tradfri-fhem tester gesucht

[DeeSPe]

Ich denke herausgefunden zu haben woran es mit diesen Events liegt!
Sobald "closing" gefeuert wird, wird das notify ausgelöst und das geht nun so schnell dass er noch über 95% geöffnet ist. Somit bekommt er ein zweites Mal den Befehl zum Herunterfahren und das wiederum erzeugt "stopped" und wieder "closing", womit das notify natürlich wieder ausgelöst wird. Stelle ich nämlich ein dass er bei "closing" wieder auf 99% fahren soll, klappt es wie gewünscht.
Bug oder Feature? Auf jeden Fall ist es Käse dass er zwischendurch "stopped" feuert wenn es in die selbe Richtung weiter geht.
Bekommst Du das evtl. noch abgefangen?

Gruß
Dan

[justme1968]

entkoppel mal das set in deinem notify mit einem sleep 0.01 davor und schau ob es dann geht.

wenn du noch etwas testen magst: in modul gibt es in der parse routine ziemlich am ende das ReadingsEndUpdate und danach eine ganze reihe von $hash-{helper}{readingxy} = $readingxy. schieb mal das ReadingsEndUpdate nach die zeile mit der zuweisung für pct. ändert das etwas ?


mist. den timer bzw. watchdog hatte ich absichtlich weg gelassen und gehofft das es auch ohne geht. die wartezeit lässt sich ja nicht genau bestimmen weil es davon abhängt wann genau beim weiter fahren gesendet wird. und das ist zumindest zum teil zufällig.

mit einem timer bekommt man ja auch nicht alle stop und wieder anfahren mit. was ist wenn man innerhalb der drei sekunden stoppt und wieder startet?

ein inhibit wie bei hm wäre schön... gibt es aber nicht.

also doch timer?


du warst schneller. funktioniert es statt auf 95% zu fahren wieder ganz hoch fährst ?
ich hatte auch mal ein stop eingebaut. ich weiss aber nicht ob das funktioniert. das wäre auch eine option.
das stopped kommt in zwei fällen: in endlager. das ist hier nicht der fall und wenn das gateway zwei mal den gleichen pct wert sendet. ist es das ? vielleicht hilft eine der beiden ideen von ganz oben.

[DeeSPe]

Leider hat weder das sleep etwas gebracht noch das Verschieben von readingsEndUpdate aus Zeile 1890.
Bei meinem momentanen Tests klappt es selbst nicht mehr mit dem Setzen auf 99, das notify löst wie vorher 3x aus. Häääää? Verstehe ich nicht!

Hier die Events:

Code Auswählen Erweitern

2021-02-11 22:45:07 HUEDevice dz_Rollo pct: 99
2021-02-11 22:45:07 HUEDevice dz_Rollo direction: closing
2021-02-11 22:45:07 HUEDevice dz_Rollo state: 99
2021-02-11 22:45:07 HUEDevice dz_Rollo direction: stopped
2021-02-11 22:45:08 HUEDevice dz_Rollo pct: 94
2021-02-11 22:45:08 HUEDevice dz_Rollo direction: closing
2021-02-11 22:45:08 HUEDevice dz_Rollo state: 94
2021-02-11 22:45:08 HUEDevice dz_Rollo direction: stopped
2021-02-11 22:45:09 HUEDevice dz_Rollo pct: 91
2021-02-11 22:45:09 HUEDevice dz_Rollo direction: closing
2021-02-11 22:45:09 HUEDevice dz_Rollo state: 91
2021-02-11 22:45:09 HUEDevice dz_Rollo direction: stopped
2021-02-11 22:45:10 HUEDevice dz_Rollo pct: 96
2021-02-11 22:45:10 HUEDevice dz_Rollo direction: opening
2021-02-11 22:45:10 HUEDevice dz_Rollo state: 96
2021-02-11 22:45:11 HUEDevice dz_Rollo pct: 100
2021-02-11 22:45:11 HUEDevice dz_Rollo direction: stopped
2021-02-11 22:45:11 HUEDevice dz_Rollo state: 100
Hier war das notify sogar so eingestellt dass es bei "closing" "set dz_Rollo pct 100" ausführt.

Gruß
Dan

[DeeSPe]

Hab noch einen weiteren Test gemacht und zusätzlich mein userReading und den watchdog wieder aktiviert, allerdings auf das Reading "dir", so dass man beide parallel betrachten kann. Dabei hat auch alles wieder so geklappt wie es soll.
Hier mal der Event Monitor beim Auslösen des notify:

Code Auswählen Erweitern

2021-02-11 22:59:48 HUEDevice dz_Rollo pct: 99
2021-02-11 22:59:48 HUEDevice dz_Rollo direction: closing
2021-02-11 22:59:48 HUEDevice dz_Rollo state: 99
2021-02-11 22:59:48 HUEDevice dz_Rollo dir: closing
2021-02-11 22:59:48 HUEDevice dz_Rollo direction: stopped
2021-02-11 22:59:50 HUEDevice dz_Rollo pct: 94
2021-02-11 22:59:50 HUEDevice dz_Rollo direction: closing
2021-02-11 22:59:50 HUEDevice dz_Rollo state: 94
2021-02-11 22:59:50 HUEDevice dz_Rollo pct: 91
2021-02-11 22:59:50 HUEDevice dz_Rollo state: 91
2021-02-11 22:59:51 HUEDevice dz_Rollo pct: 95
2021-02-11 22:59:51 HUEDevice dz_Rollo direction: opening
2021-02-11 22:59:51 HUEDevice dz_Rollo state: 95
2021-02-11 22:59:51 HUEDevice dz_Rollo dir: opening
2021-02-11 22:59:55 HUEDevice dz_Rollo dir: stopped

Gruß
Dan

[DeeSPe]

Ich hatte es bisher nicht erwähnt, evtl. weißt Du es auch schon, aber der "stop" Befehl hat generell keine Auswirkungen auf das Rollo.
Am Rollo selbst oder mit der FB ist es so dass man einfach noch einmal eine der beiden Tasten drückt und damit ein "stop" auslöst.

Gruß
Dan

[DeeSPe]

Hallo Andre,

ich habe mal Zeile 1840 auskommentiert:

Code Auswählen Erweitern

      #$readings{direction} = 'stopped';
und Zeile 1882 geändert in:

Code Auswählen Erweitern

      readingsBulkUpdate($hash, $key, $readings{$key}, 1) if( !defined($hash->{helper}{$key}) || ($hash->{helper}{$key} ne $readings{$key} || $key eq "direction") );

Damit funktioniert es nun genau so wie es auch mit meinem userReading funktioniert.

Einzig der "stop" Befehl funktioniert (noch) nicht.

Gruß
Dan

EDIT: Und das "stopped" zwischen 1 und 99 muss natürlich weiterhin mein watchdog machen. Wie Du schon geschrieben hast, ist es schwer das vernünftig ins Modul zu implementieren da es nicht immer sicher ist dass sich das Reading noch später ändert. Ich könnte aber damit leben das per watchdog zu lassen.

[justme1968]

hmmm...

prinzipiell sollte sich das verhalten aus dem notify und direkt aus dem modul nicht unterscheiden. mal abgesehen vom timer der im modul nicht da ist. im modul mache ich ja auch nichts anderes als mit dem vorherigen wert zu vergleichen.

was mir auf den ersten blick auffällt ist das sich die logik in deinem notify minimal von der aus dem modul unterscheidet.

hast du mal verglichen wie reproduzierbar die werte die vom rollo rein kommen überhaupt sind? das sendet ja leicht asynchron zum fahren und ich glaube es werden nicht immer direkt die start und stop werte gesendet.

ich versuche nachher noch mal zu testen.

[DeeSPe]

Letztendlich sorgt meine erste Änderung nur dafür kein "stopped" zu setzen wenn der alte Wert gleich dem neuen Wert ist. Das hat offenbar die Probleme verursacht, vermutlich wegen der vorhandenen Asynchronität. Damit kommt beim plötzlichen Wiederhochfahren nicht plötzlich das zusätzliche "stopped/closing" dazwischen.
Die zweite Änderung sorgt auch nur dafür dass das Reading "direction" immer wieder gesetzt wird, auch wenn es identisch zum vorhergehenden Wert ist, ich denke das ist nicht so tragisch und ich habe es mit "event-on-change-reading" entprellt. Könnte man an dieser Stelle nicht statt "readingsBulkUpdate" einfach "readingsBulkUpdateIfChanged" einsetzen statt dem "if" Konstrukt dahinter?

Gruß
Dan

[justme1968]

readingsBulkUpdateIfChanged gab es noch nicht als das modul entstanden ist . das ganze ist schon etwas älter.

aber unabhängig von der methode: wenn der neue wert gleich dem alten ist sollte diese stelle sowieso keinen unterschied machen. und mit readingsBulkUpdateIfChanged wäre es auch schwerer dein or noch mit einzubauen.

wie gesagt: ich schaue nachher noch mal.

[eschie]

Hi,
ich benutze die Anbindung der Tradfri-Gateways nun schon seit längerem. Ich regel den Tag über sehr viel an den Helligkeiten und Farbtönen der Lampen in Abhängigkeit der Tageszeit und Außenhelligkeit. Leider passiert es, dass ich immer wieder die Kontrolle über alle Devices verliere. Sie reagieren nicht mehr auf Befehle aus FHEM heraus. Ich kann aber über die App auf dem Handy weiter die Lampen steuern. Das heißt am Gateway kann es nciht liegen. Teilweise empfängt FHEM sogar noch korrekte Rückmeldungen über den Status der Lampen. Ich habe in letzter Zeit versucht die Ursache/Quelle einzugrenzen und bin dabei auf verschiedene Möglichkeiten gestoßen, die Devices in FHEM wieder unter Kontrolle zu bekommen.
* Das Gateway vom Strom trennen löst die Probleme jedes mal, aber die Ursache kann das Gateway nicht sein, da ich über die Handyapp ja noch weiter die Lampen steuern kann.
* FHEM-Neustarts löst das Problem in der Regel nicht, nur in ganz seltenen Fällen läuft danach wieder alles.
* das Stoppen und Starten des "tradfri" Devices in FHEM löst die Unterbrechung beim Stoppen meist für wenige Befehle. Es lassen sich 2 bis 3 Lampen kurzzeitig steuern, dann geht wieder nichts mehr.
* mehrmaliges Stoppen und Starten führt irgendwann wieder dazu, dass die Geräte ein paar Tage steuerbar sind. Manchmal lässt sich das System so aber auch nicht wiederbeleben.
* in 95% der Abstürze hilft es den "node" prozess, in dem die FHEM-Tradfri-Bridge läuft zu killen und dann das device in FHEM neuzustarten. die restlichen 5 % lassen sich durch wiederholtes killen der Prozesse lösen.

Ich habe das Tradfri device in FHEM schon mal mit "verbose 5" laufen lassen. ich konnte in den logs aber nichts finden, was auf das Problem hinweist. Ich vermute, dass es in dem Java-Skript-Teil hakt. ich habe aber leider keine Java-Erfahrung und kann diesen Teil nicht debuggen.

Auch habe ich das Problem sowohl auf einem Ubuntu 18.04 LTS auf x64 Basis beobachtet, als auch auf einem Raspbian.

Kann mir hier jemand helfen, oder hat weitere Tipps oder Anregungen, wie ich die Ursache finde?

[aje89]

Hi,
ich benutze die Anbindung der Tradfri-Gateways nun schon seit längerem. Ich regel den Tag über sehr viel an den Helligkeiten und Farbtönen der Lampen in Abhängigkeit der Tageszeit und Außenhelligkeit. Leider passiert es, dass ich immer wieder die Kontrolle über alle Devices verliere. Sie reagieren nicht mehr auf Befehle aus FHEM heraus. Ich kann aber über die App auf dem Handy weiter die Lampen steuern. Das heißt am Gateway kann es nciht liegen. Teilweise empfängt FHEM sogar noch korrekte Rückmeldungen über den Status der Lampen. Ich habe in letzter Zeit versucht die Ursache/Quelle einzugrenzen und bin dabei auf verschiedene Möglichkeiten gestoßen, die Devices in FHEM wieder unter Kontrolle zu bekommen.
* Das Gateway vom Strom trennen löst die Probleme jedes mal, aber die Ursache kann das Gateway nicht sein, da ich über die Handyapp ja noch weiter die Lampen steuern kann.
* FHEM-Neustarts löst das Problem in der Regel nicht, nur in ganz seltenen Fällen läuft danach wieder alles.
* das Stoppen und Starten des "tradfri" Devices in FHEM löst die Unterbrechung beim Stoppen meist für wenige Befehle. Es lassen sich 2 bis 3 Lampen kurzzeitig steuern, dann geht wieder nichts mehr.
* mehrmaliges Stoppen und Starten führt irgendwann wieder dazu, dass die Geräte ein paar Tage steuerbar sind. Manchmal lässt sich das System so aber auch nicht wiederbeleben.
* in 95% der Abstürze hilft es den "node" prozess, in dem die FHEM-Tradfri-Bridge läuft zu killen und dann das device in FHEM neuzustarten. die restlichen 5 % lassen sich durch wiederholtes killen der Prozesse lösen.

Ich habe das Tradfri device in FHEM schon mal mit "verbose 5" laufen lassen. ich konnte in den logs aber nichts finden, was auf das Problem hinweist. Ich vermute, dass es in dem Java-Skript-Teil hakt. ich habe aber leider keine Java-Erfahrung und kann diesen Teil nicht debuggen.

Auch habe ich das Problem sowohl auf einem Ubuntu 18.04 LTS auf x64 Basis beobachtet, als auch auf einem Raspbian.

Kann mir hier jemand helfen, oder hat weitere Tipps oder Anregungen, wie ich die Ursache finde?

Enablen und disablen des tradfri Adapters hilft bei mir jedesmal.
Für mich ist die Lösung alles auf deCONZ umzustellen.
Die Ikea App verliert bei mir auch ständig die Verbindung und ich muss den Code neu scannen.

[justme1968]

das liegt leider an der darunter liegenden node-tradfri-client lib und zum teil daran das es kein offizielles api von ikea gibt.

alle x stunden automatisch ein set reconnect oder set restart machen ist zwar nur ein workaround sollte aber helfen.

eventuell und bei reproduzierbaren bedingungen wäre es gut bei node-tradfri-client ein ticket auf zu machen.

[error500]

Hallo zusammen,

ich habe ähnliche Probleme wie von eschie beschrieben. Bei mir hat es bisher immer geholfen ein restart am fhem tradfri-gateway abzusetzen.

Habe mir eben mal das Changelog von node-tradfri-client angesehen und bin dort darauf aufmerksam geworden, dass am 24.02.2021 mit Version 2.2.0 ein paar Sachen hinzugefügt wurden. Ich habe dann mal zum Test nach der Zeichenkette "whenPowerRestored" in den Dateien im tradfri-client Verzeichnis gesucht. Nichts. Auch nach einem "npm update" wurde nichts gefunden. NPM ist jetzt nicht wirklich meine Stärke, also habe ich das Paket tradfri-fhem einfach mal deinstalliert und wieder installiert. Anschließend habe ich auch die eben erwähnte Zeichenkette gefunden.

Ob das Problem damit nun behoben ist oder nicht, kann ich noch nicht sagen. Aber für mich steht erst mal fest, dass node-tradfri-client auf meinem pi trotz "npm update" nicht aktuell war. Vielleicht hilft das ja jemandem weiter, bzw. jemand kann mir sagen, wie das Update korrekt durchzuführen ist.

Viele Grüße
Mark

[error500]

Hallo nochmal,

ich habe mein Problem mal etwas genauer unter die Lupe genommen: Die Readings der Tradfri-Geräte sind nach einer gewissen Zeit nicht mehr aktuell. Dann muss ich das fhem Tradfri-Gateway Device neu starten. Die Readings (aller Tradfri-Geräte) werden dann sofort aktualisiert und nach einiger Zeit sind die wieder nicht mehr aktuell. (Nach einem Befehl an eine Lampe über App oder FHEM werden, sofern noch "synchron", sämtliche Readings des angesteuerten Geräts aktualisiert.)

Um das einzugrenzen habe ich ein Tradfri-Device ausgewählt, bei dem ich mit einem AT alle X Minuten einen set-Befehl absetze um eine Readings-Änderung zu bewirken. Ergebnis: wenn das AT länger als ca. 5 Minuten nichts verändert, dann verabschiedet sich irgendwas. Wird in den 5 bis 6 Minuten immer was an einem Device geändert, dann bleiben die Readings auch über 2 Tage synchron. Wenn diese 5 bis 6 Minuten um sind und währenddessen kein set auf irgendein Tradfri-Device abgesetzt wurde, verändert sich anschließend kein Tradfri-Reading mehr. Die Lampen sind jedoch alle noch ansteuerbar (es wird dann aber kein mehr Reading aktualisiert).

Leider kann ich mit meinem Wissen den Grund nicht weiter einschränken. Daher lasse ich aktuell mein AT weiterlaufen, dass alle 5 Minuten an einer Trafri-Lampe was ändert, damit alle Readings aller Tradfri-Geräte aktuell bleiben.

Hat jemand eine Idee?

Viele Grüße
Mark

[AlexWall]

Hallo zusammen,

ich habe das Problem, dass ich beim start des Moduls folgenden Fehler bekomme:

2: tradfri: starting tradfri-fhem: /usr/bin/tradfri-fhem -s xxxxxxxxxxxxxxx --ip 192.168.1.6
2021.04.01 18:48:34 5: tradfri: using /usr/bin/tradfri-fhem
2021.04.01 18:48:34 3: tradfri: starting
2021.04.01 18:48:34 3: tradfri: using FHEM logfile
2021.04.01 18:48:35 5: tradfri: read: [2021-4-1 6:48:35 PM] this is tradfri-fhem 0.1.8
2021.04.01 18:48:35 5: tradfri: read: [2021-4-1 6:48:35 PM] connecting to: 192.168.1.6
2021.04.01 18:48:35 4: tradfri: [2021-4-1 6:48:35 PM] connecting to: 192.168.1.6
2021.04.01 18:48:35 5: tradfri: read: *** FHEM: connection failed, SyntaxError: Unexpected end of JSON input
2021.04.01 18:48:35 3: tradfri: read: end of file reached while sysread
2021.04.01 18:48:35 3: tradfri: stopped

tradfri-fhem version 0.1.8
Ubuntu 16.04 LTS

Kann jemand helfen?