HmIP Taster Events via RPC/API

ThomDietrich commented 2 years ago

Describe the solution you'd like

Hallo, ich habe bereits nach einem passenden Ticket gesucht und entschuldige mich, sollte ich es übersehen haben.

Nach der Einrichtung eines HmIP-BRC2 Wandtasters in RasberryMatic wollte ich Taster-Events anschließend in Home Assistant auswerten. Hier werden allerdings keine Events empfangen. Es scheint hier Probleme mit der Übermittlung per RPC/API zu geben. Ich würde mich freuen wenn dies korrigiert würde.

Vielen Dank und liebe Grüße!

Describe alternatives you've considered

Die Erklärung für die Lösung des Fehlverhaltens findet sich in der Home Assistant Dokumentation: https://www.home-assistant.io/integrations/homematic/#homematickeypress-events-for-homematic-ip-devices

Die CCU wird über ein Pseudo-Programm, welches anschließend auch wieder gelöscht werden kann, dazu gebracht plötzlich und fortan Events zu generieren.

Is your feature request related to a problem?

Bug: Nach dem Erstellen und Löschen eines Programms sollte das Verhalten der CCU unverändert sein. Dass plötzlich mehr Events gesendet werden wirkt nicht nachvollziehbar und ist also streng genommen ein Fehler.
Feature Request: Das beschriebene Vorgehen um Events von HmIP Geräten über die API zu erhalten ist alles andere als leichtgängig, inutitive und fehlerunanfällig. Besteht die Möglichkeit dieses Problem im Rahmen des RaspberryMatic Projektes zu lösen?

Additional information

No response

jens-maus commented 4 weeks ago

Dann arbeitet ihr da gerne mal was optimierteres aus und ich übernehme das dann gerne auch in RaspberryMatic. Vielleicht kann man die value_id ja dann auch so wählen (wenn man sie schon als freitext so oder so nennen kann) das man diese ggf abfragen kann? D.h. Zum Beispiel als value_id einfach CENTRAL_LINK nutzen? Kann man die dann irgendwie abfragen ob das existiert in dem Moment wo man sie gesetzt hat?

SukramJ commented 4 weeks ago

Bei RM wird per Patch derzeit PRESS_SHORT gesetzt, d.h. wenn man das ändert, dann hat man Altlasten, die beseitigt werden sollten.

Im Sinne einer Handlungsempfehlung frag ich mich gerade, ob es besser ist pro Verfahren (RM, HA, IoBroker) eine eigene value_id zu wählen, oder immer die gleiche zu setzten. Für eine verfahrensspezifische value_id spricht schon mal, das man eh nicht weiss was die CCU bei Programmen verwendet.

jp112sdl commented 3 weeks ago

Kann mal jemand testen was bei [xmlrpc http://127.0.0.1:32010 getMetadata [list string 00021A498A4C88:1] reportValueUsageData] rauskommt? (Adresse natürlich vorher anpassen^^)

Baxxy13 commented 3 weeks ago

Sehr gut... 14209 0 14213 0 PRESS_LONG 0 PRESS_SHORT 0 Panda 1 Pandabaer 0]

😁 Katze und Moorhuhn hatten mir missfallen. 😉

jp112sdl commented 3 weeks ago

Yeah, ist damit jetzt die Aufgabenstellung gelöst?

Baxxy13 commented 3 weeks ago

Hmm, klingt erstmal gut. Hast du auch ne Idee wie ich den Zoo wieder wegbekomme?

jp112sdl commented 3 weeks ago

Hast du auch ne Idee wie ich den Zoo wieder wegbekomme?

Gerät ablernen und neu anlernen. Sowas wie ein removeMetaData scheint nicht vorgesehen zu sein. Stört aber auch nicht, so lange die Werte = 0 sind

Baxxy13 commented 3 weeks ago

Direkt nach neu Anlernen der HmIP-PS sieht das mit getMetadata jetzt so aus: PRESS_LONG 0 PRESS_LONG_RELEASE 0 PRESS_LONG_START 0 PRESS_SHORT 0

Für einen Kanal eines HmIP-MOD-RC8 so: PRESS_LONG 0 PRESS_LONG_RELEASE 0 PRESS_LONG_START 0 PRESS_SHORT 0 STATE 0

Könnte man also in der Tat als "Central-Link" Detektor nutzen wenn man über die Ausgabe iteriert. Sobald auch nur eine 1 drinsteht ist der "Central-Link" aktiv.

jens-maus commented 3 weeks ago

Da habt ihr ja mal wieder etwas feines rausbekommen. Sehr gut! D.h. Wir könnten den WebUI Patch für den Central-Link etwas verfeinern und das mit dem getMetaData jetzt einbauen um zu erkennen das der bereits aktiv ist? Müsste man IMHO nur noch rausfinden ob das getMetaData sicher den DC nicht erhöht wenn man das zich mal aufruft. Auch könnte man ja überlegen ob man diese Central-Link advs jetzt vllt in der WebUI Unter Direktverknüpfungen auch mit anzeigt damit die an der eigentlich richtigen Stelle mit aufgelistet werden?!? Oder belassen wir es beim Device Info Popup wie jetzt?

Baxxy13 commented 3 weeks ago

Also ich sehe keinerlei Funk-Kommunikation wenn ich getMetaData aufrufe. Auch am DC tut sich nix. Ich würde sagen das können wir gefahrlos nutzen.

Groß umbauen würde ich das auch nicht. Ich find's gut da wo es ist. Wenn wir da noch eine "Link aktiv" / Link inaktiv" Info irgendwo reinpressen können wäre das natürlich super.

Zur eigenen value_id: Würde ich nicht machen, sondern mich an die "Spielregeln" der WebUI halten. Die nimmt, wenn ich das Dummy-Programm anlege und den Tasterkanal auswähle ohne weitere Anpassungen des Users, den ersten Datenpunkt auf dem Kanal und das ist (soweit ich das sehen kann immer) PRESS_LONG.

SukramJ commented 3 weeks ago

Verwenden Programme nicht ihre id als value_id?

jens-maus commented 3 weeks ago

Groß umbauen würde ich das auch nicht. Ich find's gut da wo es ist.

Wenn wir da noch eine "Link aktiv" / Link inaktiv" Info irgendwo reinpressen können wäre das natürlich super.

Muss ja nicht groß sein und man könnte das an der Stelle wo es jetzt ist ja so belassen bzw nur um die Info erweitern. Aber vielleicht doch nen zusätzlichen Eintrag unter der Liste der Direktverknüpfungen zu haben wäre vllt doch nicht schlecht - schon aus Konsistenzgründen...

Zur eigenen value_id:

Würde ich nicht machen, sondern mich an die "Spielregeln" der WebUI halten.

Die nimmt, wenn ich das Dummy-Programm anlege und den Tasterkanal auswähle ohne weitere Anpassungen des Users, den ersten Datenpunkt auf dem Kanal und das ist (soweit ich das sehen kann immer) PRESS_LONG.

Wirklich immer der erste? Oder den den man anlegt? Und ich stimme zu, wir sollten da jetzt nicht eigene value_ids uns ausdenken die man dann im Zweifel nur durch ablernen wieder entfernt bekommt. Wer weis was das noch hier+da für side effects oder regressions auslöst...

Baxxy13 commented 3 weeks ago

Es ist schon der Datenpunkt den man auswählt. Vorausgewählt ist immer PRESS_LONG. Ist aber m.E. auch nicht so wichtig weil wir den Löschbutton eh sperren solange ein Programm genutzt wird. Und wenn wir nun noch den Aktivieren Button sperren wenn eine der id's 1 ist sollte das passen.

D.h. hat ein User das Dummyprogramm, egal mit welchem Trigger, angelegt sind idealerweise beide Buttons inaktiv.

SukramJ commented 3 weeks ago

D.h. hat ein User das Dummyprogramm, egal mit welchem Trigger, angelegt sind idealerweise beide Buttons inaktiv.

Nee, dazu war ich zu faul, und die Events kommen mit einer einfachen Belegung auch alle an.

Ist aber m.E. auch nicht so wichtig weil wir den Löschbutton eh sperren solange ein Programm genutzt wird.

Wenn man eine eigene value_id nimmt muss man sich um die interne CCU-Logik zur Referenzierung nicht kümmern. Dann macht man auch durch ggf. zu häufiges de-referenzieren auch die Programme nicht kaputt.

Mit setMetadata und einem bereinigtem Struct kann man die fremd value_ids wieder entfernen.

Baxxy13 commented 3 weeks ago

Klingt auch nicht verkehrt. Kannst du mal ein Beispiel zeigen für so eine "Bereinigung"?

Wir sind noch in der Überlegungsphase wie man es am besten macht. Wird sich aber etwas ziehen, wegen Urlaub.

SukramJ commented 3 weeks ago

Kannst du mal ein Beispiel zeigen für so eine "Bereinigung"?

Ich kann da nur meinen Python code anbieten, aber ich muss mir ja auch eure Skripte anschauen:

    async def cleanup_metadata(self):
        """Clenaup the metadata for central links """
        clean_value: dict[str, Any] = {}
        if metadata := await self._device.client.get_metadata(
                address=self._address, data_id=REPORT_VALUE_USAGE_DATA
            ):
            for key, value in metadata.items():
                if key in CLICK_EVENTS:
                    clean_value[key] = value
            await self._device.client.set_metadata(address=self._address, data_id=REPORT_VALUE_USAGE_DATA, value=clean_value)

CLICK_EVENTS = PRESS_SHORT, PRESS_LONG, ....

SukramJ commented 3 weeks ago

Für Homeassistant hab ich es mal zum Testen umgesetzt:

Es wird eine eigene value_id HAHM verwendet.
Es gibt zwei neue Services, d.h. der Benutzer muss selber aktiv werden: create_central_links / remove_central_links
Beim Anlegen wird geprüft ob HAHM mit Wert >0 schon vorhanden ist.
Beim Entfernen wird HAHM auf 0 gesetzt und die HAHM aus den Metadaten entfernt.
Der Eintrag ist also HAHM = 1 oder nicht vorhanden.

Wer Lust hat gerne testen und Feedback geben. Noch ist nichts in Stein gemeisselt.

jp112sdl commented 3 weeks ago

und die HAHM aus den Metadaten entfernt.

Von welchen Metadaten ist hier die Rede ? Die des Geräteobjekts in der ReGa oder die im HMIPServer? Oder hat HA noch mal einen eigenen MetaDaten-Aufbewahrungsschrank?

Die Metadaten des Geräts direkt im HMIPServer (auf die sich auch Baxxy bezieht, bzw ich in meinem Beitrag: https://github.com/jens-maus/RaspberryMatic/issues/1567#issuecomment-2420492778) lassen sich von 'außen' nicht löschen. Es gibt dazu keine Methode.

SukramJ commented 3 weeks ago

Ich verwende die XMLRPC-Schnittstelle:

Ich lese mit getMetadata aus dem Kanal reportValueUsageData aus. Dann lösche ich aus reportValueUsageData mein eigenes Key (HAHM)/Value Paar. Dann schreibe ich mit setMetadata reportValueUsageData auf den Kanal

jens-maus commented 3 weeks ago

Es wird eine eigene value_id HAHM verwendet. [...] Wer Lust hat gerne testen und Feedback geben. Noch ist nichts in Stein gemeisselt.

Mein erstes Feedback wäre das doch bitte in der Tat zu unterlassen dir jetzt eigene value_id auszudenken und zu nutzen, denn das macht dann den Umstieg auf ein anderes CCU System in der Tat kompliziert. Und wenn wir jetzt in RaspberryMatic ne andere value_id verwenden als HMHA endet das nur darin das dann da dooferweiser zwei Stück für den selben Zweck existieren. Nutzt doch bitte einfach die existierende value_id für das Tastergerät (eben PRESS_LONG) und unterlasse es hier was eigenes einzubestellen, denn letztendlich maintainst du ja im Grunde nur eine Integration die via APIs Geräte von CCU Zentralen abfragt und sich an existierenden Verhalten orientieren sollte. Und insofern würde ich es sehr gut finden wenn du dann letztendlich das genauso machst wie RaspberryMatic oder die originale CCU Firmware selbst. Können wir dafür eine Einigung bzw. eine Konvention findet an die wir uns dann gleichermaßen halten?

SukramJ commented 3 weeks ago

Mein Feedback zu deinem Feedback wäre doch etwas auf die Wortwahl zu achten!!! Das ist eine Arbeitsgrundlage und ich lasse mir ungern sagen das ich etwas zu unterlassen habe. Ich hoffe der Punkt ist klar. Ich schreib nicht hier in diesem Issue weil ich einen Einzelweg gehen will, sondern weil ich Interesse daran habe kooperativ an einer Lösung zu arbeiten. Ich hoffe das ist auch in deinem Interesse. Ich bin dazu bereit.

Wen man nicht bereit ist etwas zu testen, dann wird man auch nicht die Probleme feststellen können, daher mein Vorgehen mit einer eigenen value_id. Ich denke aktuell, das die Wiederverwendung einer bestehenden value_id mehr Probleme mit sich bringt als zu lösen, aber ich lass mich da auch gerne überzeugen.

jens-maus commented 3 weeks ago

Ich hoffe das ist auch in deinem Interesse. Ich bin dazu bereit.

Oh. Das tut mir natürlich leid das du meine Worte so verstanden hast - so waren Sie natürlich nicht gemeint. Auch ich bin an einer kooperativen Lösung hoch interessiert und wollte dir nicht vorschreiben wie du etwas umzusetzen hast und wie nicht. Wenn ich mich also falsch ausgedrückt habe tut mir das natürlich leid.

Wen man nicht bereit ist etwas zu testen, dann wird man auch nicht die Probleme feststellen können, daher mein Vorgehen mit einer eigenen value_id.

Ich bin dazu schon bereit, verweile jedoch gerade noch im Urlaub und kann das erst praktisch nächste Woche irgendwann mal testen. Möchte aber eben auch vermeiden das hier zu schnell Dinge ggf in den Stein gemeißelt werden und dann ein anderer Lösungsansatz ggf. schwierig wird.

Ich denke aktuell, das die Wiederverwendung einer bestehenden value_id mehr Probleme mit sich bringt als zu lösen, aber ich lass mich da auch gerne überzeugen.

Wenn das so ist, das die Wiederverwendung einer bestehenden value_id mehr Probleme macht, dann habe ich das wohl in der Tat noch nicht ganz kapiert bzw durchschaut. Was genau wäre/sind denn die Probleme die auftauchen würden wenn man einfach PRESS_LONG verwendet? Weil die CCU bzw RM machen das ja jetzt schon so wenn man ein WebUI Programm anlegt wenn ich Baxxy richtig verstanden habe. Und ich bin eher besorgt das wenn die HA Integration jetzt ne eigene value_id setzt und RM dann ne andere es dann ggf. Probleme geben könnte. Auch müsste man mal ne WebUI Code wohl durchsuchen und schauen das nicht irgendwas bereits das getMetaData via XMLRPC nutzt und das dann durcheinander kommt wenn da ne fremde value_id verwendet wird. Wäre nicht das erste mal das da irgendeine alte eQ3 Programmierung einem auf die Füße fehlt wenn man versucht innovative/neue Dinge einzuführen.

SukramJ commented 3 weeks ago

Danke für die Rückmeldung, ich hab nicht vor vorzeitig Fakten zu schaffen , also lass und weiter konstruktiv zusammen arbeiten. Inhaltliche melde ich mich die nächsten Tage, wenn ich einige Sachen noch getestet habe.

SukramJ commented 3 weeks ago

Mein Problem mit der CCU eigenen value_id ist, das das Löschen nur mit einem Lookup auf die verwendenden Programme absicherbar ist, und man die weiteren externen Verwender nicht kennt, und so ggf. die Referenz löscht, die noch extern verwendet wird. Auf der anderen Seite sind die eventuell auftretenden Seiteneffekte, die in der CCU auftreten könnten, nicht zu unterschätzen. Irgendwas ist immer. Version 1.68.0b3 verwendet jetzt PRESS_SHORT.

jens-maus commented 3 weeks ago

Danke für die Info und die Anpassung. Aber wer außer die WebUI in RM oder CCU oder eben jetzt deine HA Integration setzen überhaupt diese Metadaten bzw. Setzen/löschen dieses Central-Link für Tastergeräte? Ich vermute keiner.

Der Punkt ist, das externe Applikationen bzw. Systeme IMHO im Grunde ja nur die Art&Weise wie die CCU selbst das intern handhabt nachbilden und modifizieren sollte. D.h. Im Grunde: auch wenn es ein WebUI Programm gibt das den Central-Link generiert kann es natürlich passieren das eine externe App oder die interne "Entferne Central-Link" Funktion diesen entfernt. Ich kann zwar die Idee dahinter verstehen das man als externe App/System gerne seine Central-Links quasi selbst verwalten bzw deren State selbst pflegen will. Bin mir aber an der Stelle nicht so sicher ob das eine gute Idee ist. Denn umgedreht kann man ja auch argumentieren das ggf eine externe App/System den Central-Link gänzlich löschen können muss/sollte, aber wenn das dann nicht geht weil die CCU/RM das z.b. über PRESS_LONG verwaltet und ne andere das aber dann über XYZ bekommt man den Central-Link ja niemals weg, oder? Deshalb wäre es vmtl in der Tat IMHO das beste einfach dich das nachzubilden was passiert wenn man in der WebUI ein leeres Programm anlegt um den Central-Link zu generieren und was auch passiert wenn das WebUI Programm gelöscht wird. Weil was würde sonst passieren wenn z.b. der Nutzer nur temporär die HA Integration mal nutzt, dann sich aber dagegen entscheidet. Dann bekommt er den central Link nur umständlich wieder los oder bekommt es im Grunde auch gar nicht mit das da einer gesetzt ist...

SukramJ commented 3 weeks ago

Dann ist die Anforderung ja jetzt erfüllt.

jens-maus commented 3 weeks ago

Da sonst doch super. Danke dir. Dann werden wir das für RM bestimmt zeitnah auch so umsetzen und dann ist gut 😜

SukramJ commented 3 weeks ago

Noch mal ne Grundsatzfrage:
Der WebUI-Patch setzt das ja für HmIP-RF und Bidcos-RF um. Ist das Setzen von reportValueUsage eigentlich bei virtuellen Fernbedienungen notwendig? EDIT: Eigentlich geht es nur um die HmIP-RF virtuelle Fernbedienung.

Baxxy13 commented 3 weeks ago

Die RCV's brauchen das m.E. nicht. Kannst du aber leicht mit dem Homematic-Manager testen oder lauschst im HA auf den Keypress.

Das RM die Central-Link Option bei den (IP) RCV's anzeigt liegt entweder daran das das damals nicht bedacht wurde oder das wir virt. Tasten nicht von echten unterscheiden können. Kann man ggf. noch "verbessern".

jens-maus / RaspberryMatic