I see several issues with the parameters of this item that need further research. At a quick glance the information appears to be in the manual attached to our database entry.
I hard-reset the controller, and now when I add this device, the ‘Switch (deprecated)’ actually works to control the switch, although the ‘Dimmer’ does not do anything. Indeed I am still unable to save any changes in the thing config due to this parameter 113 issue.
I have a few of these plugs which are zwave-plus, and I planned to set up a large mesh that goes from the house to the outbuildings etc., planning on sticking one up on the chimney for a clean line of sight down the driveway so that I can install a sensor in the parcel box to let us know when parcel box is opened.
I am busy at work in the eastern US. Hopefully I can look at this entry this evening unless somebody else gets to it first.
When I first started here, I noticed many issues in the database and, as thanks for OH, spent 4 months cleaning up issues. This particular device was last updated just a few months ago.
@chris - a very quick question, is it not possible to remove a device from a zwave controller after the device has already vanished (ie broken)? I ended up with 3 nodes which were no longer in my network but they kept re-appearing in the inbox, in the end I just ‘ignored’ them. Does this mean that until you hard-reset the controller, those devices which one has elected to ignore will always be on the controller?
The binding is supposed to work, but some of us have resorted to using the windows Zensys Tool.
That link sends through to a 404 when downloading, looks as if they removed it. A little more research and I found this one to work:
Thank you Bruce! I especially like the idea of ‘backing up’ the controller! Something to do as part of every OH backup/update… should make life much easier.
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.
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.
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.
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.
@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.