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

So I think we should restore the NOGET setting to the database, if for no other reason than to eliminate that as a variable.

Yes, I just did a restart of OH with the latest binding – 2.4.0.201807021829.

As an aside, it is odd that after a restart there are so many nodes that come up dead, then after a while all is good.

Done.

I’ll modify my device XML (in the jar) and see if that helps before making the change in the db.

I’ve finally had the chance to look at this log, and I would agree that at least the first issue is it’s not responding to the WAKEUP_GET command… Since you’re already working to remove that, let me know how it goes…

I’ve updated the DB – changed WAKE_UP config from ADD to NOGET.

I built a jar, reversing the changes from here, and it made it past SET_WAKEUP, but seemed to get stuck at GET_NEIGHBORS. This is strange because this device is a secondary controller. After restarting OH again, the device completed initialization, but I am now getting this when trying to use it (SCENE_ACTIVATION is also missing from the xml)…

2018-07-03 16:38:35.541 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 212: Incoming command class COMMAND_CLASS_SCENE_ACTIVATION, endpoint 0
2018-07-03 16:38:35.541 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 212: Command class COMMAND_CLASS_SCENE_ACTIVATION not found.
2018-07-03 16:38:35.542 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Commands processed 1.
2018-07-03 16:38:35.542 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@7e8ed6f3.
2018-07-03 16:38:35.542 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Checking transaction 635  null.
2018-07-03 16:38:35.542 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Checking transaction : state >> ABORTED
2018-07-03 16:38:35.543 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Checking transaction : node  >> 112
2018-07-03 16:38:35.543 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Checking transaction : class >> 43 == null.
2018-07-03 16:38:35.543 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Checking transaction : commd >> 1 == 0.
2018-07-03 16:38:35.543 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Ignoring transaction since not waiting for data.

Please try the latest version and see if it helps.

2018-07-03 16:38:35.541 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 212: Command class COMMAND_CLASS_SCENE_ACTIVATION not found.

Yeah, I’ve seen this a few times. LOL

On a more serious note, I don’t see how it adds SCENE_ACTIVATION from the NIF if it hits the COMMAND_CLASS_MARK (0xFE) before it gets to SCENE_ACTIVATION (0x2B). Unless it gets added somewhere else…

2018-07-02 12:26:41.866 [DEBUG] [wave.handler.ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 12 00 4A 67 02 60 0B 01 01 01 86 72 70 9B EF 85 2B 26 D0 

Agreed - as above, please try the latest version and see if it helps…

Installing it as we speak…

Good news. I was able to discover one of the Minimotes, and the SCENE_ACTIVATION command class now works correctly. But, it hasn’t generated a node.xml yet, and seems to be stuck at STATIC_VALUES.

I’m having trouble with another one, but I don’t think it’s the binding. Pressing a scene button doesn’t generate a message to the binding. I think this one is in a funky state given how much I’ve been messing around with it. I may need to reset it and re-include.

That’s got it! I’m curious to see what special sauce you used on it. Thank you! I did notice this (completely unrelated)…

2018-07-03 18:14:23.221 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 212: Initialising Thing Node...
2018-07-03 18:14:23.222 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 212: Initialising cmd channel zwave:device:07cb40a2:node212:scene_number for DecimalType
2018-07-03 18:14:23.222 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 212: Initialising state channel zwave:device:07cb40a2:node212:scene_number for DecimalType
2018-07-03 18:14:23.229 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 212: Initialising state channel zwave:device:07cb40a2:node212:scene_number for DecimalType
2018-07-03 18:14:23.230 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 212: Polling intialised at 1800 seconds - start in 511200 milliseconds.
2018-07-03 18:14:23.231 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 212: Device initialisation complete.

This was received while I was waking the device up while it was in the Inbox, so that the manufucaturer info would be detected. It’s odd to me that the channels would be initialized before the device was, and before the device was approved from the Inbox…

Did you delete the Thing and rediscover? [That’s officially my new motto :rofl:]

Can you send a new log please? Preferably by email if possible…

I just added the (so called) control classes as well. This hasn’t been needed in the past, but now is due to other changes.

1 Like

Just sent the log to you in an email.

@chris
i think you have some problems with the lifeline group.
I have made a hard reset of my z-wave usb stick, removed the z-zwave stick thing, added again and then tried to a add two wallplugs from fibaro and coolcam.
After the inclusion process, the current switch state and powermeter were received once. But now if the powermeter or switch state is changing, openhab will no longer receive any updates. I tried to set the lifeline in the parameters of the wallplug, but this does not help.
I have no errors in the log.
I hope you have some ideas to solve this.

I don’t believe there is a general problem with lifeline, so you’re going to have to provide information about your problem…

Please check the logs to find out what is happening. Please also advise what the device is - it’s hard to comment without logs and basic information on the device - sorry.

For a couple days now, I’m not seeing any of my nodes being polled. For example, battery levels on my battery-powered devices haven’t updated in a couple days.

All I see are these lines in the log.

2018-07-05 09:38:56.866 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 79: Polling...
2018-07-05 09:43:03.233 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 52: Polling...
2018-07-05 09:44:19.312 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 43: Polling...
2018-07-05 09:45:02.444 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 45: Polling...
2018-07-05 09:46:12.592 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling...

Normally I would see each of these lines followed by the specific channel(s) being polled.

The channels definitely are linked to items.

I don’t know what to make of this, as I didn’t think this area had changed in a long time.

I’m on OH build 1308 with zwave 2.4.0.201807032158.

Edit: This is really strange. I edited my zwave items file (basically added a blank line and saved). I got all the expected “channel unlinked polling stopped” / “channel linked - polling started” messages in the log, and polling appears to be working again. What’s odd is that I have no “channel linked - polling started” log messages at startup.

Edit 2: @chris I saw this again running build 1502. I noticed that only one of my 13 devices was being polled (the lack of any battery updates is how I first noticed it). When I looked in the log, I saw that only one node had any Channel *** linked - polling started messages at binding startup. A stop/start of the binding fixed it. I suspect there is some type of timing issue at startup where the framework is not calling channelLinked for every item that’s linked to a channel.

Thank you @sihui. After I updated to newest snapshot I could install dev version of the binding and I’m running the 201807032158 version ATM, and I have 2 remarks and 1 question:

  1. The binding doesn’t seem to receive a scene numbers from Fibaro buttons however - not in the events.log at least ( parameter 1 in configuration is set to 127 - all scene IDs should be sent).
    Keyfob (also Fibaro) works straight ahead as it used to.
    It’s not a big deal for me because I managed to use associations for all I needed, but I thought it’s better to mention in case it’s important. (@chris you’re awesome btw :slight_smile: )

  2. Aside from that 6 of my 7 Fibaro door sensors changed their channels from sensor_door to sensor_binary, which required some reconfiguration.

  3. All my Danfoss thermostats configure well, but they all display E5 after a while, which seems to be a communication problem. Habmin however doesn’t seem to notice that. 2 or 3 of 6 altogether are being initialised. I can’t say if they work now, as it’s summer where I live and the heating is turned off elsewhere. Is there something I can / I should do about it?

openHAB 2.4.0 Build #1307

If there’s “build #” on the bottom of the screen, does it mean it’s SNAPSHOT? I have an OpenHABian running elswere and it says “Release Build” - does it mean STABLE?

I don’t have one but I guess it should work like all other Fibaro devices:
link a Number item to the scene_number channel and catch it in a rule like Item FibButton_Scene received update XX

Yes.

Yes.