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 ]
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.
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:
-
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 ) -
Aside from that 6 of my 7 Fibaro door sensors changed their channels from sensor_door to sensor_binary, which required some reconfiguration.
-
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.
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?