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

[mhilbush (Mark)]

@rbuelund

Now go back to Habmin, and Readd a Zwave Controller.

Did you enter the serial port of the controller in the Serial Controller thing?

[lsiepel]

I had some issue’s with the dimmer and the dev binding, i had to remove and add the device and that fixed everything.

[rbuelund (Ronny)]

I did, but it did not really accept it ? I now went back to the old
binding which works. Also if I try the new would I have to add it every
time I restart my Raspberry pi ? When is a stable release expected?
With the old binding i cannot use my Fibaro sensors.

[dan12345 (Dan)]

Hi - and not wanting to chase, but just wondering if there would be a fix for this in the next few days? If not, would you mind posting a JAR before all the hold-off changes made things a little unstable?

thanks,

Dan

[mhilbush (Mark)]

@rbuelund

I did, but it did not really accept it ? I now went back to the old
binding which works. Also if I try the new would I have to add it every
time I restart my Raspberry pi ?

I’m not sure what you mean by it not accepting it. Are you saying that when you go back into HABmin after setting the serial port the serial port is not set?

[rbuelund (Ronny)]

…ok… I press the + sign under Things in HABmin. I select “Z-Wave
Binding”, Z-wave controller and press save (Nothing happens here??) I
then go to PaperUI and see the added controller under Things. I edit the
controller and insert /dev/ttyAMA0 as serial (which was the correct for
the old binding. I save and get:

Status:OFFLINE - COMMUNICATION_ERRORSerial Error: Port {0} does not exist

So this does not work.

[mhilbush (Mark)]

@rbuelund

in HABmin. I select “Z-Wave
Binding”, Z-wave controller and press save (Nothing happens here??)

So a Serial Controller thing doesn’t show up in HABmin’s Things list? That’s really odd.

@rbuelund

I edit the controller and insert /dev/ttyAMA0 as serial

And you confirmed that /dev/ttyAMA0 exists and that there is not a permissions problem?

Can you confirm that the serial feature is installed?

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

On a completely clean installation of OH2 Snapshot (#771), you will get the following error when you try to start the new Z-Wave binding: openhab> bundle:start org.openhab.binding.zwave Error executing command: Error executing command on bundles: Error starting bundle 208: Could not resolve module: org.openhab.binding.zwave [208] Unresolved requirement: Import-Package: gnu.io To fix this: feature:install openhab-transport-serial and then Z-Wave will start

Can you confirm that there’s only one version of the binding installed? In Karaf console, run this:

list -s | grep zwave

Sorry for asking what may be basic questions. In the 1.5 years of using the dev version of the binding, I’ve not come across this before.

[Kyle_Fair]

Hi there, wondering on the ETA of the release of 2.4 zwave binding? Appreciate all your guys hard work. I have bought myself a Yale zwave front door lock and trying to get it to work with no luck. Have spent about 8 hours watching vids etc on how to manually load the binding but it is way over my head.

Thanks
Kyle

[sihui]

@Kyle_Fair

but it is way over my head.

No, it’s not
Uninstall the zwave binding through PaperUI, download the jar from the first post in this thread, put it in your addons folder, restart openHAB.
If you get an error you need to load the serial transport:

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

On a completely clean installation of OH2 Snapshot (#771), you will get the following error when you try to start the new Z-Wave binding: openhab> bundle:start org.openhab.binding.zwave Error executing command: Error executing command on bundles: Error starting bundle 208: Could not resolve module: org.openhab.binding.zwave [208] Unresolved requirement: Import-Package: gnu.io To fix this: feature:install openhab-transport-serial and then Z-Wave will start

Then delete all your things and readd them (don’t exclude your devices!).
Good luck.

[Kyle_Fair]

Thank you for the reply. Will try again.

[chris (Chris Jackson)]

@Kyle_Fair

wondering on the ETA of the release of 2.4 zwave binding?

Normally, releases have been made every 6 months - the next one (2.4) is likely to be in December.

[mhilbush (Mark)]

@chris

may reconsider this issue and add unknown classes as that change is causing quite a few problems…

@chris @5iver Here’s the downside of adding these unknown classes. While I don’t think this causes any real issue, it certainly results in bogus information being added to the node.xml files.

It looks like node 43 (an Everspring ST814) lost it’s mind shortly after midnight. All those unknown command classes below were added to the node.xml.

Here’s the raw log entries.

zwave.log.20180731021619:2018-07-31 00:21:53.933 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 43: Command class COMMAND_CLASS_DCP_CONFIG not found, trying to add it.
zwave.log.20180731021619:2018-07-31 00:21:54.309 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 43: Command class COMMAND_CLASS_THERMOSTAT_OPERATING_STATE not found, trying to add it.
zwave.log.20180731021619:2018-07-31 00:21:54.318 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 43: Command class COMMAND_CLASS_SECURITY_PANEL_ZONE_SENSOR not found, trying to add it.
zwave.log.20180731021619:2018-07-31 00:21:54.326 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 43: Command class COMMAND_CLASS_DCP_MONITOR not found, trying to add it.
zwave.log.20180731021619:2018-07-31 00:21:54.333 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 43: Command class COMMAND_CLASS_METER_PULSE not found, trying to add it.
zwave.log.20180731021619:2018-07-31 00:21:54.372 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 43: Command class COMMAND_CLASS_PREPAYMENT_ENCAPSULATION not found, trying to add it.
zwave.log.20180731021619:2018-07-31 00:21:54.385 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 43: Command class COMMAND_CLASS_SWITCH_TOGGLE_BINARY not found, trying to add it.
zwave.log.20180731021619:2018-07-31 00:21:54.414 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 43: Command class COMMAND_CLASS_DCP_MONITOR not found, trying to add it.
zwave.log.20180731021619:2018-07-31 00:21:54.430 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 43: Command class COMMAND_CLASS_SCHEDULE_ENTRY_LOCK not found, trying to add it.

I’ve seen similar examples from other nodes, but not as egregious as this one.

[Lolodomo]

On my side, I am still unsble to setup my ST814 to report values every hour, I only got new values once a day. I captured the logs when I change the setting through Paper UI. I will provide them this evening.

[chris (Chris Jackson)]

@mhilbush

Here’s the downside of adding these unknown classes.

Yes - this is exactly why I implemented the change. However, while these are not nice in the XML, they also don’t cause any problem with the binding operation.

If we leave this change in, then we need to ensure that all command classes that devices support, but don’t report in their NIF, are added to the database, otherwise devices won’t work as they used to. Remember that it has worked this way since the very first version of the binding (ie in OH1) around 2013 if I remember correctly.

[chris (Chris Jackson)]

@Lolodomo

I am still unsble to setup my ST814 to report values every hour,

This must be related to associations, or device configuration. Have you tried a reinitialisation of the device - is there a log of the reinitialisation?

[mhilbush (Mark)]

@chris

Yes - this is exactly why I implemented the change. However, while these are not nice in the XML, they also don’t cause any problem with the binding operation.

Agreed. Only one exception, and it may be a pretty minor one. If one of these node.xml files was uploaded to the DB in order to create a new device in the database, won’t the DB entry be created with a bunch of bogus command classes? And, it’s unlikely the user would know which ones were legit and which ones were bogus. And, even if they did know, they would need to ask you to delete the bogus ones. Like I said, I think that’s a pretty minor issue in the whole scheme of things.

On the plus side, the node.xml can be cleaned up by doing a reinit.

[mhilbush (Mark)]

@Lolodomo

I am still unsble to setup my ST814 to report values every hour

My devices are set up to auto report every 30 minutes. If you want to PM me, I can walk you through the exact configuration I have in my devices.

[lsiepel]

@mhilbush

looks like node 43 (an Everspring ST814) lost it’s mind shortly after midnight. All those unknown command classes below were added to the node.xml.

I think Kyle meant the merging of the dev branch into the master branch so that al these fixed would join the daily snapshots. And i thought Kai wanted to do some smaller milestone like releases. imho this refactored z-wave binding would be big enough for such a release.

[jtwigger (James Twigger)]

Just added a new z-wave door sensor device to Chris’ database. Outside of waiting for the next jar file, is there another way to have the new device (which is now included in the database) get recognized in my local openhab install? Thanks!

[5iver (Scott Rushworth)]

If you’re really antsy to use it…

Modify a zwave binding jar to add/change a zwave device while waiting for a build

**PLEASE don’t use this without also updating the device database! As a community, we make the most progress when everyone contributes!** I’ve seen several posts where people have made changes to the device database and they were eager to try out their new shiny gizmo, or wanted to test a change/fix an issue, before it was included in a build. Here is a method to update the zwave jar with a modified device Thing definition, without having to use an IDE to modify and compile the jar. This method…