OH2 Z-Wave refactoring and testing... and SECURITY

Yes - you are right. At the moment, if you use text files then there is actually no way to configure the device. This was something I tried to change in ESH to allow this, but it was rejected.

Currently there is no officially endorsed way to control devices at all in ESH.

Just updated to todays build of OH and your binding above and now I am getting:

04-Dec-2017 19:35:31.365 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 22: Command received zwave:homeseer_hswd100_00_000:controller:node22:switch_dimmer --> 100
04-Dec-2017 19:35:31.365 [WARN ] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 22: No command converter set for command zwave:homeseer_hswd100_00_000:controller:node22:switch_dimmer type PercentType

Something is amissā€¦ the latest version of the binding dated 4 Dec shows as 2.2.0.201711192127

It now says 2.2.0.201712041944ā€¦ but the manifest.mf also says it is a zigbee bindingā€¦

Who cares what it says as long as it works :grinning:

It canā€™t possibly workā€¦ at least for zwave. Itā€™s the zigbee binding!

Did you test it? As the filesize has significantly decreased I doubt if this is really the Z-Wave-Binding.

Nope, I changed to installing through the market place and that works fine ā€¦

Strange - not sure how the filenames got mixed up but Iā€™ll clear this down tonight.

Iā€™ll likely look to merge this into master after 2.2 is released.

The marketplace points to the same 2.2-snapshot file, so itā€™s very strange itā€™s different if you download it manuallyā€¦

1 Like

While Iā€™ve been running the dev version for a very long time in my test system, and feel very comfortable with it, I would argue for some patience in replacing master with the dev version.

Merging the dev version into master will be a breaking change for everyone who runs the 2.2.0 snapshot version of the binding. Those of us running the 2.2.0 snapshot version on networks with a large number of nodes (I have about 70) will need to delete and rediscover all the Things. This is a lot of work, and I would like to do it just once. :wink: If there are more breaking changes planned, I would prefer that those breaking changes be added to the dev version before itā€™s merged into master.

In addition, once the dev version is merged into master, it would be great if there was some accompanying documentation that will help others migrate smoothly:

  • instructions on deleting and rediscovering nodes (including reminders to update channel settings such as Celsius/Fahrenheit, update the polling frequency if you use something other than the default, etc.),
  • best practices on using security (such as being selective about the number of nodes that use security due to the impact on network traffic, the need to save your key somewhere to aid in disaster recovery, etc.),
  • notes on using locks (there are many learnings in this thread that will help others include locks into their network).

@chris If you agree, I would be happy to help with this.

My thought is to do it after the 2.2 is released so that gives around 6 months before the next release for people to get used to the idea (or at least hear that itā€™s comingā€¦).

Yep - this is the reason itā€™s been sitting on the back burner. Itā€™s easy for people who read the forum every day or two, but those who just update their software will get a shock :frowning: .

To be clear - by rediscover, this does not mean re-include. You only need to delete the things, and press the inbox + button. This shouldnā€™t be such a major taskā€¦

I would certainly appreciate inputs on documentation. Iā€™m about to go on holiday for 2 weeks, and one thing I plan to look at is a documentation generator that will improve the detail of documentation. If you wanted, I could suggest to create a PR into the dev branch with any of the above points it would be great. I would argue that this isnā€™t really just an upgrading issue, but more generally a documentation improvement ā€œopportunityā€. We can of course also use this to generate an upgrade ā€œhow toā€ā€¦

Thanks :slight_smile:

Yes, it is just a rediscover, not an exclude/include. But, if youā€™ve modified the node label, node location, polling interval, temperature scale, restore-last-value, etc for your nodes, then it is a time-consuming process. I doubt Iā€™m the only one who has done this. And, if you have a lot of battery devices (and are impatient like me), they all need to be woken up in order to complete initialization.

I agree this makes sense. The more time between stable releases, the better. However, considering my comment above, I was trying to avoid doing this multiple times in the event there are more breaking changes after dev is merged into master.

Instead of deleting/rediscovering Things, does deleting the XMLs accomplish the same thing (pull in the new database entries), but without requiring redoing device configuration?

I wish that were the case, but I donā€™t know for sure. I thought there were changes to the Thing definition in the JSON DB that required deleting the thing.

No - it doesnā€™t do the same thing. You need to update the thing definitions and this is only done by a rediscovery processā€¦

Correctā€¦

Is there any way of manually triggering a network heal? My experience is that every time I restart either the binding or openhab (something Iā€™ve done way too often last couple of days) a couple of nodes (the ones that donā€™t have direct contact with the controller) are OFFLINE. Most often they stay this way a day or two and then suddenly they are ONLINE again. This is mains powered devices. I interpret this as the nightly heal doing magical stuff, but I am not sure. Having a way of kicking the heal manually would thus be nice.

In HABmin, select the node, go to ā€œToolsā€, click on ā€œadvanced settingsā€, click on ā€œToolsā€ again and select ā€œHeal the deviceā€.
I donā€™t know of any way to do a network heal, though.

Done that, doesnā€™t seem to help. I donā€™t really know though exactly which device to heal. The one marked as OFFLINE doesnā€™t seem to be reachable, so Iā€™ve tried healing the devices that should be neighbours of it, but no successā€¦

The only thing Iā€™m aware of is to go into the controller properties and set the heal time to the next hour. Although, I do see the last heal times updated after a restart of the binding. If your devices are dropping off the network, check into range or interference issues, or possibly a bad device. It may not be one of these devices, but a device they are routing through. When you run a discovery, do mystery nodes show up in your inbox? Iā€™ve seen big improvements in my network after removing ghost nodes from the controller. Zensys Tools works well for this.

1 Like

Nope, never seen anything from this binding in the inbox that shouldnā€™t be there. I have been having strange problems with my Z-wave network in the past, for example it seems like some nodes only work if theyā€™re in direct range from the controller. Lately everything has worked perfect though, itā€™s just the first days after a binding restart Iā€™m experiencing problems :slight_smile: