Domoticz

Hey PieterS,

You need 2 components: zwavejs2mqtt and the domoticz plugin. Zwavejs2mqtt is best run in a docker container but has nothing to do with the plugin moroen and I built. I don't know if there is a zwavejs2mqtt docker container image for Synology.
The plugin is a standard python plugin which I suspect can work on Synology but I am not a Synology expert. The plugin does not care where zwavejs2mqtt runs.


Sent from my SM-G980F using Tapatalk

https://community.home-assistant.io/t/i ... ker/287788 seems to indicate you can run it in Synology

Sent from my SM-G980F using Tapatalk

Thnx Herman for explanation. Didn't understand there are 2 services and there dependency.
To be continued

OK, good luck with the Synology implementation. Let me know how it goes and whether you need any help.

I have a couple of Fibaro FGMS001 motion sensors with older firmware version 2.6 that still use the deprecated Alarm Sensor Command Class (/156) to send a tamper alarm. If I trigger the tamper alarm I see the following MQTT messages:
I've added this to device_types.yml:
In device_types.py I've added:
In devices.py and topics.py I've added sensor_alarm to the .device_types to import. However it seems the plugin filters out the topic zwave/10/156/0/state and doesn't send it to Domoticz. With the plugin set to Debug->All the topics /10/156 are not logged in Domoticz. The topic zwave/10/49/0/Illuminance works fine though.

Any idea what goes wrong?

Can you check device_types.py? It has the device types hard coded in there but I am not sure if these are still used as I am behind on versions myself.

Also, I know zwavejs2mqtt has the ability to update fw but I have not tried it so I don't know where it gets its firmware from.

Sent from my SM-G980F using Tapatalk

If I publish the same topic with exactly the same payload using a modified version of the tools/mqtt-device utility it works fine. What could be the difference with zwavejs2mqtt?
Firmware upgrades for Fibaro devices are only supported with their home centers. I don't have one and think it is too much trouble to either send my devices to Fibaro or a local dealer. I can live without the tamper alarm, it is just the challenge to get it to work

Got it working. Previously I've overlooked that I had to add the sensor type after state (/0 general purpose alarm):

I've added this to devices_types.yml

Changes merged! Thx.

Sent from my SM-G980F using Tapatalk

All my Z-wave devices are now working smoothly with zwavejs2mqtt, mosquitto broker and the ZWave-MQTT-plugin. Performance is much better, especially when switching multiple devices at once. I was already looking for an alternative home automation solution but dzVents and many other good things of Domoticz kept me on board. The future of OZW however doesn't look good and after this new plugin has had some proper testing with more devices I suggest that Domoticz makes the same architectural move as Home Assist did earlier this year (https://github.com/home-assistant/archi ... issues/483).

Thanks again for this great plugin. I'm not switching back

That's great to hear. I was a little curious to see whether the base functionality was adequate enough for others to adopt. Glad to see it's working.

Wrt domoticz making the move to zwavejs, I, like yourself, very much like the strength of the domoticz scripting (dzvents, python). I looked at HA but the idea of having to migrate all my dzv scripts to yaml gives me the creeps. In that sense, I'd rather NOT have domoticz hardcoding zwavejs support because then we are back to square one: everytime you need a fix for anything, you need to take every other change on board as well. In this case, I can simply update zwavejs and/or the pluging with no need to update domoticz itself. The overhaul of the python plugin framework has already led to a couple of beta's crashing people's systems (which is why it's called beta ) and I'd rather decide myself what to update when. If someone were to migrate dzv to HA then maybe .

I also see the big improvement in responsiveness. When I switch off all the lights at night, it literally takes sub second to switch everything (14 devices) off, check all the doors, locks and report through the google home speaker.

The only thing I do see is that there is a small mem leak in my system. Moroen noticed the same. I cannot relate it to the plugin. Maybe it's the python subsystem, IDK. it's marginal and I can easily run for many months (maybe even a year) without the need for a restart of any kind (given the 4GB mem). Also, performance is not impacted at all so no issue there. I just don't like the idea of a memory leak.

H

Have to say I agree with everything said above. Due to the weakness of Openzwave/Zwave I wrongly attributed this to Domoticz and considered changing to another platform but I didn't like any of the other options although Homeseer was tempting. However after starting to use Zigbee2mqtt and seeing how responsive it is and this promising start with zwavejs2mqtt I won't be moving. I do think that as has been stated before that moving zwave out of the Domoticz core isn't a bad idea. I will definitely be trying this option sooner rather than later.

heggink wrote: ↑Monday 23 August 2021 16:32I'd rather NOT have domoticz hardcoding zwavejs support because then we are back to square one: everytime you need a fix for anything, you need to take every other change on board as well.
(...)
I also see the big improvement in responsiveness.

Well, I do not agree: Tight integration of zwave was IMO a benefit + a well standardized protocol with interoperability in it's roots (compared to 433/868, up to need dedicated hardware gateways with a firmware hiding the mess of OEM commands ; zigbee being somehow a modern version of this) do not need frequent code updates (only for config files, now done on startup with OZW 1.6): So current situation was adequate for this protocol.

JS interpreted code as a plugin being more responsive than OZW compiled/native in domoticz raise some questions: Migration to zwavejs needed a full rebuild of your zwave network (exclusion/reinclusion of all modules) I presume? Maybe doing so at once resulted in a better topology than adding devices one by one over several months/years.

JS was never designed as a general language to drive hardware, but as a client-side enabler for dynamic web pages (php was for server side)! I really hope someone will take the missing lead for OZW, or maybe Silabs will provide something as free software & easier to merge for free projects like Domoticz than existing Z-IP stack.

lost wrote: ↑Tuesday 24 August 2021 15:32I really hope someone will take the missing lead for OZW, or maybe Silabs will provide something as free software & easier to merge for free projects like Domoticz than existing Z-IP stack.

I wonder how likely that is.

lost wrote: ↑Tuesday 24 August 2021 15:32

heggink wrote: ↑Monday 23 August 2021 16:32I'd rather NOT have domoticz hardcoding zwavejs support because then we are back to square one: everytime you need a fix for anything, you need to take every other change on board as well.
(...)
I also see the big improvement in responsiveness.

lost wrote: ↑Tuesday 24 August 2021 15:32Well, I do not agree: Tight integration of zwave was IMO a benefit + a well standardized protocol with interoperability in it's roots (compared to 433/868, up to need dedicated hardware gateways with a firmware hiding the mess of OEM commands ; zigbee being somehow a modern version of this) do not need frequent code updates (only for config files, now done on startup with OZW 1.6): So current situation was adequate for this protocol.

Maybe, but apparently not in real life. Domoticz lost a lot of its user base to HA as a result of the switch from 1.4 to 1.6. Had it been separated then one could have updated domoticz without the OZW upgrade that was part of it.

lost wrote: ↑Tuesday 24 August 2021 15:32JS interpreted code as a plugin being more responsive than OZW compiled/native in domoticz raise some questions: Migration to zwavejs needed a full rebuild of your zwave network (exclusion/reinclusion of all modules) I presume? Maybe doing so at once resulted in a better topology than adding devices one by one over several months/years.

Actually, no! It literally was shutting down OZW, adding the plugin, starting zwavejs2mqtt and renaming the automatically created devices.

lost wrote: ↑Tuesday 24 August 2021 15:32JS was never designed as a general language to drive hardware, but as a client-side enabler for dynamic web pages (php was for server side)! I really hope someone will take the missing lead for OZW, or maybe Silabs will provide something as free software & easier to merge for free projects like Domoticz than existing Z-IP stack.

I might agree on your observation of JS but the fact is that we need an open source based community to maintain a decent zwave implementation and zwavejs has one that is brilliant and responsive where OZW is nothing but trouble. I then prefer workability of the solution over discussions about the best technology for the job. The net is that my zwave environment is more functional, more responsive and less hassle than OZW ever was. Case in point I guess

solarboy wrote: ↑Tuesday 24 August 2021 16:52

lost wrote: ↑Tuesday 24 August 2021 15:32I really hope someone will take the missing lead for OZW, or maybe Silabs will provide something as free software & easier to merge for free projects like Domoticz than existing Z-IP stack.

I wonder how likely that is.

As per my other post, I would absolutely not go back now that I am using zwavejs2mqtt. If domoticz crashes (for any reason), zwavejs is still there. zwavejs is more functional, extremely stable (no device issues at all), less hassle. Why would I want to go back to a sub-par solution (in my particular case that is) that needs a lot of work to get to where I am now?

lost wrote: ↑Tuesday 24 August 2021 15:32
JS interpreted code as a plugin being more responsive than OZW compiled/native in domoticz raise some questions: Migration to zwavejs needed a full rebuild of your zwave network (exclusion/reinclusion of all modules) I presume? Maybe doing so at once resulted in a better topology than adding devices one by one over several months/years.

No exclude/include needed after migrating from OZW to zwavejs2mqtt. Just a "re-interview nodes" and waking up battery powered nodes sufficed for me. Most work was renaming the new device names in Domoticz and re-ordering the widgets in the GUI.

heggink wrote: ↑Friday 06 August 2021 13:18
The plugin can be found at: https://github.com/moroen/ZWave-MQTT-plugin

Instructions on how to install are on that page. In essence, it's fairly simple: install and run zwavejs2mqtt (ideally in a docker container), install the plugin, restart domoticz and start adding devices.

Since I had quite a selection of devices, it took me a while before I had moved everything from OZW to zwavejs2mqtt. Keeping the shop open whilst in transition, I had to switch between OZW and zwavej2 about 3 times before I could stop OZW altogether. This is a bit of a hassle since OZW is pretty iffy about being shut down and started up again. That said, it was not a big hassle for me (despite my 150 devices in domoticz) and I have been a very happy camper since. zwavejs2mqtt has been incredibly stable, has allowed me to configure things correctly/properly for the first time in my zwave history and provides functionality that OZW just does not (like deleting dead nodes and those nodes staying dead forever, unlike OZW just recreating them and having to resort to editing zwave databases in the stick).

Perhaps write a small instruction in the plugin readme how to migrate from Domoticz OZW to Zwave-JS2MQTT with Plugin.
Is there a instruction how to take over node names/ID's? Domoticz device naming?

That's a good idea. Just added some extra explanations here and there. Should be pretty complete now. Have a read and let me know if it's clear and concise enough.

H

Thanks Heggink for this new approach for zwaves.
It looks good
I've started to set it up on a testing server...
So far I have the control panel running with most of the node Completed.
I needed some time to find the node in dz... So, I understand that I'm going to have new devices... and I don't know how I'm going to match them with the old ones...
It's seems that I'll need to redo the dz part (names, plans, scripts (with idx). I just have 80 devices used, so it's possible. Maybe, I missed something on this part....

I also have some errors, I don't know if it is relevant. I'm writing some notes in order to be able to redo it on my production server in a while, perhaps I'll could share the points where I had issues regarding the initial documentation