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 2 years ago

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.

jp112sdl commented 2 years ago

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.

Baxxy13 commented 2 years ago

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?

stale[bot] commented 2 years ago

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.

ThomDietrich commented 2 years ago

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ß

jonaswre commented 2 years ago

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.

Baxxy13 commented 2 years ago

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)

jens-maus commented 2 years ago

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?!?

jp112sdl commented 2 years ago

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.

Baxxy13 commented 2 years ago

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.

jens-maus commented 2 years ago

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.

jens-maus commented 2 years ago

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.

Baxxy13 commented 2 years ago

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.

jp112sdl commented 2 years ago

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.

jonaswre commented 2 years ago

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

Baxxy13 commented 2 years ago

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.

jonaswre commented 2 years ago

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 👍🏻

jp112sdl commented 2 years ago

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.

jp112sdl commented 2 years ago

Ich habe mal den PR #2017 reingestellt, der die beiden Skript-Methoden von Baxxy in WebUI Buttons verpackt.

jonaswre commented 2 years ago

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.

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>

jp112sdl commented 2 years ago

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.

jens-maus commented 2 years ago

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.

jonaswre commented 2 years ago

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.

jens-maus commented 2 years ago

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.

jonaswre commented 2 years ago

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.

jp112sdl commented 2 years ago

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

jonaswre commented 2 years ago

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.

jp112sdl commented 2 years ago

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.

ThomDietrich commented 1 year ago

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.

jens-maus commented 1 year ago

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.

SukramJ commented 4 weeks ago

Aber das Abfragen nicht. Dafür fehlt noch die passende Funktionalität in der XMLRPC API die nur eQ3 nachpflegen kann.

Wie sieht denn für Abfragen der passend Skript Code aus? Ich binde ja bereits jetzt schon Skripte in hahomematic (Homematic(IP) Local) ein, weil nicht alles über die XMLRPC API bereitgestellt wird.

Baxxy13 commented 4 weeks ago

Es gibt keinen Homematic-Script Code der eine Rückgabe bezüglich vorhandener/nicht vorhandener CENTRAL-LINKS ermöglicht. Auch wurde m.W. keine XML-RPC Methode implementiert um den Status bezüglich CENTRAL-LINK abzufragen. Also alles beim Alten...

SukramJ commented 4 weeks ago

@Baxxy13 Danke für die Rückmeldung

jp112sdl commented 4 weeks ago

https://github.com/eq-3/occu/blob/master/WebUI/www/api/methods/interface/getlinks.tcl getLinks mit entsprechender Geräteadresse und flags = 2 gibt auch nichts zurück?

jonaswre commented 4 weeks ago

Ich hatte mal die Anforderung, zu testen, ob ein Gerät einen Central Link hat. Damals habe ich das so gelöst, dass ich versucht habe, den Central Link zu löschen. Dabei erhält man einen anderen Rückgabewert, falls der Link bereits vorhanden war. Anschließend habe ich den Link wieder neu angelegt. Dieser Ansatz ist zwar nicht besonders sauber, hat aber für meinen Anwendungsfall funktioniert. Falls Interesse besteht, kann ich nochmal das genau Beispiel raussuchen.

jonaswre commented 4 weeks ago

Found the dart code

  Future<bool> hasLinkToCentralDevice(ChannelId address) async {
    final centralDevice = ChannelId(
      deviceId: DeviceId('CENTRAL_DEVICE'),
      index: 63,
    );

    try {
      await this.removeLink(address, centralDevice);
      await this.addLink(address, centralDevice, '', '');
      return true;
    } catch (e) {
      return false;
    }
  }

jens-maus commented 4 weeks ago

Dabei sollte man jedoch beachten das das vmtl den DutyCycle erhöhen wird wenn man da somit removeLink+readd nur zum prüfen durchführen lässt. Ergo sollte man vorsichtig damit umgehen wenn man nicht Gefahr laufen will bei einer Zentrale mit vielen Geräten nur durch diese Art der Central-Link Prüfung die Zentrale quasi für eine Stunde zu blockieren...

Baxxy13 commented 4 weeks ago

getLinks mit entsprechender Geräteadresse und flags = 2 gibt auch nichts zurück?

Nope...

{
 "method": "Interface.getLinks",
 "params": {
 "_session_id_": "hFeqEAF93E",
 "interface": "HmIP-RF",
 "address": "00021A498A4C88:1",
 "flags": "2"
 }
}

{
    "version": "1.1",
    "result": [],
    "error": null
}

SukramJ commented 4 weeks ago

Vielen Dank für die Infos. Mir ist das Löschen/Wiederanlegen ein wenig zu invasiv, da die Integration bisher nichts ungefragt auf der CCU geändert hat. Ich werd mir das mal anschauen , aber im Zweifel auch nicht umsetzten.

Baxxy13 commented 3 weeks ago

Man sollte auch bedenken das dieses Löschen/Wiederanlegen jedes mal in den Flash des Senders schreibt. Außerdem muss die Config übertragen werden was, wie Jens schon schrieb, auf den DC geht und es muss bei Batteriegeräten die Systemtaste gedrückt werden. Alles in Allem nicht wirklich erstrebenswert.

Hatte gestern noch paar Sachen ausprobiert, aber nichts gefunden. Es bleibt also dabei: Ohne Implementierung einer Methode zum Abfragen (seitens eQ-3) geht das halt nicht.

SukramJ commented 3 weeks ago

Das einzig hinderliche bei HmIP ist, dass refCounter = 0 nicht funktioniert.

Wenn ich nichts übersehen habe, dann funktioniert das mittlerweile auch bei HmIP.

Baxxy13 commented 3 weeks ago

Ja, das passt mittlerweile. Nur ist der refCounter zumindest auf RM kein sicheres Indiz da wir ja den Link anlegen können ohne ein WebUI-Programm zu nutzen. Oder anders gesagt, wird der Link angelegt ohne ein WebUI-Programm zu nutzen dann wird auch der refCounter nicht erhöht.

SukramJ commented 3 weeks ago

Wenn der refCounter zum Anlegen einer Zentralenverknüpfung auf 1 und zum Entfernen auf 0 gesetzt wird, wo wäre dann der Unterschied zu https://github.com/jens-maus/RaspberryMatic/commit/fee847b9ccc3af7bb56b9efd0fa2078af55cf6ba .

Ich hab nicht vor da eine Automatik einzubauen, die über alle PRESS* Datenpunkte läuft, solange ich den Status nicht einfach abfragen kann!

Baxxy13 commented 3 weeks ago

Ich hatte nicht mehr auf dem Schirm das der Patch auch den refCounter setzt. Die Frage wäre aber ob und wie man den auslesen kann. Dann hätte man einen guten Indikator. Ich hab da erstmal nichts zu gefunden.

Theoretisch könnte man den Patch auch "abspecken" da inzwischen reportValueUsage auch bei HmIP funktioniert. addLink / removeLink zum CENTRAL_DEVICE:63 sind nicht mehr notwendig.

Ich hab nicht vor da eine Automatik einzubauen, die über alle PRESS* Datenpunkte läuft, solange ich den Status nicht einfach abfragen kann!

Alles gut, das soll ja auch nicht. Vom Prinzip kann man das mit reportValueUsage auf den Tasterkanal in einem Rutsch machen. Da werden automatisch alle PRESS* Datenpunkte eingeschlossen.

Und das Gute ist, ist der refCounter schon 1 dann passiert nichts, also auch keine Kommunikation zum Gerät. Aktivieren: echo 'load tclrpc.so; puts [xmlrpc http://127.0.0.1:32010 reportValueUsage [list string 00021A498A4C88:1] [list string 14209] [list int 1]]' | tclsh

Deaktivieren: echo 'load tclrpc.so; puts [xmlrpc http://127.0.0.1:32010 reportValueUsage [list string 00021A498A4C88:1] [list string 14209] [list int 0]]' | tclsh

Der Haken, man braucht die ID des Kanals.

SukramJ commented 3 weeks ago

Der Haken, man braucht die ID des Kanals.

Bei XMLRPC nicht.

Baxxy13 commented 3 weeks ago

Hmm, dann zeig mal. Ich bin für alles offen.

reportValueUsage(channel_address address, string value_id, integer ref_counter)

SukramJ commented 3 weeks ago

value_id == "PRESS_SHORT". Der Rest ist klar.

Wie im PR.

SukramJ commented 3 weeks ago

Statt PRESS_SHORT kann man aber auch KATZE oder MOORHUHN eintragen. Geht immer

SukramJ commented 3 weeks ago

Es sieht aber so aus, als ob man mit der value_id löschen muss die man auch zum Erstellen verwendet hat.

Baxxy13 commented 3 weeks ago

Interessant, ja... die value_id muss identisch sein.

jens-maus / RaspberryMatic