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

Kellermeister · June 30, 2018, 1:13pm

Hello
I’m using the development version of the z-wave binding. thanks, it’s great what you do.

With the development version of the 24-04-2018 all works fine. I have now updated to
the version of 26-06-2018. With this newest version, i don’t see any z-wave things in
habmin. (newest version downloaded with the link on 1st entry in this topic)

What i have to do to make the new version work again?

My Openhab Version: 2.2.0

stefan.hoehn · June 30, 2018, 1:54pm

Thanks, @sihui, you made my day! When “going back to the future” (hence, removing 2.4 and using the newer 2.3 dev branch) all my problems with the former working and currently non-working things went away and I am back on track with my installation.

sihui · June 30, 2018, 2:21pm

I’m pretty sure with an openHAB version that old all the new features in the development version of the zwave binding won’t work anymore …

chris · June 30, 2018, 2:44pm

@mhilbush please try this version. This adds support for alarm_entry and also tries to resolve the issue with initialising battery devices that you are having.

mhilbush · June 30, 2018, 3:02pm

Thanks @chris! I try it out shortly.

chris · June 30, 2018, 3:04pm

For the alarm_entry - I just aggregate all the different alarms into one - so MANUAL, AUTO, KEYPAD etc are all used to show the lock state. I think this is fine - if we need to spit this at some stage to provide more detail, then we can look at that later…

mhilbush · June 30, 2018, 8:06pm

@chris I’m not having any luck with this version. Here’s a log from node 72 (Wallmote).

https://drive.google.com/open?id=1ISFE4r-kVFjms0OZiF9U2Sn561MSqsEr

15:54:59.555    Discovery started (thank you for the change to TRACE log level)
15:55:12.980    Added thing from inbox
15:55:47.911    Woke up device

chris · June 30, 2018, 8:32pm

It looks like the change I made worked, and I think this will help, but it’s obviously not the root cause…

hoomee · June 30, 2018, 10:12pm

thank you @sihui for your answer.

That’s were I took that from:

openHAB 2.3.0 Build #1232

but how do I know if it is stable, snapshot or whatever else?

Yes, that’s the one in addons folder. It is installed but not active, so it’s not working.

It seems to work:

19 │ Active │ 80 │ 3.12.0.OH │ nrjavaserial

and yet I receive that error:

openhab> bundle:start 277
    Error executing command: Error executing command on bundles:
    	Error starting bundle 277: Could not resolve module: org.openhab.binding.zwave [277]
      Unresolved requirement: Import-Package: org.eclipse.jdt.annotation; resolution:="optional"
      Unresolved requirement: Import-Package: org.eclipse.smarthome.config.discovery.usbserial

(I reinstalled so the number changed from 272 to 277).
The zwave binding I had running was installed in habmin, so I went to karaf and uninstalled zwave from there (bundle:uninstall xxx). Then I dropped new binding in the addons folder (to keep the dependencies, as proposed by @chris). It reported installed (but not active) and starting failed with errors as above. I “chown”-ed the binding to openhab:openhab btw, should I not?

Has anybody seen those errors before? Is my only hope to reinstall openhab?
What are those “jdt.annotation” and “smarthome.config.discovery.usbserial” anyway?

Sidenote:
All I want is to get the Fibaro Dimmer2 and Qubino Flush Dimmer to report their state. It’s only possible in development binding, isn’t it? (Associations seem not to work well as well ATM, but that’s sth I can live with, or without to be strict.)

sihui · June 30, 2018, 11:04pm

That is a pretty old snapshot version. Current snapshot is #1307.

You should at least upgrade to openHAB 2.3 stable.

The proper way to do that is:
uninstall the binding the way you did install it. So if you did install it via GUI, uninstall it via GUI.
If it does not work uninstall it via karaf.
If it is still not gone (check via bundle:list), clear cache and tmp.
After you got rid of the binding drop the jar into the addons folder. It should be active automatically.

If the transport serial is missing install it.

If you are finished restart openHAB. It will take a while because you cleared tmp and Cache …

chris · July 1, 2018, 8:31am

Just FYI, I understand the issue now - it’s caused by this change -:

I just need to work out how to resolve it…

EDIT: @mhilbush please try this version.

I think that once this issue with the wakeup is resolved, I will merge this new DEAD NODE code into the main dev branch, and if there’s no major complaints merge dev into master in a week or two. @5iver I’m not really sure where we are with your issues?

mhilbush · July 1, 2018, 10:59am

Seems obvious now that you point it out.

The change makes sense, maybe with the exception of the WAKE_UP command class.

I’ll try this version out now.

mhilbush · July 1, 2018, 11:38am

@chris I’m still seeing the “Node doesn’t support WAKEUP” message in the logs when I wake up the device.

As before, I deleted a Wallmote thing, rediscovered, added from the inbox, then woke it up. Do you want to see the log?

I also tried resetting a Minimote and reincluding it. Same behavior.

When I woke up the Minimote…

2018-07-01 07:38:07.735 [DEBUG] [wave.handler.ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 08 00 04 04 5F 02 84 07 29 
2018-07-01 07:38:07.735 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=95, callback=4, payload=04 5F 02 84 07 
2018-07-01 07:38:07.735 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[4], type=Request[0], dest=95, callback=4, payload=04 5F 02 84 07 
2018-07-01 07:38:07.735 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=95, callback=4, payload=04 5F 02 84 07 
2018-07-01 07:38:07.735 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-07-01 07:38:07.735 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 95: Application Command Request (ALIVE:UPDATE_NEIGHBORS)
2018-07-01 07:38:07.735 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 95: Node doesn't support WAKEUP - ignore wakeup
2018-07-01 07:38:07.735 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 95: Commands processed 1.
2018-07-01 07:38:07.735 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 95: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@6593c6af.

mhilbush · July 1, 2018, 11:45am

There’s still a check for the WAKE_UP class in setAwake?

github.com

cdjackson/org.openhab.binding.zwave/blob/6f5e97e690629d0569ba26d047a1397046b54520/src/main/java/org/openhab/binding/zwave/internal/protocol/ZWaveNode.java#L1356


 *
 * @param awake boolean true if the device is currently awake
 */
public void setAwake(boolean awake) {
    // Don't do anything if this node is listening
    if (listening == true || frequentlyListening == true) {
        logger.debug("NODE {}: Node is listening - ignore wakeup", getNodeId());
        return;
    }


    ZWaveWakeUpCommandClass wakeUpCommandClass = (ZWaveWakeUpCommandClass) getEndpoint(0)
            .getCommandClass(ZWaveCommandClass.CommandClass.COMMAND_CLASS_WAKE_UP);
    if (wakeUpCommandClass == null) {
        logger.debug("NODE {}: Node doesn't support WAKEUP - ignore wakeup", getNodeId());
        return;
    }


    // Create the timer if this is our first call
    if (timer == null) {
        logger.debug("NODE {}: Creating wakeup timer", getNodeId());
        timer = new Timer();

chris · July 1, 2018, 11:46am

This is now a different error - I’ll take a look at this…

chris · July 1, 2018, 11:49am

Yep - my initial change was ok, but it was caught by this one . I will remove this check - it should be safe as it should only get this far if it is a battery device (as there’s a listening check above). There may be some corner cases though where devices don’t listen, but also don’t support the wakeup class (I know there are one or two that strangely do this!).

Please try this.

Edit: Let’s see what you see with this - there might be another error I think (for sure you will have another similar error, and maybe even an exception for good luck!). I’m rushing as I’m about to go out - I really need to spend a bit more time on it either late tonight or tomorrow…

mhilbush · July 1, 2018, 1:33pm

Here’s what I’ve found so far. Results are mostly good.

Aeon Wallmote - discovered correctly and is working correctly
Fibaro Button - discovered correctly and is working correctly
Ecolink TILTZWAVE2 - discovered correctly and is working correctly
Minimotes - I have 3 devices with mixed results (I’m really starting to hate these devices )

– one was discovered correctly, and is working correctly

– one was discovered correctly, but is complaining about the COMMAND_CLASS_SCENE_ACTIVATION not found when I press a scene button. This one and the one above both report the same firmware version (1.19). There is no node.xml for this one either. I also tried to exclude/reset/include the node. I’m not sure what to make of this at this point.

2018-07-01 09:13:12.633 [DEBUG] [wave.handler.ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0A 00 04 00 5F 04 2B 01 01 00 81 
2018-07-01 09:13:12.634 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=95, callback=0, payload=00 5F 04 2B 01 01 00 
2018-07-01 09:13:12.634 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[4], type=Request[0], dest=95, callback=0, payload=00 5F 04 2B 01 01 00 
2018-07-01 09:13:12.634 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=95, callback=0, payload=00 5F 04 2B 01 01 00 
2018-07-01 09:13:12.634 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-07-01 09:13:12.634 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 95: Application Command Request (ALIVE:SET_WAKEUP)
2018-07-01 09:13:12.634 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 95: Incoming command class COMMAND_CLASS_SCENE_ACTIVATION, endpoint 0
2018-07-01 09:13:12.634 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 95: Command class COMMAND_CLASS_SCENE_ACTIVATION not found.
2018-07-01 09:13:12.635 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 95: Commands processed 1.

– one won’t discover at all. HABmin is declaring that the node is not in the Z-Wave network. I’m going to reset this device and re-include it.

chris · July 1, 2018, 2:14pm

Thanks Mark,
That looks pretty promissing.

We’d need to look earlier in the initialisation to see what’s up. It’s not completed initialisation yet, although it should have received the NIF so should know the supported classes already. This will be why it’s not saved the XML - it’s not finished the static initialisation (ie still at SET_WAKEUP).

mhilbush · July 1, 2018, 2:26pm

Agreed. Thanks for getting this sorted out!

I just restarted OH, so I’m going to wait a while for the zwave network traffic to settle down. Then I’ll do a delete/rediscover test on the 2 problematic Minimotes, nodes 95 and 96.

peter_oh · July 1, 2018, 3:22pm

I’m having trouble securely pairing a Schlage BE469. I tried a while ago with one that was already installed, but put it off until I got my second one so I could have it on my desk rather than on a door while debugging.
I’m trying a version posted for mhilbush yesterday
196 │ Active │ 80 │ 2.3.0.201806301554 │ ZWave Binding
I start the secure inclusion using openhab, and then start the inclusion on the lock itself. The lock shows an X to indicate inclusion failure. I did end up with a new node (NODE 27 in the logs below), but it’s not securely included, and in habmin, it’s just listed as “Unknown Device” with no Manufacturer, Type/ID etc (although it does show Neighbors and SPECIFIC_TYPE_SECURE_KEYPAD_DOOR_LOCK)

Here’s a log from the first inclusion (which was my first inclusion event since my upgrade from 2.2 to 2.3, so there is a lot of messaging. I had TRACE turned on when I was trying to debug my first lock):

Here’s a subsequent inclusion attempt:

Note that the lock itself thinks it’s not included, according to an on-lock procedure

Any tips on how I can proceed?