I’ve been noticing this random and intermittent issue and have been trying to determine what and why it is occurring. I have 2 tablets running Imperihome. The tablet screens will go to sleep after 5 minutes of inactivity, so every 4 minutes I send an API string via URL to the tablets to keep them on their main screen, and keep them awake. The Condition is true to send the API string if there is motion detected. However if there is no motion from the nearby motion sensors, I do not send this API string and the screens will fall asleep.
What I have been noticing is that the API string sent via a luup.inet.wget command stops working after an unknown amount of time, or unknown # of pulses. The only way I know how to reset the issue is to “restart” the reactor sensor. I am only experiencing this issue on the downstairs tablet. I know it is not Imperihome because I can tap on the screen and it wakes up. But it will fall back asleep after 5 minutes.
I have been watching the Status of the conditions within the Reactor and they all look correct, with the exception that my Pulse for X timer seems to be re-tripping way to soon. I can watch my “pulsed x times” increase multiple times within a minute and my pulse for is 245 seconds. Just in the last minute it went from Pulsed 151 times to 158 times.
I captured three logic summary logs. One before I restarted sensor, one after I restarted, and again
about 12 minutes after the restart. I have a feeling this may require a debug, so please let me know what you would like Rigpapa. I emailed these reports to you. This issues occurs at totally random times. Sometimes I can go for a week and not have to restart my Reactor sensor, sometimes I have to restart it ~12 hours later. I had this issue yesterday afternoon and then again this morning. But the last time I noticed it was maybe last weekend? It had definitely been a while.
TIA
–Matt (3rdStng)
Best time to capture the Logic Summary is when/after you think the tablet is not being contacted. If you think the pulse timing is off, post a Logic Summary that shows that. Looking for your reports now.
OK. So everything looks fine operationally in what you’ve sent. The pulse count being off is a display bug cause by excess evaluations from the motion sensor repeatedly reporting and causing re-evaluations, but the timing shown in the events is holding true, and the action is being run when expected. In the “after 12 minutes” file, look at 10:12:44 and 10:16:44, all good, and no excess requests.
I’d look in your LuaUPnP.log file, find the “wgets” and see what they might be logging. You’ll probably want to do that when the tablet misbehaves.
Thank you for looking into this.
Would it be better to do a HTTP post or something better than the wget Luup command?
It just happened again. I grabbed a new Logic Summary about 5 minutes of the tablet being asleep. The Pulsed X times was 164 at the start of this post and now at 179. Not sure if the count matters or not. but I’m trying to find anything that may be the same when I notice the issue.
I looked through my LuaUpnp.log file too and there is nothing in regards to “wget” or any variation of the luup.inet.wget string. I can email the new logic summary and LuaUpnp log over if you like.
Long shot, but can you go into the Backup/Restore tab of your Reactor master device (blue icon) and click the “Plugin Status” link in the footer, and email me that output as an attachment.
Sent.
Of course I “Restarted” the sensor shortly after my previous post. What I thought about later on is if this is due to a LUA engine reload or something. I’m happy to move away from the luup.inet.wget command if there is a better way. I tried using the HTTP Post option, but it didn’t work. Which was probably in error on my side.
OK. All normal, but it occurred to me… maybe there’s a misunderstanding about the way the logic will actually work. Do you understand that if there are repeated motion events during the 225s timing period, that period is not extended? The pulse is fixed to the set period, and once it starts, it will be neither longer nor shorter than the configured period. That means if it gets through 200s of your interval and there’s a motion pulse (motion sensor trips and then untrips), then 25 seconds later when the timer expires the underlying condition is false and the pulse train stops. Somehow I’m thinking this isn’t what you actually want.
I get that the pulse will not be extended. It is mainly set this way to keep the sensor tripped. I know it is a cosmetic thing, but when the sensor is active, I wanted the icon to show tripped (red.)
My understanding is that as long as the conditions under that group are met, the pulse will keep the sensor tripped for 225s. Then there is a 15 second pause, in which the sensor will revert to untripped. However if the conditions are still met, it will pulse again for another 225s and send my luup.inet.wget command to keep the tablet awake. The 225s plus 15s = 4m. So the API string is sent to my tablet every 4 minutes, providing the motion sensors around are still tripped. Just 1 minute sooner than the 5m mark where the Imperihome screen will sleep itself due to inactivity.
1 - Item is true and the tablet is awake displaying my home screen, which is a clock and the inside/outside temps.
2 - Tablet is asleep because there is no movement upstairs.
3 - Either 1 or 2 are tripped, so my sensor icon is red and visually showing me that this sensor is active and running.
Is my thought process completely wrong?
OK, but the thing is, motion sensors typically send a brief pulse when they sense motion–they go true, and then go false. They tend not to stay tripped for long, unbroken periods of time (YMMV with config, but this is generally the case).
Edit: if it’s not otherwise clear what I’m getting at… it’s possible, even likely, that “stimulus” from the motion sensor can come at any time, even right at the end, of the long phase of the pulse. If the motion sensor resets before the end of that phase, the pulse train will stop and the wget will not happen, even though there was motion perhaps 30-60 seconds before. What you really need, IMO, is to use a “delay reset” on the motion sensor condition and the group containing the multiple sensor conditions, and I would set that as long as you want the “presence timeout” to be. It’s really separate timing from the pulse train–the pulse train is trying to meet the requirements of the tablets, but presence may need completely different timing based on how the room is used (e.g. if people sit quietly a lot, a longer duration is needed).
