One of my sensors occasionally goes into a polling loop. I’ve so far disabled the poll after a command update in the device’s config, and have now moved polling from 1 day to 10 days, but once polling starts, it doesn’t stop. It’s a Steinel external motion sensor and relay, used to switch on an external light.
dbReference
630
defaultAssociations
0,1
manufacturerId
0271
manufacturerRef
0002:1A72,0002:6770
modelId
IS140-2
vendor
Steinel
It’s Node64 in the attached log file. When it goes into the loop, it brings my z-wave network to its knees and floods the logs very quickly. I’ve been through the log with the log viewer but as I don’t know z-wave to the depth required, I don’t know if it’s a config, device, setup or binding error. It does work absolutely fine until polling starts though.
If anyone has the time can you please cast your eyes over this and let me know your thoughts. I would disable polling completely but this doesn’t seem to be an option.
Log file attached with .xml appended to name to get around forum limit.
Of course now I see this… “Application Busy, try again later”. Not sure if it’s meaningful or not but it sounds like it is, I’m off to bed so will have to look it up tomorrow.
Seems to be OK now, after tracking down what endpoint 2 was (the one that keeps saying “try again later”) and finding it was set to send changes to an association which included the controller, I removed the controller from the association for that endpoint and the looping seems to have stopped. Polling every 10 minutes hasn’t provoked it into going crazy again so I’ll park this for now and keep an eye on it.
This issue has returned. Node 64, the steinel, is poll looping, despite the associations being set to just lifeline and switch (so I can see if the light is on or off). Polling is set to one day as that seems to be the longest I can set it for. Command polling is disabled.
What I suspect is going on here is that openhab is polling the luminance sensor (endpoint 2) but when there’s no light falling on it (luminance 0), it returns “endpoint busy”, I suspect this is the situation as the timing seems to match this, the poll loop has now ended after the light sensor sent a reading to openhab. From looking at my logs, the polling starts at about the same time every day (consistent with the polling period) and ends at the point at which daylight starts hitting the sensor (around 7:20).
Does anyone know how to stop polling on this device? It’s polling again and taking down my network, is there no way to stop polling for a device? Can I modify any XML anywhere?
I suggest to make sure that the database is correct and that channels haven’t been added to endpoints that don’t really exist. This is the likely cause of this sort of thing - although it shouldn’t report “try again later” in this instance!
It works fine once the device has been powered off, including polling, it’s when the device returns “APPLICATION_BUSY” that it just hits it with another poll message. Right now for example I can hit the “refresh” button in habmin and it polls the device without problems, but this only lasts for a while before I wind up having to yank the power out of the device again. Are the polls triggered by the binding or is it something the device is doing to create the polling messages?
This is the device in the database, I’m not sure how to check if the database is correct though, I don’t remember the documentation being exactly wonderful!
I can’t remember. @chris Does the binding not poll channels that aren’t linked to items?
If that’s the case, maybe you can delete the item that’s linked to that channel. I realize you won’t be able to use the luminance feature of the device. But, as they say, pick your poison…
I’ve got three channels mapped, one to the burglar alarm (endpoint 1), another to the ambient light sensor (endpoint 2) and a third to the relay (endpoint 3). I’ve got two association groups set, one to “group 1 lifeline” (although Habmin and PaperUI keep losing this) and another to “group 2 Control key” (to send back motion events).
The ambient light sensor is something I’m quite keen on keeping and the device works fine until this weird loop starts, why would the binding be polling a device every 5 seconds?
I’ll try asking the manufacturer (which never seems to go anywhere) but as I’m running snapshots to deal with other problems with openhab I’m trying to exhaust this first.
I’ve noticed that other devices in the past have been problematic with polling and have had this turned off in the database, maybe this is another one of them? There’s no real need to poll this one as it returns all its results to associations.
These polling loops go on for hours, a poll every 5 seconds for 4 or 5 hours seems like a bit of a standoff, if there’s a way to end it on one side quickly that would be helpful.
I’ve sent steinel an email with the device config, a snapshot of the log viewer and an explanation of the issue and am hoping they send me something other than a recommendation that I run their controller software or something like that!
It does seem that it should not behave oddly just because there is no light. One could imagine a device bug where the firmware is waiting for a reading from light sensor (and so rejecting polls).
I guess you could put a hood over it and get it failing, as an exercise?
I shone a torch on it last night to get a light reading but it didn’t stop the polling loop so that may have been a red herring. It’s quiet at the moment so I’m just trying to get various other problems sorted until this one re-occurs, or the manufacturer replies to my email, or someone comes up with something I can do. As you pointed out in another thread, there are other devices that have polling problems and were worked around by MiCasaVerde to take that into account.
I will take a look to see if I can limit this (somehow). We probably could set some sort of counter on the number of retries following the “Try Again Later” message and if we hit that count, we don’t send further requests for some period of time.
Thanks, I’m running on a virtual machine so can test things and rewind if needed so if you want to try a dirty proof-of-concept then let me know, although I’m away from mid-Sunday on work so might be slow to respond after that until I get back.
