RSSI HM-ES-TX-WM

[emufan]

DONT'T DELETE THIS.

Language: german

custom_component/hahomematic version (if applicable): 1.12.3

Home Assistant version (if applicable): 2022.7.5

CCU version:

• CCU3
• Original
• Version: 3.65.6

Problem-relevant configuration:

Do you use tls? no Do you use callback? no Do you use username and password? yes Which interfaces do you use (hmip/bidcos/wired)? hmip, bidcos, groups

Describe the bug

Ich muss doch nochmal auf die RSSI-Werte vom RSSI HM-ES-TX-WM zurückkommen. Kann mir auch vorstellen, dass es auch bei anderen HM-Geräten so ist, kann das aber nicht sagen.

Wie schon im Diskussionsforum beschrieben bekommt ds Gerät seit den letzten Änderungen (zufällig oder damit verbunden) keine RSSI-Werte mehr, wo sich bei der Core-Integration schon Werteänderungen ergeben. Hier mal zwei Snapshots:

Dennoch sind de rssi-Entitäten hier in der Integration stets und immer unknown.

Wenn die alte diese nicht dann und wann pollt (wovon ich nicht ausgehen), müssen sie ja zumindest dann und wann über die Events kommen, hier aber nie ankommen oder nie verwerted werden.

Vielleicht kommmen sie nur über einen bestimmen Kanal? Wobei die Werte im Core in jeder Entität sind, d.h. auch in lowbat, energy_counter, usw.

Nicht dringend, aber evtl. auch für anderen HM-Geräte relevant.

[SukramJ]

Initial werden für alle Geräte Werte geladen, sofern sich diese seit dem Neustart der CCU geändert haben. Danach wird auf Events der CCU gewartet. Ein weiteres Polling erfolgt nicht.

Das Vorgehen sollte zur PyHomematic Integration identisch sein. @danielperna84 Das Vorgehen ist für alle Geräte identisch, d.h. es gibt keine gerätespezifische Sonderbehandlung.

Wenn ein Gerät bzw. die CCU keine Events sendet kommen also auch keine geänderten Werte in HA an.

Mangels geeigneter Geräte kann ich das auch nicht nachvollziehen, bzw. konnte bisher nur sehen das keine Events durch die CCU generiert wurden.

[danielperna84]

Da es schon so ewig her ist weiß ich nichts mehr genau wie das war. Aber bei pyhomematic ist die Kette get_rssi -> getAttributeData -> _getNoteData, und dort wird dann ein vollwertiges getValue gemacht. Vielleicht macht das den Unterschied aus?

[SukramJ]

getValue greift teilweise auf das Gerät durch und lässt so den DutyCycle steigen. Ist alles in #328 gut dargestellt. Daher verwenden wir das ReGaScript fetch_all_device_data.fn das alle Daten aus der CCU holt ohne auf die Geräte durchzugreifen und den DutyCycle zu steigern.

Das ganze wurde auch schon mal hier diskutiert ohne eine wirkliche Lösung zu finden.

Das ist aber alles nur für das initiale Laden der Daten relevant!

Danach senden einige HM Geräte keine Events mehr, so das der initiale Wert dauerhaft stehen bleibt. Das scheint sich aber im wesentlichen auf den Kanal 0 zu beschränken, in dem auch die RSSI-Werte liegen.

Eine Lösung hab ich derzeit nicht.

[danielperna84]

Das ist mir klar. Ich wollte nur den Unterschied zwischen pyhomematic und hahomematic an dieser Stelle hervorheben, und weshalb pyhomematic hier auf den ersten Blick besser (und ineffizienter) zu funktionieren scheint. Interessant wäre es mal die RSSI-Werte bei der pyhomematic variante zu loggen. Wäre ja durchaus möglich, dass man dort die ganze Zeit die Werte behält, die initial mit dem getValue geladen wurde, und es dadurch nur wirkt als würde es besser funktionieren.

[SukramJ]

Man kann leider keine Diagramme für RSSI in der CCU aufzeichnen. In HA steht der RSSI-Device seit einer Woche konstant auf -67 dBm, was auch der CCU Anzeige entspricht. Ich dachte mal das ich hier eine Änderung gesehen hätte, aber vielleicht hab ich mich da auch getäuscht.

[emufan]

Wäre ja durchaus möglich, dass man dort die ganze Zeit die Werte behält, die initial mit dem getValue geladen wurde, und es dadurch nur wirkt als würde es besser funktionieren.

Was meinst Du hier mit Initial? Nach Reboot von HA oder nach Einrichtung der Integration? Nur letzters kann nicht sien. Siehe Ausgangspost. Da sind zwei Screenshots. die _2 Entitäten sind aus der Core-Integration. Und da gab es schon zwischendurch ein Update der RSSI-Attribute.

[danielperna84]

Was ich meine ist, dass bei pyhomematic beim (Home Assistant) Start ein getValue gemacht wird. Da wird das Gerät also aktiv abgefragt, inkl. dem Nachteil von dem dadurch resultierenden RF-Traffic. Das passiert bei hahomematic nicht.

Es wäre ja möglich, dass der HM-ES-TX-WM selten bis nie Events bzgl. RSSI verschickt, und diese nur auf Anfrage (getValue) bereitstellt. Das würde ja dazu passen, dass die Core-Integration hierfür einen Wert anzeigt, die neue Integration hingegen nicht. Denn die macht ja kein getValue. Und wenn die CCU zu dem Zeitpunkt (neue Integration laden) auch keinen Wert im Cache hat, dann bleibt das ewig bei None hängen.

Nur so eine Theorie.

[emufan]

Hatte ich verstanden. Meinte nur Dein konkretes "initial" im Post davor.

Aktives periodisches lesen oder Ausnahmeliste (außer es betrifft alle HM-Geräte) für ein Lesen beim Booten fände ich auch too much.

Aber ein Service, mit dem ich das per Automatisierung in den vorhandenen/generierten Sensor pollen könnte, das fände ich gut. Dann kann sich ja jeder dann einbauen, wenn wer möchte. Oder habe ich etwas übersehen und das gibt es schon?

[SukramJ]

Geht es hier immer noch NUR um den RSSI Wert?

Aber ein Service, mit dem ich das per Automatisierung in den vorhandenen/generierten Sensor pollen könnte, das fände ich gut.

Ein Service der eigentlich nie geänderte Daten lädt, aber zumindest bei den nicht-batterie betriebenen Geräten auch direkt auf das Gerät zugreift, und damit den DutyCyle erhöht, halte ich ich für keine gute Idee.

[emufan]

Im konkreten Fall ja, nur RSSI-Wert. Aber ich habe auch nur das eine H.Gerät. Weiß also nicht, ob und bei welchen Parametern sich bei anderen HM die Logik ähnlich tickt.

Ein Service der eigentlich nie geänderte Daten lädt, aber zumindest bei den nicht-batterie betriebenen Geräten auch direkt auf das Gerät zugreift, und damit den DutyCyle erhöht, halte ich ich für keine gute Idee.

Hm. Verstehe ich nicht. Wie nie geänderte Daten? Das ist doch das Thema. Der Wert änder sich ja und wird auch im WebUI andauern anders angezeigt, Nur in dieser Integration nie. Die, die es nicht interessiert, haben die Entität Parameter ja auf deaktiviert. Oder sieist nicht aktiviert und hat den Status unknown. Und die, die dort einen validen Wert erwarten/haben wollen, planen sich per Automatisierung den Pull-Service ein. Klär erhöhrt dws den Duty-Cacyle. Aber das ist ja eine bewusste Entscheidung deren wie ich, die sich den Service als Automatisierung einrichten. Jedes Drücken einen Schalters erhöht auch den Duty Cycle. Oder das gleiche Gerät sendet auch alle x Minuten seine anderen Werte. Dann kann ich doch auch alle 3-6 Stunden mal den RSSI-Wert pollen.

[SukramJ]

Nur für RSSI macht das keinen Sinn für mich (@danielperna84 ?). Bei meinen HM Geräten wird auch nur der RSSI Wert nicht aktualisiert, wobei ich LOWBAT nicht testen konnte.

[danielperna84]

Also ich habe grundsätzlich nix gegen einen hahomematic.update_entity Service dem man eine Entity ID gibt, und im Hintergrund wird dann der zum Parameter passende getValue ausgeführt. Muss man ja nicht machen wenn's einem egal ist. Und wer unbedingt manuell pollen möchte hat hiermit die Möglichkeit dazu.

[emufan]

So meinte ich das. Das wäre prima! Und wäre auch ein super genereller Workaround, falls es mehr solcher Edge-Cases gäbe. Oder wenn man (gerade bei den HM-Geräten) mal einen garantierten Wert für den einen oder anderen Parameter braucht, usw.

[SukramJ]

super genereller Workaround, falls es mehr solcher Edge-Cases gäbe

Ich denke das sagt Alles.

Ich bau den Service ein, aber ich schreibe dazu keine Doku.

• Wofür braucht man diesen Service
• Wofür braucht man diesen Service nicht.
• Was ist bei batteriebetrieben Geräten zu beachten
• Wie garantiert sind die Werte? ( siehe Punkt batteriebetriebene Geräte)
• Was sind die Folgen der Servicenutzung? Dutycycle bei exzessiver Nutzung.

[SukramJ]

Der Service heißt homematicip_local.update_entity Und erwartet als einzigen Parameter eine entity_id. Eine Entität kann höchstens alle 60 Sekunden abgefragt werden.

[SukramJ]

Da sich wohl niemand bereit erklärt mit entsprechender Doku zu unterstützten sollten wir diesen Service lieber lassen oder?

[emufan]

Ich habe das von Dir tatsächlich anders verstanden. Nämlich, dass es dazu keine Doku geben wird/soll und es nur hidden ausgeliefert wird.

Ich schreib' gern ein Passage, wenn gewünscht. Zu einigen Puntken von oben müsste ich es aber erst mal probieren, (wie garantiert, ...) um das Verhalten testen und dann beschreiebn zu können.

[SukramJ]

War wohl missverständlich, aber die Doku ist für mich Voraussetzung diesen Service überhaupt einzubauen, da es hidden Services nicht gibt.

Die für mich relevanten Punkte hatte ich mal aufgezählt. Wäre gut wenn Du, soweit wie möglich, etwas dazu schreiben könntest. Es gibt in custom_homematic einen Branch force_update für den Du einen PR für die Readme einstellen kannst.

Zu testen ist das ganze über Version 1.12.6.beta1.

Wenn das logging geändert wird (custom_components.homematicip_local.services: info) kannst Du auch sehen ob der Wert geändert wurde. Das funktioniert aber nur bei generischen Entitäten (binary_sensor, sensor, number,...)

Das Mindestabfrage Interval beträgt 60 Sekunden.

Vielen Dank für deine Unterstützung.

[emufan]

Zu testen ist das ganze über Version 1.12.6.beta1.

Ich probiere mal weiter. Erste Info: Die rssi-Werte wurden erfolgreich von der CCU gelesen. Werde nun noch warten, bis sie sich verändern und mit dem Manager vergleichen, usw. Danach schreibe ich was dazu. Kann ein paar Tage dauern, da aktuell im Urlaub mit wenig Rechnerzugriff, aber kommt.

[SukramJ]

Kein Problem.

[SukramJ]

Ich denke das Ticket kann erst mal beschlossen werden.

[emufan]

Wobei ihr mir vielleicht doch noch kurz auf die Sprünge helfen könntet, damit ich in der Doku nichts falsches schreibe. Wenn ich im Manager im Value-Paraemset das hier aufrufe und sehe

Ist das dann ein wie auch immer irgendwann in letzter Zeit zur CCU gekommener letzter Wert und gespeicherter Wert in der CCU. Oder ein durch ein getvalue direkt vom Gerät geholter Wert (der dann ggf. auch in der CCU aktualisiert wird, wenn überhaupt).

[SukramJ]

Schau mehr hier https://github.com/SukramJ/hahomematic/blob/devel/docs/rssi_fix.md

[emufan]

Nein, das wusste ich. Ich meine auch nicht die Werte an sich oben. Ich meinte, kommen die in dem Moment, wenn ich sie mir im Manager angucke (d.h. Value-Paramset angucke) (nur) aus dem Speicher der CCU oder werden vom Gerät geholt und dann angezeigt.

Nur damit ich hier nicht Äpfel mit Birnen vergleiche.

Denn hier wiederum mit homematicip_local.update_entity hatte ich es so verstanden, dass vom Gerät aus geholt/aktualisiert werden würde.

[SukramJ]

Nein, das wusste ich. Ich meine auch nicht die Werte an sich oben. Ich meinte, kommen die in dem Moment, wenn ich sie mir im Manager angucke (d.h. Value-Paramset angucke) (nur) aus dem Speicher der CCU oder werden vom Gerät geholt und dann angezeigt.

?? Gute Frage, ich würde vom Cache ausgehen (Batterie) oder laden beim Öffnen beim Rest.

Denn hier wiederum mit homematicip_local.update_entity hatte ich es so verstanden, dass vom Gerät aus geholt/aktualisiert werden würde.

Der da hinter steckende Befehl getValue greift bei batteriebetriebenen Geräten nicht auf das Gerät zu.

[emufan]

Danke Dir. Alles sehr suspekt. Dann würde es ja doch nur (wieder) daran liegen, dass e13 warum auch immer was in Events packt und was nicht. Dann würde aber auch das homematicip_local.update_entity den Dutycyle nicht beeinflussen bei den Batteriegeräten.

Egal für jetzt und das Thema, aber @jens-maus kann Du mit Deinem HM-Allwissen noch etwas beisteuern, da es mich wirklich interessiert.

• Ist das so, dass das getValue bei allen Batteriegeräten nur auf den CCU-Cache geht? Wenn ja, dann würde ich wie hier beim HM-ES-TX-WM auch nicht verstehen, warum in der alten getValue-Startvariante der Core-Integration mein HmIP-SLO Außenhelligkeitssensor (recht weit weg platziert) nach HA Neustart oft keine Wert hat, einhergehend mit gestörter Kommunikation? Wenn nur Cache abgefragt werden würde, dürfte das ja nicht passieren, wie ich das bislang verstanden habe.

• Und im Falle HM-ES-TX-WM sendet das Gerät dann periodisch an die CCU in den Cache und es fehlt quasi nur warum auch immer das packen in die Events (obwohl geänderte Werte vorhanden) und getValue lädt dann hier und im HomematicManager nur die Werte aus dem Cache? Komich komich die Leerer.

[SukramJ]

Es gibt einen HA Service update_entity der, wie ich das sehe die gleiche Funktionalität hat wie der unsere.

@emufan Kannst Du dir das auch mal anschauen?

Ich werde daher den homematicip_local service wieder entfernen.

[emufan]

Nein, der hatte bei mir nichts gemacht. Wie sollte er auch? Wenn der notwendige Callback per explizitem getValue in der Integration dafür gar nicht definiert ist/war?

[SukramJ]

Wenn der notwendige Callback per explizitem getValue in der Integration dafür gar nicht definiert ist/war?

Meinst Du ich würde Fragen wenn ich nicht vorher kurz selber getestet hätte?

[emufan]

Sprechen wir von jetzt oder bevor Du den 'getValue' Service eingebaut hattest?

[SukramJ]

Jetzt. Und für den update_entity service musste ich auch keinen getValue Service einbauen.

[SukramJ]

Der HA Service homeassistant.update_entity hätte auch funktioniert, ohne das ich homematicip_local.update_entity eingebaut hätte.

Ich hab den Service auch erst heute gesehen.

[emufan]

Dann verstehe ich das Problem vorher nicht. Du hattest vorher - so wie ich es verstanden hatte - kein getValue genutzt, d.h. keine Calls zur direkten Abfrage (mehr) von Werten in der CCU genutzt, der direkt auf die Geäte zugreift, sondern nur die "anderen" Interfaces und Events genutzt.

Und dann kann HA per homeassistant.update_entity das einfach so, d.h. weiß wie man auf die CCU callen muss, damit diese Werte direkt vom Gerät liefert, wenn das ansonsten von der Integration gar nicht gemacht wird? Nee, das verstehe ich noch nicht.

Hab' es gerade mal probiert. Und ja, geht. Hatte es vor der Diskussion aber auch probiert und wie gesagt, ging damals nicht. Der besagte Problemfall blieb immer unknown.

[emufan]

Den Service kannte ich und den nutze ich (soll man nutzen), wenn man andere Updateintervalle braucht als default. Früher konnte man die Update-Frequenzen in den yaml-Configs ja für die Integrationen einstellen, Das gibt es nicht mehr. Nun soll man dann Auto-Update im Config-Flow ausmachen und sich dann eine passende Automatisierung bauen.

[SukramJ]

Dann verstehe ich das Problem vorher nicht. Du hattest vorher - so wie ich es verstanden hatte - kein getValue genutzt, d.h. keine Calls zur direkten Abfrage (mehr) von Werten in der CCU genutzt, der direkt auf die Geäte zugreift, sondern nur die "anderen" Interfaces und Events genutzt.

Danach habe ich jetzt doch gar nicht gefragt, bzw. darüber müssen wir jetzt auch nicht wieder diskutieren.

Der Service geht. Gut, dann wird er andere entfernt.

[emufan]

Ich möchte ja gar nichts "diskutieren". Was sollten wir auch? Aber dass ich es einfach gern verstehen würde, warum es funktioniert und HA allein ohne getvalue oder anderer API auf das Gerät zugriefen kann, wenn doch eigentlich kein direkes Lesen vom Gerät implementiert ist, zählt nicht? Nun gut. Entsprechend damaligen Änderungen in der Diskussion des duty calclex mit Jens und passend zu

getValue greift teilweise auf das Gerät durch und lässt so den DutyCycle steigen. Daher verwenden wir das ReGaScript fetch_all_device_data.fn das alle Daten aus der CCU holt ohne auf die Geräte durchzugreifen und den DutyCycle zu steigern.

Zum "Service geht". Konnte nur Batterie-Geräte testen. Ob es er auch einen Direktcall zu einem nicht-Batterie-Gerät macht, konnte ich nicht testen.

Ebenso nicht, ob sich der Service im HA anders verhält, wenn das Gerät gerade "unavailable" ist.

[SukramJ]

Begriffe wie getValue, fetch_all_device_data.fn und Duty Cycle sind bei meiner heutigen Frage irrelevant, weil diese Themen gar nicht geändert, angefasst oder in Frage gestellt werden. Notwendige Änderungen im Backend (hahomematic 2022.7.14) wurde mit der CC Version 1.13.1 eingeführt.

Die Services homeassistant.update_entity und homematicip_local.update_entity rufen den gleichen Code in einer Entität im Backend (hahomematic) auf, und daher kann der eigene Service weg.

Wenn homeassistant.update_entity früher andere Ergebnisse geliefert hat, dann liegt das schlicht daran, das vor hahomematic 2022.7.14 der notwendige Code im anders implementiert war.

Ich hoffe das war zur Einordnung verständlich genug.