Manuell verstellte Rölladen zeigen nicht mehr % Status in Homekit an

[matthiaseinig]

Erstmal vielen Dank für diese fantastische Homekit integration. Ich habe aktuell über 60 Geräte damit in Homekit eingebunden, und mal abgesehen von gelegentlichen Crashes funktioniert es super!

Jetzt aber zum Problem:

Ich habe 20 Rollläden die über mehrere HmIPW-DRBL4 (Firmware 1.8.4) gesteuert werden und in der Homematic direktverknüpft mit Schaltern verbunden mit mehreren HmIPW-DRI32 (Firmware 1.2.2).

Das ganze auf einer CCU3 mit RaspherryMatic (Firmware 3.71.12.20230826).

Die Rollläden sind dann wie hier in HAP-Homematic als HomeMaticBlindIPAccessroy konfiguriert

und einer HAP Instance zugeordnet welche in der Home App hinzugefügt wurde.

Soweit so gut, ich kann die Rollläden rauf/runter fahren und in jeder Position stoppen:

1. manuell mit den Schaltern
2. in der Homematic (Status und Bedienung > Geräte)
3. in Homekit via HAP-Homematic

Bisher wurde immer, egal über welchen Weg der Rolladen bedient wird, die aktuelle "Behanghöhe" in % in der Home App korrekt angezeigt.

Seit einiger Zeit funktioniert das nur noch wenn ich den Rolladen in der Home App über Weg 3 bediene oder den Wert direkt über Weg 2 in % eingebe

Wenn ich aber über Weg 1 die "auf/ab" Tasten bedeine oder über Weg 2 auf die auf/ab Tasten drücke, dann steht zwar in der Homematic die Behanghöhe korrekt da, in der Home App wird aber entweder "geschlossen" (0%) oder offen (100%) angezeigt, je nachdem ob ich zuletzt auf Ab oder auf Auf bedient habe.

Bei der Bedienung ausschliesslich mit der Home App, wird immer der korrekte % Wert angezeigt.
Egal über welchen weg, in Homematic under "Status und Bedienung > Geräte", unter "Realer Wert Behanghöhe" steht immer der korrekte % Wert. Jedoch nicht im direkten Eingabefeld.

Somit scheint seit neuestem wenn die Bedienung nicht über die Home App erfolgt, der aktuelle Status nicht an Homematic-HAP übertragen zu werden, was vorher problemlos funktioniert hat.

Offensichtlich wird nicht der Wert aus "Realer Wert Behanghöhe" ausgelesen, sondern der Eingabewert im Textfeld.

Erstaunlicherweise funktioniert es bei einem HmIP-BROLL (Firmware 1.10.8) weiterhin problemlos, egal über welchen Weg der Rolladen bedient wird

Dieser ist identisch konfiguriert wie die Rollläden gesteuert über HmIPW-DRBL4

Da ich an der Konfiguration nichts geändert habe und es bisher ging, ist nun die Frage, ob sich an HAP etwas geändert hat, dass dieses Verhalten erklärt.

Um meine Frau nicht in den Wahnsinn zu treiben und meine gesamten Home Automations Bemühungen in Frage zu stellen, hoffe ich dass jemand eine Idee hat ;)

Zur Ergänzung, ich habe bereits versucht die gesamten Homematic Direktverknüpfungen zwischen HmIPW-DRBL4 und HmIPW-DRI32 neu zu konfiguerieren.
Auch habe ich komplett alles nochmal neu in Homematic-HAP neu konfiguriert, jedoch lässt sich die korrekte Anzeige nicht wieder herstellen.

[matthiaseinig]

Nach weiterer Suche bin ich über einen Eintrag zu einem ioBroker issue der das gleiche Problem beschreibt gekommen.

bei den HM-Aktoren gibt es sog. statedatapoints und controldatapoints also einen Statuskanal und einen Steuerkanal. Beide haben jew. einen LEVEL-Datenpunkt.
Wenn per WebUI oder App keine prozentuale Position an den Steuerkanal abgesetzt wird, sind die Level-Werte des Statuskanals und des Steuerkanals, nach der Rolladenfahrt, gleich.
Wenn der Rolladen per Taster an der Wand betätigt wird, wird der Steuerkanal auf 0% (rauf oder runter) bzw. 100% (rauf oder runter) gesetzt. Stoppt man dann den Rolladen per erneuten Tastendruck, wird nur im Statuskanal der aktuell angefahrene Level angezeigt. Der Level des Steuerkanals bleibt bei 0% oder 100%.
Wie ich aus diesem Beitrag (ganz unten https://forum.fhem.de/index.php/topic,100152.0.html) lesen konnte, sind diese unterschiedlichen Datapoints von Homematic Absicht.

Scheinbar ist es das selbe Problem, jedoch bleibt dann die Frage warum es bisher funktioniert hat, hat sich etwas in hap-homematic geändert dass nun der falsche Datenpunkt von Kanal 4 anstatt der Statusdatenpunkt von Kanal 3 ausgelesen wird?
Und warum funktioniert es beim HmIP-BROLL weiterhin?

[matthiaseinig]

Wenn ich mir das HomeMaticBlindIPAccessory.js im code ab Zeile 361 ansehe, hat sich ja dort seit 2 Jahren nichts geändert, es fällt jedoch auf, dass beim HmIP-BROLL
'SHUTTER_VIRTUAL_RECEIVER': { inhibit: { name: '4.INHIBIT' }, activity: { name: '3.ACTIVITY_STATE' }, level: { name: '4.LEVEL' }, getlevel: { name: '3.LEVEL' }, process: { name: '3.PROCESS' } },

scheinbar der Kanal 3.LEVEL bei "getlevel" angegeben wurde, beim
HmIPW-DRBL4

'HmIPW-DRBL4:BLIND_VIRTUAL_RECEIVER': { inhibit: { name: 'INHIBIT' }, activity: { name: 'ACTIVITY_STATE' }, level: { name: 'LEVEL' }, process: { name: 'PROCESS' }, slats: { name: 'LEVEL_2' } },

jedoch nicht.

Was wahrscheinlich daran liegt, weil der DRBL4 ja 4 Rollläden steuert und somit andere Kanäle verwendet werden.
Beim Blick in HmIPW-DRBL4.json und HmIP-BROLL.json scheint zumindest der jeweilige Status Kanal pro Rolladen korrekt als BLIND_TRANSMITTER bzw. beim BROLL als SHUTTER_TRANSMITTER definiert zu sein.

Zumindest mit dem rudimentären Verständnis des Codes das ich aktuell habe :)

Da keine der Dateien seit über 3 Jahren geändert wurde, scheint sich wohl beim DBRL4 durch ein Update der Firmware oder der CCU irgendetwas anders zu verhalten.

Ich forsche weiter :)