Fixing Z-Wave for once and for all!

[Plantje]

Ok, for now however we'll have to make do with what we get. And then I am still trying to understand the quirks of Z-Wave. Found a new one yesterday...

Normally, as soon as one of my Fibaro smoke detectors stops reporting temperature, I assume it is dead, I have to add it again, hit the "Refresh node info" button or have to replace the batteries.
However, I noticed....as soon as that happens the "Air Temperature" device doesn't report temperature anymore, but a new device on the node has popped up. This is named "Air Temperature/Humidity" and is nicely reporting temperature... This can happen after days, hours, weeks... I don't know

[AntoonvdOetelaar]

I would be better off switching to an Atom Homey.

Do you know how it communicates with z wave devices?
The only implementation I have seen working without any problem are Fibaro Homecenter controllers.
Can we easily interface with them?

[heggink]

I would not mind having a zwave2mqtt type solution. The zigbee2mqtt works really well...

Sent from my SM-G980F using Tapatalk

[felix63]

I would not mind having a zwave2mqtt type solution. The zigbee2mqtt works really well...

Sent from my SM-G980F using Tapatalk

Except for the 250 device limits

[heggink]

Agreed but that is being worked on.

Sent from my SM-G980F using Tapatalk

[manuloup]

Before remove and adding them again, try the "refresh node info". Most of the time this works for min system.
- Hardware
- Zwave settings
- Node management
- Control panel
- click on "select operation"
- choose "refresh node info"
- select a node from the list which it's not working correct.
- click on "Go" (behind the "refresh node info")

Do this for all nodes that are not working and wait half an hour or so. For me this brings back the nodes again most of the time (not always). And I'm aware that there is also a refresh node button in Domoticz self but for some reason this does not the same because in my experience is that clicking on this button has no effect at all.

Thanks to you, I was able to restore some of my lost devices !

Before :

zwave1.jpg (275.43 KiB) Viewed 1857 times

After :

zwave2.jpg (347.68 KiB) Viewed 1857 times

Now I would like to delete from my zwave key the old devices that were broken or sold. I tried to do a delete device in CP, but did not work.
Do you know a better method ?

Thanks

Manu

[lost]

Agreed but that is being worked on.

Domoticz only use the open-zwave library from whole OZW projects: On top of this library you have qt/nodejs/mqtt that were added to interact with it, probably to allow use in projects that did not made the effort to provide a real tight integration to their own core until main contributor says stop.

This is not theses wrapper/server added layers of complexity (+heavy dependencies quickly impossible to manage, usually dealt with the worst "modern" way with containers) that'll manage your hardware.

OZW exists, have proved rock solid used alone for most users in the past. So a back to basics approach would IMO help.

Anyway, this new for me means buying a few spares (as some discounts show off from resellers that may fear for their sales in the coming month) but no new devices that may never gain support.

Sigma designs already provide a SDK on device side. IMO they should take OZW development lead, otherwise they're dead.

[heggink]

Not sure I understand what you are trying to say. The challenge with open source is that it's 'open' and therefore depends on contributions. Every now and then a new , better concept comes along and it gets adopted. Same with Domoticz: over the years, great additions like dzvents and the python framework have been added. On the zigbee side, that now gives multiple workable choices for integration (I chose z2m but others made other choices). I would be quite happy for domoticz to be the great integration and automation hub to connect different technologies together and build nice environments. In that sense, having a zwave plugin (rather than a built-in) would be great as it would allow flexibility in choice but it would require someone like stasdemidyuk creating the plugin for something like zwave node js. If you find that another implementation provides better support, the switch is relatively easy where, right now, we're all dependent on the built-in open zwave.

Agree on the complexities of containers but at some point in time, you don;t really have a choice as it seems to be the only (workable? efficient?) way to balance stability (stuff that works and you don't want to upgrade) with new requirements (bugs being fixed, security requirements) where both have conflicting dependencies (different versions of libraries which is a continuous challenge). At the moment, I can easily run zigbee2mqtt on the same hardware natively, in a container or on a different system without any impact to domoticz. I can decide to update zigbee2mqtt or the plugin nor both depending on their mutual compatibility. The moment I update domoticz because I want a new dzvents feature, I get all the other updates I may not want. With either dzvents or the (updated >255 devices) python framework, there should be no need to build in zwave. But still, someone would need to build it... The joys of open source .

[lost]

Agree on the complexities of containers but at some point in time, you don;t really have a choice

To drive such specific HW like a z-wave controller, that probably does not fit in any OS driver model, IMO there is very few mandatory dependencies. Problem comes with added layers targeting IoT unification. OZW did go towards these but with a single person driving the project + added traction from projects that did not do the job of a tight integration = Current situation.

As well, I'm not sure there is no choice: The problem is less & less developers are able to build something without using many avoidable dependencies that'll soon show maintenance issues: This works quickly, but soon become a nightmare. This leads to a situation than began with Java aging: Now, almost any SW built on Java comes with it's own JVM to run without issue... Now that's even doing some chroot on steroids for anything.

In conclusion, for me, containerization = If not targeting test, mostly external sign of quick&dirty design!

[rrozema]

I would not mind having a zwave2mqtt type solution. The zigbee2mqtt works really well...

Sent from my SM-G980F using Tapatalk

I run both openzwave and zigbee2mqtt. I think zigbee2mqtt has potential, but it still has a very long way to go before it comes even close to z-wave. zigbee2mqtt is still very immature: It crashes when you change the name of a device, many devices aren't properly recognised, it only supports a limited set of types of devices, etc. Most of the problems are however due to the zigbee protocol and standardization by far not being as complete as z-wave's, so I don't see zigbee as a proper replacement for Z-wave for years to come. But marketing push for zigbee is a lot stronger, so we may easily get stuck with inferior zigbee devices, just like what happened with VHS. Alternatives where technically more reliable and better, but because people are to stupid to decide what's good for themselves, we all got the inferior product pushed onto us...

[heggink]

I would not mind having a zwave2mqtt type solution. The zigbee2mqtt works really well...

Sent from my SM-G980F using Tapatalk

I run both openzwave and zigbee2mqtt. I think zigbee2mqtt has potential, but it still has a very long way to go before it comes even close to z-wave. zigbee2mqtt is still very immature: It crashes when you change the name of a device, many devices aren't properly recognised, it only supports a limited set of types of devices, etc. Most of the problems are however due to the zigbee protocol and standardization by far not being as complete as z-wave's, so I don't see zigbee as a proper replacement for Z-wave for years to come. But marketing push for zigbee is a lot stronger, so we may easily get stuck with inferior zigbee devices, just like what happened with VHS. Alternatives where technically more reliable and better, but because people are to stupid to decide what's good for themselves, we all got the inferior product pushed onto us...

My point was not to push zigbee over zwave but to make a case for plugin based integration over builtin especially for zwave. I also run both because, whilst being technologically more advanced, I had many issues with zwave devices dropping off the network (e.g. smoke detectors) and consistently creating new devices when re-included, refusing to be refreshed. With zigbee, the smoke detectors I never had any issues with (for over 6 months now). Again, not trying to push one over the other but hoping that there will emerge some kind of plugin based zwave integration that I can update/upgrade independently from the rest of the system and v.v.. WIth ZIgbee, I can easily make (minor) changes to the plugin myself (to deal with the shitty spirit firmware eurotronic is shipping their newest devices with), with zwave, I would have to do that in c++ and build domoticz by hand. That's a no-go for me.

[lost]

Again, not trying to push one over the other but hoping that there will emerge some kind of plugin based zwave integration that I can update/upgrade independently from the rest of the system and v.v.. WIth ZIgbee, I can easily make (minor) changes to the plugin myself (to deal with the shitty spirit firmware eurotronic is shipping their newest devices with), with zwave, I would have to do that in c++ and build domoticz by hand.

For z-wave&Domoticz, plugin means python and it's limits.

That's nice language to quickly do some glue-software you would have done from shell scripts 2 decades away, with better portability (shell only for unices + several possible choices with compatibility issues) and when performance is not an issue and/or only simple multi-threading is required... but for the core of a HW controller support, that's usually not the way to go: Just read the python plugin wiki, there is several reasons for a plugin to crash Domoticz explained that cannot be solved because of some python design choices.

Agree this plugin-way was used for other protocols (like zigbee), but for widely used ones (with intrinsic incompatibilities not managed directly by some external controller upgradable FW intelligence) the reason is they just lacks standardization: As supporting new devices will often result in adding OEM defined commands that are manufacturer/device specific, that's not just some configuration parameters to load to manage a new device there: Code changes are often needed thus the second-best option (vs a standard protocol stack integration), a plugin, makes sense.

Just think about having the network stack of your operating system attached as a plugin!

[harrykausl]

Also from me the question. Would a interface to Fibaro Homecenter or another capsuled system be possible? If yes, we could be independant of OZW.

[waltervl]

No Zwave user myself and also no Zigbee2mqtt (but using Zigate plugin for Zigbee). I also would go for a kind of Zwave plugin as this enhances the flexibility.

There is already a ZwaveJS2MQTT solution.

Another solution would be that the domoticz community takes over the maintenance of the OpenZwave library now Domoticz seems to be the only major Home Automation solution that uses OpenZwave (if I am correct...).

[lost]

Domoticz seems to be the only major Home Automation solution that uses OpenZwave (if I am correct...).

Don't think so. I've Jeedom in mind + HA, latest looking for alternatives (that may not be on par with a > 10 years project soon).

[waltervl]

I did not know of Jeedom using OpenZwave. I could not find their plans with OpenZwave.
HA is definitely looking into another direction: https://www.home-assistant.io/integrations/ozw/

This integration allows you to utilize OpenZWave’s ozwdaemon to control a Z-Wave network over MQTT. If you’re starting out with Z-Wave in Home Assistant, we recommend that you use the Z-Wave JS integration.

[heggink]

I checked the zwave node js device support and all my current devices are supported. HA also has device autodiscovery and erik montnemery has built a plugin for domoticz, based on the HA autodiscovery so some base pieces seem to be there. Fix the python 255; limit and maybe this could work.

Sent from my SM-G980F using Tapatalk

[Plantje]

I would be better off switching to an Atom Homey.

Do you know how it communicates with z wave devices?
The only implementation I have seen working without any problem are Fibaro Homecenter controllers.
Can we easily interface with them?

I think the main difference is that Atom Homey uses a paid interface rather than the Open Z-Wave interface. As I understood there are roughly two ways to build in communication with Z-Wave in your home automation system:

• The "official" and paid interface that will cost quite a lot of money. This is what is included in Fibaro, Samsung Smart Things, Atom Homey etc.
• Free interfaces built by people that have started this as a hobby. Open Z-Wave, Z-Wave Node-JS, a possible Z-Wave2MQTT.... What Domoticz, Home Assistant etc use.

So, this is why I am in doubt and why I started this topic in the first place. Basically: will it always be a hassle with systems like Domoticz, Home Assistant etc? Will it always be tinkering? And at the same time: does switching to a system like Atom Homey, Fibaro Homecenter, Samsung Smart Things mean it will automatically work and always work? Or perhaps the issues that I am running into are mostly caused by using either older devices or cheap Chinese devices.
I know my brother was done with Domoticz and switched to Atom Homey and every now and then he asks:"When are you done tinkering with your home automation? When do you take the plunge?"

I think I already stated it here before: I have worked with my own tuners and PVR software for years and took the step to switch to the cable company provided box that nowadays stores recordings in the cloud and it is great! I am done with maintaining the system and checking logs. And with Domoticz (especially with Z-Wave) it feels like I am constantly maintaining the system and checking logs.

Sigma designs already provide a SDK on device side. IMO they should take OZW development lead, otherwise they're dead.

I think Sigma Designs already owns the non open source part of Z-Wave. There is no benefit for them to take over the OZW whatsoever. By open sourcing a part of Z-Wave in 2016 they have made OZW possible. If no one is using the open sourced code and making a complete open source solution the only option is to use the Sigma Designs licensed stuff.

Also from me the question. Would a interface to Fibaro Homecenter or another capsuled system be possible? If yes, we could be independant of OZW.

That would perhaps be a good option... So: using the benefits of the paid/licensed Z-Wave interface that Fibaro HC has and the flexibility of Domoticz at the same time. On the other hand: if you're thinking in that direction, you might as well switch to Fibaro HC altogether. And I hear you:"Yes, but then I would only have the expenive Z-Wave!" and you're right. So then Samsung Smartthings is an option or (and I think a lot of people here are from the Netherlands) Atom Homey.

[heggink]

So, this is why I am in doubt and why I started this topic in the first place. Basically: will it always be a hassle with systems like Domoticz, Home Assistant etc? Will it always be tinkering? And at the same time: does switching to a system like Atom Homey, Fibaro Homecenter, Samsung Smart Things mean it will automatically work and always work? Or perhaps the issues that I am running into are mostly caused by using either older devices or cheap Chinese devices.
I know my brother was done with Domoticz and switched to Atom Homey and every now and then he asks:"When are you done tinkering with your home automation? When do you take the plunge?"

Agree. I happen to like the messing about with technology but I realise that the current system is fully dependent on me and heaven forbid me and my car have a close encounter with a tree at speed...

In that sense, it's a bit like going open source vs going Microsoft: I can do stuff with domoticz that cannot be done with commercial systems that are more restrictive. Does that mean that you cannot get to a best of both worlds? That's why I am interested in the plugin approach rather than the built-in approach. Some of the challenges with domoticz come from the fact that, when you update, you update ALL, whether you like it or not. There is no partial upgrades. If Zwave Node JS is as functional as OZW and HA already recommends it then I'd rather use that and not be dependent on new domoticz versions.

On your question, is OZW/ZW-node-js functional/stable enough compared to fibaro/homey/..? That's a good question. Is the hassle worth the flexibility? Comparing to zigbee, for me it is. I can make minor changes that allow me to keep it functional without major hassle.

Are some of the zwave issues solved in zw-node-js? Without the change to >255 devices in the python framework, and without a python plugin, there is time to look at the HA/zw-node-js forums and monitor people's issues reported and see how that's being experienced. I am in no rush but the moment a flexible alternative comes along, I will move.

[rrozema]

Are some of the zwave issues solved in zw-node-js? Without the change to >255 devices in the python framework, and without a python plugin, there is time to look at the HA/zw-node-js forums and monitor people's issues reported and see how that's being experienced. I am in no rush but the moment a flexible alternative comes along, I will move.

Ignoring my personal objections against zigbee, the 255 devices limit shouldn't be an issue when comparing zigbee to z-wave. Z-wave has a limitation of max 232 devices per network. In theory you could have multiple z-wave networks each having a unique homeid, but openzwave doesn't allow for this, at least not at the moment in domoticz.