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

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.

1 Like

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.

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?

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.

1 Like

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.

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.

(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ā€

Have you deleted and rediscovered your zwave Things after updating?