It is better than resetting the controller. Zombie nodes can cause network routing issues too.
That explains some issues I was experiencing which only a hard-reset cured. Now I hopefully never have to do that again.
Yes, you should be able to use the “Remove Node” function if it is failed. This can only remove nodes that are in the controllers Failed Nodes list and this is where the problem lies. I should modify the binding to send a command immediately before the remove node so that we can be sure the device is on the failed node list, but that’s not what the binding currently does.
Just one other point about “standards” - please remember that most of the binding was written well before the standards were available. ZWave was a closed protocol until quite recently and most of the binding was developed by reverse engineering communications with devices.
2 Likes
I can see how that would lay down a fairly rocky road in as far as continued development is concerned.
When it comes to ‘standards’, there are always going to be manufacturers/developers who don’t play the compliance game, and I fear that it becomes a messy domain if all involved then dive in with a primary rule to cater for the non-compliants at the expense of the compliants.
One could say a dev should go with compliance and add features to accommodate the non-compliant as an after-thought rather than a driver behind the foundation design. Again this is always up to the developer, even moreso in non/little-paid effort. However I have always felt that when we’re dealing with the opensource world, we should stick to standards irrespective of those who don’t follow standards, if anything, it would encourage compliance across the board especially if a particular developer’s efforts gain great attention and manufacturers desire to plug into the efforts of said-developer. Catering for non-compliants as a rule is usually always a recipe for disaster.
Maybe you can put real consideration into going the standard framework of zwave with the concept of a supplementary device config database which would come into play for the non-compliant.
Problem these days is that everyone wants you to use ‘their’ hubs, people jump onto wonderful radio-network protocols, buy the licensing, and then go off and tweak around on the verge of compliance causing interopability issues outside of ‘their own’ hub.
Thank goodness for Tasmota and the likes of Sonoff not locking down their hardware, but at the same time why Sonoff can’t simply add MQTT support goes over my head, because that is primarily why we tinkerers are forced to flash those devices in the first place other than preventing the devices accessing the internet etc.
A mind pizza if you will. 
Too much of that and licensing can get revoked with penalties for still using the trademarked name.
Actually, that is a very old version. This software has evolved into the PC Controller software. This can be downloaded stand-alone or inside Simplicity Studio. There are a few threads about this and the Zniffer software, but here is one…
Aeotek had been using a version of Zensys Tools as their firmware installation tool, but I think they are now using the new version from SiLabs.
1 Like
That is what I’m planning. The binding rewrite which is underway will do this in the same way as I implemented for ZigBee. The binding will detect the device features, and create channels automatically.
Fundamentally, this is actually what happens now - it just that it’s a wide loop which includes the binding creating an XML file which contains the devices features, ingesting that into the database to create the channel definitions, and then compiling those definitions into the binding. As mentioned previously, it was done this way out of necessity as OH2 did not have dynamic channels capability at the time.
I’m currently discussing the Silabs how to move forward with a compliant, certified, binding. It is likely I will need to complete this before Christmas to avoid “legal difficulties”. My big fear at the moment is that OH2 (or OH3) doesn’t provide the framework features, and the UI features that are required by ZWave Alliance and that could be a big problem.
1 Like
You cannot get configuration parameter & association group information from the device though. How do you plan on handling those parts?
I’ve just installed zwave2mqtt just to see how it all hangs together, quite nifty, I enabled the homeassistant mqtt integration which then made all the zwave nodes appear in the OH inbox as mqtt components with all the parameters. Definitely no where near as refined as the zwave binding in OH but the fact it allowed an unrecognized device straight in and even identified the switch parameter was quite impressive. Also does some pretty nice visuals of the mesh as in how all the devices connect to each other, very nice. I also see that it has the ability to backup the controller config and load it back in too!!!
Playing with it right now and trying to break it, but so far so good. Though at this stage I feel more comfortable with the zwave binding. I’ve noticed that HA users are readily dropping HA’s zwave facility for this zwave2mqtt too.
I would not blame them. Their openzwave based addon is abysmal, especially if you do not live in Europe. That is a big part of what drove me here. They could likely freely make use of our zwave database but then they would need to write & support their own addon.
They must come from the database except for very new devices where this is available from the device.
1 Like
@chris - one ‘feature’ I noticed with zwave2mqtt is that it downloads device config xmls, I’m guessing in effect replicating how the zwave binding relies on the device database. That is I feel a very good function if we can achieve that with our native zwave binding, so rather than an integrated db, just pull down updates as and when requested by user, I’m not really supportive of auto-downloads, as god knows what it can mess up and I like to be in control of when I give the virtual machine internet access (ie updating linux etc).
How does that work on systems with no Internet access? OpenHAB is designed to not need any Internet access after it is installed. That is the purpose of the addons Linux package. Addons can be installed with NO Internet access.
Manual download, they’re in the github repository it seems.
Be it manual or auto, function is the same really as in there is no downtime and no updating addons etc.
Working within the OH framework I guess is a limiting factor for innovation without working around the framework which isn’t ideal. Understood. Though definitely something that would make things a little more ‘smoother’, as in go into CD Jackson, add the device, get it approved, then go in app, click ‘update unrecognized device’ for those who have online uplink or download files via other means and have an upload button alongside giving the offline users the ability to immediately update the config with zero downtime and zero elbow grease. Complexity and time is a buzz killer indeed, that is headache-free usability for you I guess.
*I’ve hit my post limit for today it appears, catch up soon.
This is complex with OH since the OH configuration system relies on reading the XML files in the binding. I could rewrite this so that it doesn’t rely on openHABs internal systems, but that’s quite a bit of work.
1 Like
I figured you already considered that. We appreciate your good judgement.
1 Like
Done.
3 Likes
I just tried the latest snapshot addon, error still appears to be there? unless I’m pulling from the wrong source, or even too early? ( https://ci.openhab.org/job/openHAB-Distribution/41/ )
How long before the update usually hits a snapshot?
Yes, the change has not made it into the binding:
Database export is done usually at the weekend.
You don’t have to upgrade your openHAB installation, just the zwave binding would also work, either manually or through this script:
I did the update yesterday, but CI had not completed by the time I went to bed last night. I will check this morning and if it’s ok I will merge.
1 Like