Occasional issue with actual cover state (open/closed)

[mmatesic01]

Hi. Occasionally it is happening although my cover closes or opens, for that matter it actually does not change state in Home Assistant or it flips the state, such as when physical cover is closed in HA it show that it is stated as opened. I press to close it in HA and it starts physical opening the cover, so it works vice-versa. I have two Duofern cover motor belts and this is happening on either one.

[bcutter]

Glad to see I'm not the only one. I'm seeing this right since the beginning, sporadically on few of my devices.

I talked to gluap bout this a long time ago, the idea was it depends on the range from the DuoFern controller to the devices. I could never neither confirm nor falsify that theory.

Instead, I added several workarounds in HA. Those are all based on the simple fact, that running the cover.stop_cover service (like pressing stop button in the UI) actively triggers a status update. So in my scripts and (remote control) automations I added some wait delay after opening/closing shutters and run that service afterwards.

Overkill but very good workaround is an additional "DuoFern Fix Device Status" automation which triggers that service run based on motion/door sensors etc. within a certain time period.

With all those workarounds it's pretty reliable meanwhile - but not very comfortable from an HA administration point of view.

Unfortunately I have no debugging skills (Don't devices send a status update when being controlled locally? Or does the DuoFern controller not receive it? Or does it receive them, but isn't processing it right? Etc.).

[mmatesic01]

Hi bcutter,

Well, its also been bugging me for a long time. I also tried with additional delay afterwards but with cover position service. As far for the range my DuoFern are 5m or less away from the HA with DuoFern antenna. I had no such problems with using https://github.com/gluap/pyduofern, but with older version. I think lower than 0.27. NOis w is version 0.34.

I'll try your solution with cover stop service and see how it acts. Thank you for the advice.

[bcutter]

Meanwhile I've got a fully packed automation taking care of the missing updates of cover states. Only a workaround but covers most (at least the important) cases.

Not sure if this integration can do something bout this.

[gluap]

I added a polling=True property to the entities in v0.3.1 (beta) and at least for me it reproducably shows the current state of the cover within 30 seconds (which is - I think - the default poll interval in homeassistant).

[bcutter]

I added a polling=True property to the entities in v0.3.1 (beta) and at least for me it reproducably shows the current state of the cover within 30 seconds (which is - I think - the default poll interval in homeassistant).

Thanks! That sounds very interesting. Didn't know it does not poll :-D Two questions: 1) Will that in the end mean that every 30 seconds (default HA polling intervall) the duoFern Stick will check all connected duoFern devices? 2) I didn't try the beta release (0.3.2) yet. But will it allow to select on our own if we want the integration to poll at all?

Currently with latest stable release:

Compared to other integrations:

[gluap]

In this case the stick won't be doing anything differently. Pyduofern runs in a background thread.

Just homeassistant will every 30 seconds copy the state of the shutters/blinds from the storage of the pyduofern thread variables to the storage of the homeassistant variables.

The reason ist is that I believe that the "push" to homeassistant sometimes did not go through. This would be in line with your automation successfully polling the state.

It should only be a few bytes of data being copied extra every 30 seconds.

I didn't know about that button in hacs, but my guess is that the config button is some extra that has to be added to hacs configuration - and might configure some active polling (like sending a "what's your state" message to devices vs just copying data that is already there).

[bcutter]

OK, I was just thinking of unexpected radio activity (duoFern protocol) every 30 seconds. But if that polling is done just internally and not from the stick to all devices I'm fine - and looking forward to see if it makes any difference (I can disable my status fix automation).

[bcutter]

@gluap when you think the pre-release https://github.com/gluap/pyduofern-hacs/releases/tag/v0.3.2 will be stable? Do you have enough tester feedback (or whatever you use as "confidence meter"/trigger to release new stable versions)? :-)

[gluap]

It's out now. There was no feedback whatsoever. But at least I know it was running for me all that time.

[bcutter]

I now updated (restarted HA Core to load the new updated version) to v0.3.2 and disabled all my workarounds in automations and scripts for now.

✔ Tested a bit with local updates (opening/closing covers with local buttons) out of HA control and those status changes almost immediately updated in HA.

❓ Will monitor things for a while (at least 1 to 2 weeks) to see if it really (fully) fixed this issue (and if there are any side effects).

[bcutter]

After monitoring this for a few weeks, I must say:

From time to time the status is still not reported in time. Sometimes it never triggers an update, I have 9 incidents logged.

Curious to see if the newer releases maybe improve this?

[gluap]

Today I had the issue massively - no cover states were being reported at all (for some weeks, but I put that down to me having to restart homeassistant). I coded around to try and fix it. Lo and behold - In my case there seems to be a new source of RF noise near my homeassistant raspberry pi (switched USB devices around). Putting the stick on an USB extension cable let it receive updates again. But I have no monitoring that would allow me to detect an error in a few weeks or so - I only notice wrong state reports when I see that Homeassistant is disabling the "lift cover" button because it still thinks the cover is up 100%.

[bcutter]

Extension cable for the duoFERN stick was the first thing I did before even trying to get it run.

• I also don't have a close monitoring (I could, e. g. I have an "close all shutters" automation and I could check if XX seconds/minutes after that automation has run really all shutters are reported as closed - but I already spent so much time for implementing my "Fix device status" automation that I don't want to continue that time invest).
• I also only discover wrong states when looking at the dashboards randomly.

The main problem is, that shutters are opened locally (not triggered by HA) so the status report fully relies on duoFERN. And ALL noted missing status updates belong to that situation.

I updated to 0.3.4 and will monitor the situation once again for a few weeks. I really don't want to enable my "Fix device status" automation anymore because it had/has some annoying side effects and are at best a workaround.

[gluap]

The thing I found out while trying to debug the "why don't I get any states reported" issue this morning was: at least in this case the stick was really not receiving the messages. If it's the same with the occasional issue (one reason I could think of would be if there were other devices - for instance from neighbours - using the same frequency, masking the occasional message. Or even homeassistant when sending commands to a bunch of shutters in sequence, talking over responses from the first ones in the process.), there will be no way to fix it in code (aside from codifying your workaround that I assume nudges the devices to re-send their status).

[bcutter]

Hmm, I'm of course not aware of the tech devices of my neighbours (except one garage opener of one neighbour, but no idea if it uses the same frequency). But according to my logged 9 incidents there's no pattern which would verify the assumption "RF noise of other systems corrupt the duoFERN communication".

your workaround that I assume nudges the devices to re-send their status

In the end all I do is triggering the status update by simply using the service: cover.stop_cover along with a certain entity_id. Usually for single shutters with a delay before, as the triggers are sometimes movement sensors, window sensors or much more "ugly" triggers where no local sensors are available. Ultimate goal is avoiding the stop of the manually initiated opening/closing of a shutter after X seconds just because this automation kicks in, those are the negative aspects I was talking about.

I could finetune that automation a lot over time, but not fully eliminate accidentally stopping running opening or closing processes. So at the end the individual question is what bothers more: interrupting opening/closing processes or missing device status.

6 weeks ago I was therefore putting all my hope into the new releases - and I'm quite sure they improved things a lot. 9 randomly discovered incidents in 6 weeks is still bad, but much better than in the past where this happened on a daily basis (without the device status fix automation). I must admit I still (again) use the cover.stop-cover in my "Close all shutters" automation (based on incidents even with 0.3.2 and as free lunch backup/fallback solution), so I can only speak for the other 50 to 60 % of usage.

[gluap]

@bcutter thank you for the detailed description of the automation. I tried to find a way to ask devices to re-send their state without side-effects and I think I found one - implemented in the new beta release. It needs to be called as a service (but one could do that by a time pattern in Homeassistant for instance).

[bcutter]

I saw and installed 0.4.0 (HA restart and tests pending) - those new services sound like the perfect workaround implementation. I could and very likely will just replace cover.stop_cover with duofern.update_device_state (and remove the entity_id cause the new service requests ALL devices to update their status while the former service only triggered one specific device).

Now regardless of the used trigger(s) there are no side effects like interrupted opening/closing processes, which really is a huge improvement.

Thanks a lot for digging into this and coming up with this new release. Will monitor it for a few weeks now.

[bcutter]

@gluap One question came to my mind when updating my automations (most of them still disabled as I want to test the next 4 weeks how often status updates are missed running 0.4.0) to use the duofern.update_device_state service instead of the former cover.stop_cover service:

Is it implemented to always trigger ALL devices to sync?

      - service: duofern.update_device_state
        data: {}

Or could this be possible (idea: limit air noise to one specific device instead of - I guess polling? - ALL devices) too:

      - service: duofern.update_device_state
        data: {}
        target:
          entity_id:
          - cover.rollladen_abc

[bcutter]

Update:

• Since updating to 0.4.0 everything looked fine first.
• Unfortunately, I still see that states are not updated reliably from time to time.
• It happened 3 times during the last 5 days.

[bcutter]

Follow-up:

Still happens for my devices. Did not count it, but happens a bit more often in the last days/weeks. One case today. Always the same: local control changes (e. g. opening a cover) not transfered to HA, hitting the "stop" button in HA once immediately updates the cover entities' state.

But I (still) have the auto update turned off, available since https://github.com/gluap/pyduofern-hacs/releases/tag/v0.5.5 and acting as a plaster for the core duoFERN protocol communication unreliabilty.