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

Tags: #<Tag:0x00007fd310f7db78> #<Tag:0x00007fd310f7da38>

(Chris Jackson) #3116

Please try the latest version and see if it helps.

(Mark) #3117
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 

(Chris Jackson) #3118

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

(Mark) #3119

Installing it as we speak…

(Mark) #3120

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.

(Scott Rushworth) #3121

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:]

(Chris Jackson) #3122

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

(Chris Jackson) #3123

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.

(Mark) #3124

Just sent the log to you in an email.

(borcon) #3125

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.

(Chris Jackson) #3126

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.

(Mark) #3127

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

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.

(Harry More) #3128

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?

(SiHui) #3129

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



(Chris Jackson) #3130

I recall recently someone else mentioned that their system was not polling, and there were no “channel linked” messages in the log. Maybe there’s an ESH bug that sometimes doesn’t notify the binding that a channel is linked?

(Mark) #3131

Yeah, I was thinking the same thing. Something that occurs on startup. Maybe a dependency issue, or a race condition… I looked through the recent ESH commits to see if something changed recently – no luck.

(Chris Jackson) #3132

From your log I don’t see any problem in the binding. It seems that you have removed the association -:

This will stop the device reporting.

(Scott Rushworth) #3133

There were several door sensors that were all cleaned up in the database. This involved changing some of their channels.

These changes also included adding the external switch. Great for use as a leak sensor, or with a pressure sensitive mat, or with a relay to make a dumb device smart, etc.

(Harry More) #3134

(Fibaro buttons)
Well it did before but, unless I’m doing something wrong, it does not any more. The scene IDs used to show up in the events.log just like the scene IDs of the keyfob did. Now, keyfob’s scene IDs do still show up, buttons’ scene IDs don’t. I haven’t check if the scenes would work though. Once I’ve noticed no reaction in the events.log, I just made the associations. As a side effect I hope it to be more reliable, as there will be no need to pass through the controller but they will talk directly to associated devices instead.

Is anybody aware of changes in Danfoss thermostats? Why do they keep displaying Error 5 * while the binding says all is fine? They did work surprisingly well before (some users found them unreliable or sluggish but I had no problems). Now they not seem to know which temperature they are set to… Any hints?

* E5 = “The thermostat is not receiving the expected replies from the control system”

(Scott Rushworth) #3135

Have you deleted and rediscovered your zwave Things after updating?