A minimum of 600 and a maximum of 1 - huh?!

Add-ons Bindings
1

Hi all, I’m fairly new to OpenHAB, just over a couple of months, my first post on here is unfortunately a bug post. :neutral_face:

When I add the zwave device ’ FT096 Plug-in Switch’, zwave binding falls apart.

If I go into the configuration of the FT096 thing and do a save, I get Error 400 bad request.

Checking the configuration, it appears parameter 113 has a minimum of 600 and a maximum of 1 range, which obviously can’t work, not sure if this is what is causing the problem of the ‘bad request’ on save, but also this device does not seem to respond to any switching requests etc, possibly all related?

Kind-of-off-topic, but I keep wondering why so many leave openhab for HomeAssistant, and I really am starting to understand the driver, OpenHAB is infested with configuration/interface bugs at every turn, some things dont work in PaperUI, somethings work in Habmin, this is supported there and not here and scrollbars vanish here and there and fonts are all out of wack here and there. Quite a headache, and takes the shine away from how powerful OpenHAB is, but these little bugs here and there really put you off. I appreciate it is opensource however these quality issues really do need addressing.

Another bug: unable to hard-reset the zwave controller from PaperUI, as in you request the reset but it doesnt actually do it, though it works when I do it via Habmin.

Hope someone can help with a suggestion how I can fix this range issue with the parameter 113 at the very least.

2

I will look at this later when I have better Internet access. Sometimes errors creep in with a community maintained database of over 1000 entries.

Really??
It is important that a system be stable and functional. Home Assistant did not support my Z-Wave devices and kept pushing the issue off to openzwave. I could not get a stably running system firm then.

Here, with this forum, my devices were listed as supported in the community maintained database and the developer himself helped me through initial glitches.

3

Hi Bruce, thank you!

I think it comes down to smooth usability. From a feature-set perspective, OpenHAB is second to none, that is why I chose OH. Saying that, I already disposed of the Zigbee binding and went MQTT direction using zigbee2mqtt, works beautifully with the MQTT binding in OH, sure it takes configuration outside of OH, but what it means is that once I set things up in OH, I don’t need to go round deleting things, bindings, cache/tmp folders etc etc on every funky update or config screwup.

Right now, Zwave binding is quite painful to use in OH as in if you try to add an unsupported device it gets on the controller and and then you want to add another one and the node count keeps going up, trying to remove things doesnt quite work properly and when things get royally screwed up you have to remove things/binding/hard-reset controller and do it all again, a serious headache. I am actually thinking of setting up zwave2mqtt so that I dont have to go through this nightmare.

The zwave binding in OH is probably one of the better ones out there across opensource platforms, but its configuration/update/management facility can be very cumbersome and requires a degree of solid skill to manage easily… really shouldnt be like this. And the whole adding a device to the database before it can be used kind of really puts you off. Even though a device is not in the database it should at least take the basic classes and implement a skeleton thing so that you can use it, and then at a later date when someone decides to flesh out a more complete configuration template for it via the device database then great, and maybe a little flag on the thing configuration can come up with a notification ‘Device template available’ or ‘New Template version available’ something like that. Zwave is a standard, the basic classes are all one really needs to use the devices at the most basic level, having to have it added in a database before it can be used just goes against the principle of zwave, config templates should be a feature not a mandatory requirement.

4

I’m not sure why you should need to do that with the ZigBee binding either. The binding is used by tens of thousands of users commercially and I’m not aware of such issues. Maybe the commercial guys do something slightly different with management - I don’t know, but the fundamental binding is the same.

This is probably something you are doing - not the binding. If you don’t remove devices, then they stay in the network. This is the way ZWave works - not the binding. If you have a device that is not supported, you do not need to reset it and re-include it into the network. Doing so is not recommended and is not a good idea.

I agree that this is unfortunate, but it’s a one off event, and the database is needed for ZWave to allow the device to be configured.

The reason it’s written this way is because when the binding was first written (for OH2 release 4 or so years ago) it was simply not possible to do anything else and ALL thing definitions had to be done statically in XML. Since then OH has the ability to dynamically generate things - this is how the ZigBee binding works.

Unfortunately it’s not a 5 minute job to change this concept. I’m currently in the process of a complete rewrite of the binding to resolve these sort of issues, but that will still be at least a few months away.

Well, as we know, standards aren’t followed. While I agree with your points above that things should be generated by reading the data from the device, there are a LOT of devices that require workarounds as they have not followed the standards.

I hope that helps with a bit of history on why things are the way they are and what you might expect in the near(ish) future.

5 Likes
5

Hi Chris, knowing the background does indeed help one to understand why things are the way they are, thank you for that.

I am an OpenHAB baby at this stage and do not profess to be anything other than a user, my opinions alongside the bug-reports are from a user’s perspective devoid of background/technical knowledge as such. I guess it is no different to my other half say “why don’t things just work”…

I appreciate it will be an uphill learning curve to live with how things are knowing how to workaround as and when.

The major issue with device databases is that if there is an issue, ie as this parameter range issue, it means end user is stuck, it also means that in order for it to be resolved, the end-user has to then move away from a stable-build and jump onto the snapshot bandwagon, which then opens one up to more concerns, although as I’ve read in the forums it is possible to just update the addon and nothing else but even then it is a manual process which is simply not quite end-user friendly.

Pretty much every major addon in OH works without needing to get into the guts of manually updating addons to snapshots etc, however this zwave device-database being hardcoded into the addon makes the zwave addon not very user friendly in the bigger picture, any little issue with the config template would mean waiting on a snapshot and then manually dealing with it or even waiting the longer duration for a stable build release.

I really had no desire to get involved with the ins and outs, sometimes end users just want to install and configure via a nice functional web-interface and do nothing other than click the mouse and types a few words.

(Kind of ironic considering I am a programmer as well as a linux/windows sysadmin both by hobby and profession… but it is one of those I’d rather not have to lose time on things if it can be avoided, especially being a father and a husband… home-automation is about convenience as well as security, being a full-time home sysadmin really isn’t on the cards, and that is where great opensource developers jump in and deliver click and relax functional systems for all to enjoy without headache)…

I will persevere… I love OH, and have already invested a great deal of time on this forum for guidance, looking forward to seeing your future rewrite release.

6

With HA it needs to see the device when first included into the network. That is not the case with openHAB. The binding queries the device. When I moved from HA to openHAB I did not touch my Z-Wave network at all. The binding discovered all my devices properly.

Battery devices need to be woken up enough times to be fully discovered.If they are not fully discovered you can try again by just deleting the Thing from OH (do NOT exclude from the network) and rediscovering it. The device even retains the same Thing ID so any Items and rules do not break.

My biggest problem when I first tried openHAB was not fully understanding the system and not asking for help here. This forum is much more helpful than the HA one, even including some of the developers like Chris here. He is responsible for both the Zigbee and Z-Wave bindings.

1 Like
7

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.

8

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.

9

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.

1 Like
10

@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?

11

The binding is supposed to work, but some of us have resorted to using the windows Zensys Tool.

http://docs.incontrolha.com/home/remove-a-failed-device

1 Like
12

Fantastic!

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.

1 Like
13

It is better than resetting the controller. Zombie nodes can cause network routing issues too.

14

That explains some issues I was experiencing which only a hard-reset cured. Now I hopefully never have to do that again.

15

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
16

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. :thinking:

17

Too much of that and licensing can get revoked with penalties for still using the trademarked name.

18

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
19

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
20

You cannot get configuration parameter & association group information from the device though. How do you plan on handling those parts?