HUEBridge push api unterstützung

[Jamo]

ich hatte nochmal den Fall, dass bei einem FHEM Neustart ein alter Tastendruck eines Zigbee Tasters als "neues Event" gewertet wurde und das SmartHome sich "verselbstständigt" hat.

Sowas hatte ich letzte Nacht auch. Ich habe gesehen dass ein Event von mehreren Dimmern und auch DeConZ Buttons ausgelöst wurde (logfile). Im Dimmer oder Button selber ist das Reading ''state'' aber noch mehrere Tage alt.
Um das Problem abzufangen, frage ich jetzt im notify das Readingsage des state vom jeweiligen Device ab. Nach einem Tastendruck sollte das event sofort kommen, also readingsAge < 5 Sekunden.

Code: [Auswählen]

##########################################################
# HUE DIMMER
# notify definition with Sub
# defmod HueDimmer_n notify HueDimmer._.*:.00. {myHueDimmer($NAME,$EVENT)}
##########################################################
sub myHueDimmer {
  my $sub    = 'myHueDimmer';
  my $NAME   = shift // return "Error, $sub: we need NAME as parameter!";
  my $EVENT  = shift // return "Error, $sub: we need EVENT as parameter!";
  #       [myHueDimmer] Name=HueDimmer1_Wohn, EVENT=2002
  Log 3, "[$sub]        Name=$NAME,           EVENT=$EVENT";

  # In case of a Ghost event, the ReadingsAge of the state of the physical button is too old
  if (ReadingsAge($NAME,'state',8) < 4) {# prevent ghost events, checking ReadingsAge
   # Hier Auswertung des Events und triggern einer Aktion
  }
  else {Log 3, "[$sub] GHOST Event, Name=$NAME, EVENT=$EVENT";}
}

[Thyraz]

Danke für die Rückmeldung.
Dann bin ich ja doch nicht ganz allein. 

Auf die Idee es mit so einem Workaround zu versuchen kam ich gar nicht.

Klar, dass Readingsdatum auf den Timestamp von Deconz zu setzen klingt aus Modulsicht logisch,
aber mir war nicht bewusst, dass Entwickler das in FHEM so umsetzen können.

Den ganzen Funktionen zum Updaten der Readings kann ja eigentlich gar kein Zeitstempel mit übergeben werden:
https://wiki.fhem.de/wiki/DevelopmentModuleAPI

[Jamo]

PS: Ich habe oben noch das notify mal als codeschnipsel eingefügt.

[justme1968]

@Thyraz: doch das geht über einen kleinen umweg und das macht das modul auch. die hauptsächlichen einschränkungen dabei sind:
- der long poll update um frontend zeigt den falschen (aktuellen) timestamp und nicht den tatsächlichen
  nach einem refresh ist das aber ok
- mit filelog kann es probleme geben wenn die reihenfolge der einträge nicht stimm. das passiert
  aber hier nicht.

beim mehrmals drüber nachdenken ist mir die idee gekommen das man pro reading über ein attribut konfigurieren könnte das kein event erzeugt wird wenn das reading älter als x sekunden ist.

damit müssten sich eigentlich alle problemfälle abdecken lassen.

eine weitere möglichkeit wäre das man das pollen komplett deaktiviert wenn das erste event kommt. ich weiss aber noch nicht wie wir damit umgehen das die events ausbleiben könnten.

[Thyraz]

Du müsstest diese Info per Device eben so abspeichern, dass du es noch nach dem Restart weißt.
Also irgendwo persistent und nicht flüchtig.

Pollen generell deaktivieren nach dem ersten Event (das könntest du ja durchaus persistent machen, so dass die Info nach einem Neustart immer noch da ist) würde ich nicht machen.

Bei manchen Geräten will man ja dennoch den letzten Wert, auch wenn FHEM ggf. wegen Wartungsarbeiten mal down war.


Die erste Idee klingt aber gut so. 


@Jamo, danke für deinen Workaround, bau ich dann vorerst auch mal so ein.

[uge]

Hallo,
ich möchte nur sagen, dass das Triggern mit "alten Events" bestimmt keine sehr seltenen Einzelfälle sind.
Bei mir wurden in der Nacht der Zeitumstellung alle DOIFs, welche per Tastendruck mit IKEA-Buttons toggeln, ausgelöst.
Ich würde mich daher auch über ein "ReadingsAge"-Attribut freuen.
Grüße

[Thyraz]

Ich setz mal noch nen Link zu dem Thread, da dort auch jemand auf das Problem gestoßen ist:
https://forum.fhem.de/index.php?topic=127046.msg1215955#msg1215955

[Obi-Wan]

Hallo,
seit dem Update auf die neue Version erhalte ich nun (mit Unterbrechungen) im stündlichen Rhythmus die folgenden Logeinträge:

Code: [Auswählen]

2022.04.12 01:04:04 2: Philips_HUE: http request failed: read from https://IPADR:443 timed out
2022.04.12 01:04:04 2: Philips_HUE: EventStream: terminated

Das Attribut "eventstreamTimeout" (undokumentiert in Commandref) deutet auf eine pot. Lösung hin.
Gibt es hier Erfahrungswerte für einen "richtigen" Wert? In welcher Einheit erfolgt die Wertangabe und gibt es ggf. negative Auswirkungen wenn der Wert zu groß gewählt wird ?

Danke für eine Prüfung und Rückmeldung,
Obi-Wan

[rudolfkoenig]

2022.04.12 01:04:04 2: Philips_HUE: http request failed: read from https://IPADR:443 timed out

Womoeglich haengt das mit einem anderen Problem zusammen: https://forum.fhem.de/index.php?topic=127077

[Obi-Wan]

Womoeglich haengt das mit einem anderen Problem zusammen: https://forum.fhem.de/index.php?topic=127077

Stimmt, könnte passen.
Allerdings kann ich bei meiner Installation keinerlei Verzögerungen beim Zugriff der Weboberfläche oder den Schaltvorgängen feststellen, reboots waren in letzter Zeit ebenfalls nicht notwendig und fhem.pl läuft noch in der auch von Heiko im zitierten Thread für gut befundenen Version 25777/2022-03-05

Insofern würde ich in diesem Fall eher auf ein lokales Thema im Zusammenspiel des HUEBridge-Moduls mit der HUEBridge tippen.

[justme1968]

die hue meldungen haben ziemlich sicher eine andere ursache.

die bridge nimmt mit aktueller firmware weniger parallele verbindungen an als vorher. signify empfiehlt sogar nur eine http/2 verbindung zu verwenden und dort einzelne steams zu verwenden. alternativ eine queue für http/1.x

fhem kann ersteres (noch) nicht und letzteres ist aktuell nicht eingebaut da es eine größere änderung im modul wäre.

da die meldungen normalerweise vom pollen kommen und nicht vom schalten sollte es wenig bis keine negativen auswirkungen haben. alles was das pollen verringern kann hilft aber. da es in der aktuellen version den event support gibt und das pollen für sensoren eigentlich automatisch verhindert wird wenn events gekommen sind wäre die frage ob eventuell diese änderungen manchmal nicht greifen oder die bridge aus anderen gründen ausgelastet ist.


der zweite fall in dem es solche meldungen gibt ist der normale ab und wieder aufbau des event streams. da die verbindung absichtlich zu und wieder aufgemacht wird sollte es eigentlich garkein meldung geben. das scheint nur manche installationen zu betreffen. mir ist noch nicht ganz klar ob es speziell welche mit wenigen events sind oder welche mit vielen.  hier sollte das setzen von eventstreamTimeout auf einen großen wert helfen. der wert ist in sekunden zu verstehen. probieren kann man ruhig 86400 oder ähnliches.

[Obi-Wan]

OK verstehe, hier noch mehr Details zu meiner lokalen Installation hier: Ich ziehe die FHEM Produktivumgebung aktuell auf eine neue HW um - aus Zeitgründen Stück für Stück und daher laufen, soweit nötig/möglich auch einige Module parallel auf dem Alt- und Neusystem.

Auf dem Altsystem läuft 30_HUEBridge.pm:0.242960/2021-04-21 und erzeugt keinerlei der o.a. Logeinträge wohingegen auf dem Neusystem 30_HUEBridge.pm:0.257690/2022-03-03 läuft und die geschilderten Logs in schöner Regelmäßigkeit erzeugt.

Ich werde also sobald möglich das HUE-Modul auf dem Altsystem deaktivieren und mal beobachten wie und ob sich das Logverhalten auf dem Neusystem verändert, komisch ist nur das die Abbrüche bislang nur auf dem Neusystem erfolgen. Hilft das nicht werde ich wie vorgeschlagen den Timeout entsprechend hochsetzten.
Danke und Gruß,
Obi-Wan

[Obi-Wan]

Update:
Abschalten des Altsystems brachte keine Veränderung im Logverhalten. Gestern Abend dann Timeout auf 28800 gesetzt, seit 27 Stunden keinen einzigen Logeintrag mehr....