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:
-
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.
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?
I’m guessing that this is a configuration issue of the device if it’s not sending the data. I don’t know the device, and haven’t looked at the configuration to try and work out how it works, but if it’s not sending data then it’s not likely to be a binding issue directly at least.
What devices are these exactly? There are 4 Fibaro door sensors in the database. I looked at the first, and it defines both channels - to work out what’s happening, we’d need to know what version you have.
I don’t know what causes this. I know it means the device hasn’t communicated with the controller, but I don’t know exactly what triggers it. If someone knows, then we can look at it (I do recall some disucssion on this in the past, but I forget the outcome).
I didn’t remove the assosciation. I definitly changed only the Location in the paperui. But all settings are sent.
So maybe here is the problem.
From the log, the association was removed. The binding doesn’t do this unless requested from the UI - it doesn’t just send configuration for no reason. Either it comes from the UI, or it is initialised during the initial configuration of the device (which isn’t the case here I believe).
I tried to check the log you sent, but it doesn’t have enough information as the first entry is the command to set the association group - we’d need to see what happens before the command is sent.
What do you mean with “we’d need to see what happens before the command is sent”?
There was only the inclusion process first. After inclusion, the lifeline was ok. Change the location in paperui was the second step which removed the lifeline. I could set the lifeline in paperui and it does work, but if i change any wall plug setting again in paperui, the lifeline is removed again. The zwave binding needs a restart and then i can set the lifeline again.
If i edit the fibaro wall plug, the group 1 in paperui is always empty.
Something triggered the command - it didn’t just send by itself. The very first entry in your log is the sending of the command - to work out why it was sent, we have to see earlier in the log.
Yes - so we need to see what happened here - this is my point.
Ok, so here is where the association was removed then - I think this fully explains why the association is removed at least.