Cover does not accept commands from HA (only one-way communication) #32
Comments
|
Debug logs for 5 in original post: |
|
Update: Removed the power source for that RolloTron device for a few seconds. After that, it is working again (can be fully controlled from HA). Of course distance from the stick to the device has not changed.
Interestingly, there's absolutely no difference to the device state dump taken before the power cycle. As it is working again now, I tend to quickly close this issue, hoping it was a one-time thing (not experienced once the last years). Last thoughts:
|
|
I did not see this issue again and wanted to close it before I discovered 3 remaining questions where 1 and 2 of those might help to troubleshoot this issue in case it would happen again in the future. |
|
Update: this issue happened again during the last months. The times I noticed and documented it are:
Always the same symptoms:
Details:
As this issue occurs more frequently recently creating serious real(-life) issues, I want to draw attention to it (@gluap I noticed you didn't even respond to this issue since 2023-03-24 😞) and sort it out finally. [*1] |
|
@bcutter sorry for not responding earlier, let me address that:
Regarding the new question. |
|
Sorted out those ghost devices meanwhile mainly (#36), thanks.
I don't like that approach. Every downtime is one too many. And working around things (with a restart) is not a permanent solution - it does not fit in a stable environment approach (the one I aim at).
That's a native thing, like the one you discovered a few hours ago with the deletion of devices from the device registry. Here's one example from another device connected to my HA server in the very same way the duoFERN stick is connected (so: yes, also working for hardware based integrations):
If I would need to restart HA Core everytime a simple reload (nice: can be scripted as it's a default HA service) of the deCONZ integration was needed... a nightmare. Happens not often, but reloading takes 5 seconds, restarting HA up to ten minutes ;-) |
|
@bcutter I added the reload facility. It was a bit harder than the device deletion, as the developer documentation really isn't very transparent about how this should be implemented. Or at least it's not very transparent to me. With 10 minutes for a homeassistant restart, I can see why you want to avoid it, my homeassistant takes 20-40 seconds for a restart, so I thought calling reload vs restart was mostly cosmetic. |
|
Awesome! Will give it a try asap. Let's keep this issue open until the next incident, hopefully reloading the integration can fix (easier work around) the issue. You're < 1 minute?!? Wow. Getting off-topic but really curious what hardware and setup (HA OS, container, supervised) you use. I need to carefully plan restarts (restart party's definitely need some kind of maintenance window) as during that (down)time of course almost nothing works in the smart (in that period of time: dumb) home. |
|
I'm running HA core on raspberry pi os / raspbian bookworm on a raspberry pi 4 (4Gb version) with an SSD (as opposed to sd card) as the main disk connected via USB3. What are you running HA on? Main issue with my setup is that because I'm running ha core it's a pain to get the I've been thinking about switching to supervised at some point because it would make setup of addons possible. But I'd have to migrate my grafana for that and am not very keen on doing that. |
|
Ah I got it. I guess it's the SSD - seen a stunning performance boost switching from SD to SSD on my other Pi's. Currently running HA with HA OS on a Pi 4 8 GB version (completely oversized in terms of RAM, but who knows which handy addons will cross my way in future). Using a long-life SD card for few years now. Thought about switching to SSD many times, migration failed plenty of times (power issue or USB 3 issue or...) AND the guaranteed amount of problems people have after every HA OS / kernel update running their boot disc on a RPi from SSD keeps me away from finally doing the migration. It will probably be the compromise way: leaving the boot data on the SD card and only exporting the data to the SSD (which is a two click action from the UI, thanks to HA OS - at the same time it's a one-way action and as the system runs so stable... never change a running system, right?). For me there's no alternative to HA OS, very comfortable. Maintaining the underlying OS on my own (in addition to all the time invested in the HA Core application and integrations and UI etc.) simply takes too much time (like I need / still and will do for other projects) and adds other issues as well (like the stream integration thing you mentioned or taking care of compatibility issues like python updates etc.). |
|
FYI, back on-topic: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since running 0.4.1 (0.4.3 currently) of duoFERN, one of my covers started to have issues. Immediately after updating duoFERN, it was not closed automatically (using an automation firing cover.close_cover to a group of all covers).
The last days it worked, I'd say, unremarkable reliable.
Now I can not control it anymore (at all) from HA, entity state stays in "moving", potentially waiting for the device to perform/respond. Steps:
service: duofern.sync_devicesand surprisingly got two new entites where I have absolutely no idea to which devices they might belong. I suspected maybe the not working cover would be one of them, but that's not the case. Any idea? I think I'll just disable those two as they seem to be not related to this issue at all. Side-story, but wondering anyway.service: duofern.dump_device_statewhich gave (only relevant deviceXXXXXX):(had to split this log - see next comment(s) - as GitHub was complaining...)
Note I sent few moving commands (open, close, set_position) to the cover during that time. I guess/hope usually there's not that much communication going on in the back.
Any idea what happened here? Really strange, to sum up:
The text was updated successfully, but these errors were encountered: