[BUG] MyStrom motion sensor stopped working after update to v2.0.5 #152
Comments
|
I would assume you have set the motion sensor/plug-in to I see a connection to #151 here. 🙈 |
|
Update: After unplugging and re-plugging the motion sensor worked again. But only for a couple of seconds or minutes before the DEAD state re-appeared in the log. Now I notice the state is alternating between DEAD and ALIVE. When I access the API manually, I noticed it often takes a very long time for the page to load. Thus I guess the DEAD is because the timeout value gets exceeded. Not sure why the motion sensor suddenly doesn't work correctly anymore. Two things I can think of:
Because the motion sensor shows a very high temperature of 25.6° whereas it used to be around 22°, I tend towards 1. |
|
It's most definitely the polling then. Although it's supposed to only poll every five seconds or less often. Does the temperature improve if you switch to |
|
No POLL mode, I had it set to PUSH mode. Let me switch to POLL mode and see how that goes. |
Ah. With |
|
Yes, it looks like it gets polled more often. Issue remains with POLL mode. |
|
FYI: I downgraded to 2.0.0-nightly.0 and will let you know how the temperature goes. Any way I can see the polling logs? |
|
Now with the 2.0.0-nightly.0 the motion sensor also doesn't work. Temperature of the sensor went down to 24.3° (from 25.1°), which is still higher than it used to be. API now works without any problems, no long page loading times. In the log I see only the buttons mentioned: |
If you turn on the For the records: I've had implemented a So I removed that bit of code because of this in |
|
I've pushed a nightly to |
... and of course the 🤒 of your motion sensor ... 🙈 |
|
Thanks, installed. Sensor was first alive, but turned dead within a minute or so. Even the API is timing out when accessing it manually. FYI: I have PUSH mode enabled, maybe it's related? |
|
I noticed multiple log entries per interval: Maybe the new code is creating multiple requests per interval, essentially DOS-ing (denial of service) the motion sensor? |
|
😓 I'm actually right now working on a fix for that. Both the base class and the PIR class were listening to the |
|
MyStrom PIR: Stress test not passed 🤣 |
🤣🤣🤣 I should have accepted that offer of yours for a real PIR sensor ... (joke apart, apologies for the trouble caused and thanks for helping with getting to the core of this. |
The interesting (I dare not say fun) fact about this is: it's not the length of the polling interval, it's just two subsequent (almost parallel) requests to the PIR, every 10 seconds, that bring them to their knees. Speak of how hard hardware (and software) are ... |
|
No worries, I'm only getting picked on by my girlfriend because my smart home stuff never works resp. is not so smart 😢 Hm, so with [email protected] my PIR is still dead and I still can't connect to the API manually (timing out). Not sure if the device is broken. Gonna remove it from Homebridge and check via manual API requests if it comes back at all. |
|
Ok now it's getting strange. I still see the PIR mentioned in the logs, although I have removed it from the config and disabled auto-discovery. As you can see in the logs, the 15 seconds interval gets respected, but still multiple entries per interval. My config: Restarted Homebridge two times just to make sure. |
Ah, the famous
|
Did you remove the accessory from the accessory cache in Homebridge (In Homebridge Config UI X settings, "Remove Single Cached Accessory") and then restart Homebridge? If you just remove it from the config and turn it off, it will still be remembered by HomeBridge which will try to reach it. The logs you see look exactly like that (and since you unplugged it, the host can not be reached at all).
|
I know WAF, but what's GAF? 😄 Cache it was. Thanks for the hint, wasn't aware of that setting. The good news is: The PIR came back once it was removed from Homebridge. UPDATE: I rejoiced too soon. The PIR is now not reachable via API. So it seems the PIR really is somehow broken. Unless there are still requests happening in the background which I can't see, causing a DOS. |
|
GAF: Girlfriend Acceptance Factor. 😄 One question: In which sense do you think/see the |
|
Not sure how to turn on DEBUG. In the UI on the top right menu when choosing 'Homebridge Settings' there's a text field FYI: I stopped the Homebridge service for a while and the PIR came back without DOS. Then I re-enabled the Homebridge service (with the PIR still removed from the conf) and the PIR is still responding and has a normal temperature. |
Just above should be the Homebridge Debug Mode switch. Turn that on, restart Homebridge and your log should show all the
|
|
Ok I'm officially blind. Here's the logs: Please note how the device went dead for two intervals. More importantly, my Homekit rules are not reacting to motion. The motion is visible in the API when requesting manually, but no mention of it in the log. Maybe the PUSH is not working? I'll switch to POLL mode and see how that goes. |
|
Here's the log with polling enabled (removed the log entries containing Now I can see |
|
I'll have to call it a night soon but one thing you can look out for: the If you lookout for "Callback URL" or "callback" in the log (which you can download, btw), you should see it if Debug output is enabled. For example: If you open http://192.168.1.137/api/v1/action/pir/generic (provided it works) you should see the current value. It should look like something like this ( {
"url": "post://192.168.1.111:18081/button",
"feedback": true
} |
|
Turns out the Homekit rules where not there anymore. The must have been deleted when I updated to v2.0.5 today, because they where still working last night. Is that possible? Added a new rule and in POLL mode it's working.
I now added the Homebridge IP to the callback setting because I think the hostnames don't work in my network. Unfortunately the PUSH mode is still not working. No signs of a motion detected in the log and also my new Homekit rule doesn't get triggered. Also the value of Anyway, thanks a lot and have a good night! |
|
Glad to hear you found the culprit. I don't know yet under which circumstances a device is forgotten in HomeKit but once it is (e.g. because it was removed from the cache), HomeKit will forget the rule most probably. For the push: this is weird, it's working well for me for the dingz. I just ordered my own PIR sensor, it's bugging me too much and we're both loosing too much time to fix this with my half-baked mock device (esp. as the half-baked programmer I am 🤣) vs. your real device. 🛌 well too. |
I had missed that completely ('t was too late that night). Got my PIR in the meantime and obviously had no |
|
Thanks for the update (and purchasing a PIR 😄). I updated to 2.0.7-nightly.3 and now the PIR shows always Log: UPDATE: And now when I triggered the PIR (and the LED on the PIR turned on) the state of the PIR in Homebridge changed to not triggered. So it's essentially inversed. |
|
The PIR starts going DEAD again. And when manually making API requests the loading time is very long. @johannrichard Don't you run into these problems? |
|
@qx54 I wish I had the same problems. Unfortunately I don't. The API reacts as expected. What I observed: the status page ( I have started w/ FW |
- both the PIAccessory and BaseAccessory were listening to `REQUEST_STATE_UPDATE`` - this lead to two *very* rapid subsequent calls which brings *real* PIR sensors to their knees - (also) fixes #152
|
I've not had any serious glitches with any of the latest nightlies (or even after we fixed the double-polling), running them over longer periods of time, on three different platforms/servers simultaneously with my How's your I can also suggest we do a |
|
I had the PIR unplugged for the last few days and had plans to test it with the latest working version of the plugin which was 1.8.3 nightly. Also because the buttons can't be used with the current response time of approx. 7 seconds. Do you suggest I give 2.0.7 or 2.0.8-nightly.1 a try? |
|
I would recommend you go with PS: I didn't think much of that before but obviously there are a few simple It only occurred to me lately and I haven't done any tests yet but will do so. |
For example |
|
Installed 2.0.7 for a while and the PIR worked but the buttons still were very slow. I think it's faster to go back to v1.8.3 and see how the buttons do. If they're still slow, than it's the firmware because that's the only thing that changed. EDIT: Buttons are still slow in responding with v1.8.3 while the PIR works fast. I tend to believe it's the firmware. Because when I got the 2nd button recently, I updated the firmware and installed it but it was noticeable slower than my 1st button. I postponed the debugging and forgot about it. Later I updated the firmware of the 1st one and now both are super slow. So I'm very confident it's the firmware. Do you have a MyStrom button with firmware 2.74? How is that working for you? |
|
All my buttons have firmware 2.74 already (🙈) and they have noticeable delays. With the Obviously, if you have multiple local servers (e.g. for debugging) and one of these is slow/not responding, that might also impact the speed. Or if you use hostnames instead of IP addresses. In the meantime, I have done some debugging and I have introduced a setting in the plugin You might give it a try, I have been running it in my environment for some days in different configurations. And just for fun (as I discovered it only recently), you might want to give HomeManager (3.0 Beta) a test run as well. See this article for details: it makes running/managing a Homebridge instance really easy and fun. |
|
Thanks for the details, it looks like it's definitely a myStrom issue. I have only one server and use IP's exactly for this reason. Also because one button was slow and the other fast before I updated the 2nd one as well it's quite obvious where the problem lies. I'm not following you, what do you mean with that:
Re HomeManager: Thanks for the hint 😄 |
The If you have a test server that's only running from time to time its configuration will still be configure and hence the requests will take a long time. By setting the override option on your main server (but not on the test server) you can ensure that the URL's are reset every time your main HB server is restarted. BTW: Can you let me know if the newest versions (either @beta or @next channel) work now for you too? On my side, I have consistent good and reliable results so far. Thanks. |
|
It's been a while since I've published updated versions of the plugin. In my case, the PIR motion sensor worked "as expected" (but of course I might have missed some edge cases): I will therefore close the issue. Feel free to reopen a new one in case you use the plugin with the PIR sensor and experience problems. |
|
Hi @johannrichard, sorry I somehow missed your previous message resp. forgot to get back. I gave up on the PIR back then, although I don't remember the exact reason anymore. For the super slow buttons it turned out the firmware is coded in a way that upon a button press it first tries to connect to the cloud and only after that to the Homebridge. For some reason the cloud domain doesn't resolve in my home, thus the local action was only executed after a hard-coded time-out which is 8 seconds if I remember correctly. I removed the buttons from the cloud and it's working more or less, although in approx. 10-20% the button won't work properly. Long story short, I'm not happy with the MyStrom devices. The didn't pass the WAF nor my own acceptance factor ;) |
Describe the bug
I just updated to v2.0.5 and the MyStrom motion sensor stopped working. The log is getting flooded with entries:
To Reproduce
Steps to reproduce the behavior:
[myStrom Motion Sensor] DEADentry in the logExpected behavior
Motion sensor should be working and not be marked as DEAD in the log.
The text was updated successfully, but these errors were encountered: