RaspberryMatic
RaspberryMatic copied to clipboard
jens-maus
HmIP Taster Events via RPC/API
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
Vor einiger Zeit hatten wir bzgl. dieses Umstandes, ein solches Fake-Programm anlegen zu müssen damit auch für Taster entsprechende Events ausgeliefert werden, bereits an anderen Stellen gesprochen. Nur hab ich da den Faden momentan verloren. Wir sollten das aber hier vmtl. einfach mal zusammenfassen damit man damit geordnet an eQ3 herantreten kann um irgendwelche Shortcomings (z.B. beim HMIPServer) beseitigen zu können und inwieweit wir dafür selbst im Rahmen von RaspberryMatic irgendwelche Konfigurationsmöglichkeiten dazu schaffen könnten die Eventauslieferung dieser erst zu aktivierenden Tasterevents auch hinzubekommen.
Vielleicht können @Baxxy13 und @jp112sdl nochmal diesbzgl. ne Zusammenfassung zum aktuellen Wissenstand geben und das hier auflisten, dann sollte das helfen hier ein aktuelles Gesamtbild dazu zu bekommen und besser an eQ3 bzgl. Verbesserungen herantreten zu können.
Ich kann nur erklären (zumindest für BidCos), was der Sinn dahinter ist: Wenn man die CCU nur zum Einrichten von Direktverknüpfungen nutzt, ohne Programme, ist es nicht notwendig, dass ein RF-Sender eine Quittung von der CCU empfängt. Und es ist auch nicht notwendig, dass der Sender auf diese Quittung wartet bzw. ein Telegramm im Fehlerfall wiederholt.
Daher ist die CCU als Art "Verknüpfungspartner" für den Sender erst von Interesse, wenn sie tatsächlich eine Rolle spielt - also wenn Programme getriggert werden sollen/müssen.
Ob es nun sinnvoll ist, reportValueUsage() auch ungeachtet dessen anzuknipsen, vermag ich nicht zu beurteilen.
Vermutlich wird da nichts passieren.
Also zuerst mal Punkte die aktuell allgemein gegen die Aktivierung dieser Funktion sprechen:
- einmal aktiviert wird man es nicht mehr los, es sei denn man löscht das Gerät aus der Zentrale und lernt es neu an (verifiziert)
- verzögerte bis nicht funktionale Direktverknüpfungen sollte die Zentrale mal "nicht verfügbar" sein (verifiziert)
- 20x gelb und anschließend rot blinkende Sensoren weil sie irgendwie das ack von der Zentrale nicht bekommen (teilweise verifiziert
- erhöhter DC weil jeder Status dann irgendwie 2x gesendet und quittiert wird (nicht 100%ig verifiziert)
Ich nenne das mal der Einfachheit halber auch ReportValueUsage wie es auch bei HM heißt.
Tatsächlich scheint es bei IP aber anders zu funktionieren. Hier wird wohl eine Art unsichtbare Direktverknüpfung zwischen Gerät und Zentrale hergestellt.
2 Beispiele für IP:
Jegliche IP-Tasterkanäle werden erstmal komplett von der Zentrale ignoriert. Leicht zu überprüfen indem man einen Tasterkanal protokolliert. Einmal im Programm als "Trigger" verwendet (Config steht zur Übertragung an) sieht man die "Tastendrücke" dann auch im Protokoll. (Man sieht auch an der System-LED des Tasters das ein "Partner" angefunkt wird) Löscht man das Programm bleibt das jetzt so.
Ähnlich wie bei IP-Tastern ist es bei IP-Sensordaten. (Bspw. AUF/ZU beim SWDO) Der Unterschied ist das die Zentrale diese natürlich immer mitbekommt und anzeigt und diese Daten auch ohne Eingriffe für externe Zugriffe (ioB) bereitstehen. Nimmt man hier den Status erstmalig als Trigger steht die Config zur Übertragung und der SWDO verhält sich anschließend als sei er mit irgendwas direktverknüpft. (orange dann grün).
Beispiel HM:
Nimmt man jetzt einen HM-Tasterkanal (HM-PB-2-WM55) zum ersten mal als Trigger muss auch die Config übertragen werden. Legt man jetzt weitere Programme mit diesem Trigger an muss keine Config mehr übertragen werden, aber möglicherweise zählt der ref_counter hoch. Denn lösche ich jetzt nach und nach die Programme bzw. entferne den Trigger muss nach dem letzten wieder eine Config übertragen werden. Damit wird dann vermutlich reportValueUsage wieder deaktiviert. Und das geht bei IP eben nicht.
Zusätzliche Info's zum Thema im Homematic-Forum: wie ReportValueUsage für IP Taster (HmIP-WRC6) wieder deaktivieren?
Thanks for your contribution!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of RaspberryMatic and tell us. Also check that all relevant details,
Vielen Dank für die Unterstützung!
Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüfen Sie, ob das Problem auch in der aktuellsten Version von RaspberryMatic noch relevant ist, und teilen Sie uns dies mit. Überprüfen Sie auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind oder aktualisiert werden müssen.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
Ich will mich doch nochmal kurz zu Wort melden. Danke für die Erklärungen und Abwägungen. Das war durchaus interessant.
Meiner Meinung nach ist das Problem aber nicht geklärt. Der dokumentierte Workaround alles andere als sauber, nicht deterministisch und definitiv nicht inituitv. Wäre eine Option innerhalb der Geräte-Einstellung möglich? Ideal wäre natürlich, wenn die aktuell neu entwicklete Home Assistant Integration diese Option automatisch setzen würde.
Danke und Gruß
Ich bin nun auch auf dieses Problem gestoßen. Gibt es einen Weg die sogenannten Direkt Verbindungen zu CENTRAL:0 gelöscht werden können? Im weder im UI noch per JSONAPI finde ich die.
Inzwischen wurde eine Lösung gefunden wie sich dieser "CENTRAL-LINK" per Script löschen lässt. Also ohne das Gerät aus der Zentrale zu löschen und neu anlernen zu müssen.
CENTRAL-LINK von IP-Geräten löschen per Script (aka ReportValueUsage() bei HM Geräten)
Super Sache! Vielleicht kann man überlegen deine Erkentnisse in ein neues WebUI Patch/Feature zu verwandeln wo man dann via WebUi diesen Central Link setzen und auch wieder löschen kann?!?
via WebUi diesen Central Link setzen
Den muss man nicht manuell wieder anlegen (können). Das machts von allein.
Mehr kann man darüber glaub ich nicht öffentlich diskutieren, um nicht in Konflikt mit irgendwelchen "closed source" Lizenzen von eQ-3 zu kommen.
Man "kann" das Ganze auch umdrehen und den Link ohne Dummyprogramm erzeugen.
Da wird's dann aber wieder komplizierter da man zum einen kein Feedback hat (aktiv ja / nein) und idealerweise die Möglichkeit auch auf wirklich nutzbare Kanäle beschränkt werden müsste.
Am besten wäre es wenn es dafür dokumentierte und nutzbare Funktionen gäbe.
via WebUi diesen Central Link setzen
Den muss man nicht manuell wieder anlegen (können). Das machts von allein.
Mehr kann man darüber glaub ich nicht öffentlich diskutieren, um nicht in Konflikt mit irgendwelchen "closed source" Lizenzen von eQ-3 zu kommen.
Weiss nicht warum du jetzt dauernd mit Lizenzen kommst. Ich kann hier keinerlei Konflikt erkennen und bezweifel auch das hier irgendjemand etwas gegen das RaspberryMatic Projekt machen wird das offiziell von eQ3 initiiert und unterstützt wird!
Und denke schon das es sinn ergibt eine Funktion in der WebUI ggf zu haben um nur diesen central link anzulegen ohne dauernd diesen workaround via fake webui programm machen zu müssen.
Man "kann" das Ganze auch umdrehen und den Link ohne Dummyprogramm erzeugen.
Genau das wäre mein Ansatz!
Da wird's dann aber wieder komplizierter da man zum einen kein Feedback hat (aktiv ja / nein) und idealerweise die Möglichkeit auch auf wirklich nutzbare Kanäle beschränkt werden müsste.
Das mit dem Feedback ist natürlich ne Sache. Aber vllt findet sich dafür mit der Zeit ja auch eine Lösung.
Am besten wäre es wenn es dafür dokumentierte und nutzbare Funktionen gäbe.
Das stimmt natürlich. Bezweifle aber stark das das irgendwann von eQ3 Seite kommen wird.
OK, halten wir hier erstmal die Befehlszeilen hier fest. Ohne Schnickschnack direkt für die Konsole:
CENTRAL-LINK anlegen:
echo 'load tclrpc.so; puts [xmlrpc http://127.0.0.1:32010 addLink [list string 001559939592C5:1] [list string CENTRAL_DEVICE:63]]' | tclsh
CENTRAL-LINK löschen:
echo 'load tclrpc.so; puts [xmlrpc http://127.0.0.1:32010 removeLink [list string 001559939592C5:1] [list string CENTRAL_DEVICE:63]]' | tclsh
Port 2010 oder 32010 scheint dabei keine Rolle zu spielen.
Weiss nicht warum du jetzt dauernd mit Lizenzen kommst.
https://github.com/eq-3/occu/blob/master/LicenseDE.pdf
3.4: Sie erhalten im Rahmen der HMSL nicht das Recht, in Binär- bzw. Objektform gelieferte Software zu decompilieren bzw. ein Reverse-Engineering durchzuführen, wenn die Voraussetzungen des §69e UrhG nicht gegeben sind.
Das ist super. Es war auch wirklich nicht nutzbar ohne das man die Links wieder entfernen kann.
Kann ich auch auslesen welche Links bereits bestehen? bzw. ist es immer CENTRAL:63?
Und während wir schon dabei sind. kann mir jemand einen Hinweis geben wie man die Parameter von einem (normalen) Link ändert? JSON API oder XMLRPC
Kann ich auch auslesen welche Links bereits bestehen?
Leider nicht. Zumindest habe ich bisher keine Methode dazu gefunden.
bzw. ist es immer CENTRAL:63?
Es sieht nach meinen Tests bisher danach aus. Da ich aber nur 3 Geräte getestet hatte und mein Fuhrpark am Testsystem überschaubar ist lege ich dafür keine Hand ins Feuer.
Und während wir schon dabei sind.
Gehört hier nicht her. Stell die Frage bitte im Homematic-Forum dann bekommst du sicher schnell ein paar Beispiele.
Ich hab das gerade mal in meiner App probiert und es funktioniert wirklich. Ich hab 3 meiner Geräte getestet. HmIP-BRC2, HmIP-BSM und HmIP-PS und bei allen war es Kanal 63.
3.4: Sie erhalten im Rahmen der HMSL nicht das Recht, in Binär- bzw. Objektform gelieferte Software zu decompilieren bzw. ein Reverse-Engineering durchzuführen, wenn die Voraussetzungen des §69e UrhG nicht gegeben sind.
Und ich würde mal sagen gut geraten mit dem Kanal 63 👍🏻
Kann ich auch auslesen welche Links bereits bestehen?
@jonaswre Ja, mit der Command Shell des crRFD: https://github.com/jp112sdl/HMIPServer-Shell
Die lässt sich einfach durch den Parameter Eventbus.Command.Shell.Enabled=true aktivieren.
llink zeigt dir dann die Verknüpfung eines jeweiligen Geräte-Kanals mit CENTRAL_DEVICE:63 an.
Ich habe mal den PR #2017 reingestellt, der die beiden Skript-Methoden von Baxxy in WebUI Buttons verpackt.
Kann ich auch auslesen welche Links bereits bestehen?
@jonaswre Ja, mit der Command Shell des crRFD: https://github.com/jp112sdl/HMIPServer-Shell Die lässt sich einfach durch den Parameter
Eventbus.Command.Shell.Enabled=trueaktivieren.
llinkzeigt dir dann die Verknüpfung eines jeweiligen Geräte-Kanals mitCENTRAL_DEVICE:63an.
Vielen dank für die Antwort leider habe ich keinen Zugriff auf die Shell kann man das auch per XML-RPC abrufen? Die Methode getLinks gibt nur das folgende zurück
<?xml version="1.0" encoding="ISO-8859-1"?>
<methodResponse><fault><value><struct><member><name>faultCode</name><value><i4>-2</i4></value></member><member><name>faultString</name><value>Invalid device</value></member></struct></value></fault></methodResponse>
Vielen dank für die Antwort leider habe ich keinen Zugriff auf die Shell kann man das auch per XML-RPC abrufen?
Nein, das ist doch gerade das Problem worum es hier geht.
Vielen dank für die Antwort leider habe ich keinen Zugriff auf die Shell kann man das auch per XML-RPC abrufen?
Nein, das ist doch gerade das Problem worum es hier geht.
Ich glaube @jonaswre versucht hier Infos zu sammeln für sein App Projekt und da wäre es fatal wenn er doe manuelle CommandShell des HmIPServer als Voraussetzung macht. Die beiden Tickets sollte man hier wirklich nicht IMHO miteinander vermengen.
Vielen dank für die Antwort leider habe ich keinen Zugriff auf die Shell kann man das auch per XML-RPC abrufen?
Nein, das ist doch gerade das Problem worum es hier geht.
Ich hatte das Problem so verstanden das niemand wusste wie man die Verbindung wieder löst. Das löschen bzw. anlegen geht auch per XML-RPC, nur die Abfrage geht nicht. Ich hatte gehofft das man vielleicht wenn man direkt das CENTRAL_DEVICE:63 abfragt eine Liste aller Geräte bekommt die eine solche Verknüpfung haben.
Ich glaube @jonaswre versucht hier Infos zu sammeln für sein App Projekt und da wäre es fatal wenn er doe manuelle CommandShell des HmIPServer als Voraussetzung macht. Die beiden Tickets sollte man hier wirklich nicht IMHO miteinander vermengen.
Das ist schon richtig. Ich will die auch garnicht vermischen. Aber die Frage ob ich diese versteckten Verbindungen per XML-RPC abfragen kann hat nichts mit der App zu tun. Und ist hoffentlich ich noch im Scope des Issue.
Das ist schon richtig.
Ich will die auch garnicht vermischen. Aber die Frage ob ich diese versteckten Verbindungen per XML-RPC abfragen kann hat nichts mit der App zu tun. Und ist hoffentlich ich noch im Scope des Issue.
Wenn du hoch scrollst wirst du sehen das das von @jp112sdl schin mehrfach beantwortet wurde und genau diese 63er Direktverknüpfungen nicht via XMLRPC oder anderen API Methoden abzufragen geht.
Das ist schon richtig. Ich will die auch garnicht vermischen. Aber die Frage ob ich diese versteckten Verbindungen per XML-RPC abfragen kann hat nichts mit der App zu tun. Und ist hoffentlich ich noch im Scope des Issue.
Wenn du hoch scrollst wirst du sehen das das von @jp112sdl schin mehrfach beantwortet wurde und genau diese 63er Direktverknüpfungen nicht via XMLRPC oder anderen API Methoden abzufragen geht.
Es tut mir leid ich habe den Beitrag dazu nicht gefunden. Zu mindestens nicht in den Beiträgen seit dem @Baxxy13 heraus gefunden hat wie der Link zu löschen ist. Bzw. das es die Verbindung zu Central_Device:63 hier Relevanz hat. Ich hatte gedacht das diese Verbindung vielleicht nur nicht im Rückgabewert ist. Wenn man aber explizit fragt, das es dann irgendeine Möglichkeit gibt die Verbindungen zubekommen.
Der Vollständigkeit halber sei noch mal erwähnt, dass sich auch bei BidCos Geräten nicht abfragen lässt, ob diese ein (zusätzliches) Telegramm an die Zentrale senden. Dort gibt es auch keinen internen Zentralen-Link.
Bisher hat das auch niemanden gestört, da reportValueUsage mit refCounter > 0 dem Gerät gesagt hat "Schicke ein Telegramm auch an die Zentrale" bzw. mit refCounter = 0, "Schicke kein Funktelegramm an die Zentrale".
Das einzig hinderliche bei HmIP ist, dass refCounter = 0 nicht funktioniert.
Wenn diese Kleinigkeit repariert wäre, würde alles nach außen hin so sein wie bei BidCos / Wired. Und auch so wie es in der Dokumentation steht. Ich verweise gern noch auf den Forenbeitrag: https://homematic-forum.de/forum/viewtopic.php?f=31&t=76196&p=739401#p739401
Ich hab einen sehr schmutzigen Weg gefunden um über XML-RPC abzufragen ob es einen Link mit dem Central_Device:63 gibt.
Wenn man den Link versucht zu löschen obwohl es ihn nicht gibt, bekommt kann einen Generic Error . Wenn man allerdings einen Link löscht den es gibt bekommt man einen Erfolg. Bestimmt nicht die beste Sache für den Duty Cycle weil man bei erfolg den Link natürlich auch wieder erstellen muss.
Gibt es einen Weg den refCounter per XML-RPC abzufragen? Dann könnte man sich das löschen und wieder anlegen sparen.
Ich hab einen sehr schmutzigen Weg gefunden um über XML-RPC abzufragen ob es einen Link mit dem Central_Device:63 gibt.
Die Variante hatten wir auch schon im Kopf. Das mit dem Result ist bekannt. Und nicht nur wegen des DC - es käme auch jedes Mal eine Servicemeldung, dass Konfigurationsdaten zur Übertragung anstehen (zumindest bei Fernbedienungen).
Der refCounter = ChnDPUsageCount und wird an den Schnittstellenprozess gesendet, damit dieser entscheiden kann "Ja, ich muss den internen Link anlegen" oder "Nein, der Link kann".
Der Wert wird nicht im Gerät gespeichert.
Hallo, Glückwunsch zum fertigen PR!
Ich möchte nochmal eine Frage aus dem Thread aufgreifen.
Die Funktionalität der Anlegen/Aktivieren und Entfernen/Deaktivieren Schaltfläche aus dem PR, sowie die Funktion zur Prüfung eines Zentralen-Links, sind bereits heute via XMLRPC nutzbar!? Die Entwickler des Projekts hahomematic könnten also bereits heute das ursprünglich beschriebene Problem in einer entsprechenden Routine lösen? Danke für die Klärung.
Das Anlegen und Löschen geht wie im PR ersichtlich via XMLRPC, ja. Aber das Abfragen nicht. Dafür fehlt noch die passende Funktionalität in der XMLRPC API die nur eQ3 nachpflegen kann.
D.h. Man kann nur blind anlegen und löschen und hat aber aktuell keine Möglichkeit den Status des "Zentralen Links" abzufragen.