"er.a is not a valid duofern device" since v0.4.3

[bcutter]

Probably when using duofern.ask_for_update service (but that message has only been logged once, even I used the service without an device_id few more times):

Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht

Logger: custom_components.duofern
Source: custom_components/duofern/__init__.py:113
Integration: Duofern control (documentation, issues)
First occurred: 01:45:00 (1 occurrences)
Last logged: 01:45:00

er.a is not a valid duofern device, I only know dict_keys(['xxxxxx', 'yyyyyy', 'zzzzzz', 'aaaaaa', 'bbbbbb', 'cccccc', 'dddddd', 'eeeeee', '000000', 'ffffff'])

Related to https://github.com/gluap/pyduofern-hacs/releases/tag/v0.4.1:

• The device_id parameter of duofern.ask_for_update is mandatory now, isn't it?
• So applying this to all devices or (important to me) using a cover group (entity cover.all_covers) is not possible anymore?
  That would make that service pretty useless, e. g. when HA starts and I want to sync the device states (without needing to wait for 5 minutes)... 😞 It was working perfectly for all my devices. Now we don't have an option to IMMEDIATELY sync device states, or am I missing something?

[gluap]

Tbh that wasn't possible in the past either - if anything, it failed silently.

Making the update device specific was requested by you because "updating all" was not granular enough. So I put in the work to add it and removed the "update all" part as you, the only user then, had deemed it unsuitable.

Calling ask_for_update for a device group has the same downsides as calling it for all devices - messages sent out in a burst. So I didn't even think that would be what you meant.

[bcutter]

So what do you recommend for syncing the device state for all devices immediately?

[gluap]

I have no proposal for that. My takeaway from #24 (comment) was "updating individual devices is preferrable". Tbh I would have assumed that allowing the service to take "entity id" (essentially your use case) would also allow it to take List of "entity ID" but that does not seem the case. All this makes me think that the "non-customizable global update" is really the best solution as it takes the burden of thinking about this from the users.

[bcutter]

I still think both is needed and useful.

Specifying an entity_id is helpful and common HA standard (usually with target: entity_id) for services.

Applying the service to all entity_ids too (cited from #24):

Anyway it would still be good if it would work with groups, so setting the "entity_id" to a "cover.group_of_covers" would be necessary from my point of view.

I did not try it yet if the service accepts magic (hidden/not well or at all documented) keys like e. g. lights services do with "*". At least the GUI according to services.yaml only lists/accepts actual device entity_id's.

My summary: the current implementation (0.4.3) with targeting single entity_id's is very good.

Aiming at forcing an immediate device status update for ALL devices it would be great if the service accepts groups or simply addresses all devices if no entity_id is specified (like the former service prior to renaming it did).

As (ugly) not very end user friendly workarounds I can currently only imagine

• using the service for every entity_id so for 10 devices that makes 10 service calls
• trying to template service usage e. g. in a for loop

---

Update 1:

• magic keys not accepted ❌
• specifying multiple entity_id's also not accepted (service exclusively only accepts exactly ONE) ❌

service: duofern.ask_for_update
data:
  device_id:
    - cover.cover_a
    - cover.cover_b
    - cover.cover_c

So out of ideas with current 0.4.3. Only ugly workarounds remain -.-

---

Update 2:

Checked everything once again. Syntactically (did not verify it actually WORKS, so if device states are really synced) this seems to work - in terms of "service call is performed without an error":

1. multiple entities ✅

service: duofern.ask_for_update
data:
  device_id: cover.cover_a,cover.cover_b,cover.cover_c

2. all entities (HA magic words) ✅

service: duofern.ask_for_update
data:
  device_id: all

If this technically works (to be verified) I think with leaving a note in the docs on this service this should be sufficient. What do you think @gluap?

I now need to test it in real life. For that I need to make a device status change (likely by local control) duoFERN/HA should not get aware of instantly. 5 minutes auto update function should be no issue I guess. Not sure how to provoke this, I spent months with trying to avoid that "missing status update situations", now I want to create it 😄

[gluap]

I can check if i can merge back the "update all" solution, and / or if there's a way to make the gui more intuitive for specifying lists of targets or a group. I think I have seen that for other services so probably it's possible.

Will take until the weekend though, as im traveling without my laptop.

[bcutter]

I will test the functionality of the "multiple entities" and "all entities" tricks.

If it works in my opinion there's no need for (investing time on) a rollback of the former "update all" handling. Just a docs update (once that version leaves beta status), 5 minutes, done.

Of course using the UI would be much more intuitive for the "apply for multiple entities" part, but tbh I don't think one is really (regularly) using this service from the UI. Maybe I'm just projecting MY usage to others here (biased opinion). But:

Services are used mainly as part of scripts or automations so once one knows how to syntactically use the service for multiple/all entities, it should be fine.

[bcutter]

Update: again one step back. 😞

Using

service: duofern.ask_for_update
data:
  device_id: all

as well as

service: duofern.ask_for_update
data:
  device_id: cover.cover_a,cover.cover_b,cover.cover_c

gives the well-known error message in HA log:

❌ all (LOG truncated):

Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht

Logger: custom_components.duofern
Source: custom_components/duofern/__init__.py:113
Integration: Duofern control (documentation, issues)
First occurred: 01:45:00 (10 occurrences)
Last logged: 22:43:31

all is not a valid duofern device, I only know dict_keys(['...']...)
...

❌ multiple entities specified (LOG truncated):

Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht

Logger: custom_components.duofern
Source: custom_components/duofern/__init__.py:113
Integration: Duofern control (documentation, issues)
First occurred: 01:45:00 (13 occurrences)
Last logged: 22:48:43

er.er.a is not a valid duofern device, I only know dict_keys(['...']...)
...

So even it looks totally fine in the UI, that error is logged - and it's very likely not working on duoFERN side.
Probably duoFERN simply can neither map "all" to one of the expected device_ids nor work with more than one device_id.

---

So I fear: yes, unfortunately

I can check if i can merge back the "update all" solution

...seems to be necessary to bring this back to work.

[gluap]

thank you for testing this so extensively. I'm looking into it!

[bcutter]

You're welcome. Thanks four having a look into it, really looking forward to that. For now without the multiple/all duofern.ask_for_update service I'm running into the need for "5 minutes auto update" function, which is quite a lot. With the service I can reduce the status not updating again to only few seconds instead of 5 minutes without the need to rely on oldschool cover.stop_cover service.

Update: I see few random covers not updating their state reliably. One even did not for many HOURS, so definitely crossing multiple 5 minute slots. Heavily looking forward to have the service back operational.

[bcutter]

Seems to be fixed with duoFERN v0.5.5 where among others using the all: true feature is working fine now. Closed for me right now.