Since the transmission of the SWITCH_MULTILEVEL_GET is almost exactly 1.5 seconds after the original OFF command was sent, I believe this is the response to the command repoll that we’re seeing. In this case 1.5 seconds may be too short and the light may still be transitioning from its previous state to OFF. Try increasing the Command Poll Period period – maybe 3000 milliseconds. You’ll find this parameter in the Device Configuration panel in HABmin.
2 Likes
I think you are right.
I found that the dimming time is set to 3 seconds (between min and max), so going from ON (100%) to OFF (0%) and polling after 2 seconds is causing this problem.
I could be wrong but it seems the correct polling interval could be calculated based on:
<dimming time> * <current %> + <polling command time>
Hi @chris
There is absolutely an issue with something in the zwave network with respect to devices losing the Association group and here is the log to prove it, hopefully.
I came home around 10.50pm, somewhere around there.
In the logs NODE 8, the motion sensor triggered NODE 4, the Back Eave Light Dimmer.
I noticed after a few minutes after inactivity, the light did not switch off. Upon checking HabMin, I noticed Node 4 association to LifeLine NOT set. It was set for Node 8, the Aeotec Multisensor Motion sensor.
I changed using Habmin Node 4 to LIFELINE under association groups. Almost immediately, the light switched off. I had debug running the whole time.
Apologies for the file, ive cut it down ALOT (theres more if you need it) but I believe this would have captured, the resetting of the lifeline and the light going out.
Hope this helps put to bed the issue or work out whats going on!
https://drive.google.com/file/d/1CN9yUV1k0qQ7abVNOxkxv6LreAS30lNW/view?usp=sharing
Cheers
Kris
At the moment I can’t access the log - hopefully over the weekend. Does it show WHY the associations are not set? It is no good showing that there is no reporting - I must see where the association is removed otherwise it is of no help.
In theory with the 2.5 binding it should not be possible to remove associations, so it’s really important to show where it is being removed (sorry - I know I keep repeating myself here, but so far I’ve not seen logs that show associations being removed under the latest binding).
sorry I can not be helpful with a log here.
but I also see devices on 2.5 snapshot that stop sending messages to the controller until I set the lifeline again.
if I catch something in a log I will of course post it.
Hi chris ive got logs back to when it was working. Does it show it being removed i dont know. I dont have the skills to determine that but ive got logs of it working and then it not. The whole log is 10megabyes and would span at least 24hrs between it working and not. If you want that log let me know and ill put it on google drive. Cheers
I’d suggest you post the file. It’s pretty easy to see what associations are being set/removed using the viewer. When you post the file, also make sure you state which node you believe is having the problem.
Sure,
here it is. As mentioned previously In the logs NODE 8, the motion sensor triggered NODE 4, the Back Eave Light Dimmer. Those are the devices that may have had their association lost or at least are problematic
https://drive.google.com/file/d/1eZQbMnE_DlbcUPOzSxsK3CEdE7fK1pOQ/view?usp=sharing
There are no signs of any issues in this log - the only two association commands in the log are just reading the state of the associations in node 4. It shows that node 4 is linked to the controller.
One thing I noticed, which looks odd, node 4 starts spewing reports at the rate of 1-2 per second starting at 22:58:25 and ending at 23:09:22. This doesn’t look normal to me. Have you tried excluding node 4, doing a factory reset, then re-including?
Hi Guys
I havent done that Mark as its been working fine otherwise.
H Chris, you looked at the large 10mb log? or the small one.
Cheers
The large one.
1 Like
Very odd that the fix being right or wrong was to reset the lifeline. Makes it hard when the gui doesnt show it to . Maybe ill try a reset as Mark suggested
Maybe - I don’t know. You need to provide a log that actually shows the problem. This log doesn’t show any associations being set - either correctly or incorrectly. It does show an update to the configuration of one of the nodes, but this doesn’t change the associations as it was already set correctly.
So, either there really was no problem, or this log just isn’t for the right time period. Please make a note of the times that you do things so I can correlate this.
Ok. Thats almost impossible to do because who knows when it breaks. It worked the previous night then failed the next. If it happens again ill post another log. Thanks chris
I’m sorry, but without a log, it really is not possible for me to a) confirm that there is really a problem, and b) find what the problem is.
Please just keep logging enabled. Then, when you discover that it is not working, either provide all the logs, or try to find when the binding sent the association commands yourself.
I would really appreciate it if you can try to find the time it changed. It shouldn’t really be that hard (and certainly not impossible as you think!). I’m assuming that this is happening quite regularly, so you only have to search a few days of logs, and just grep for association commands.
No troubles Chris, ill do that!
It doesnt happen that often, didnt last night. Ill keep an eye on it, debug is now running constantly.
1 Like