HUE Dimmer Switch schaltet/wiederholt manchmal letzten Befehl

[justme1968]

welche NR steht beim device in den internals ?

[popy]

welche NR steht beim device in den internals ?

Die NR ist 265, hier das ganze Listing:

Code Auswählen Erweitern




Internals:
   DEF        sensor 22 1 IODev=hueBridge1
   ID         S22
   INTERVAL   1
   IODev      hueBridge1
   NAME       DIM_VR_Master_Dimmer
   NR         265
   STATE      4002
   TYPE       HUEDevice
   lastupdated 2019-01-07 21:09:46
   manufacturername Philips
   modelid    RWL021
   name       Schalter Eingang
   on         1
   reachable  1
   swversion  5.45.1.17846
   type       ZLLSwitch
   uniqueid   00:17:88:01:04:ef:29:44-02-fc00
   READINGS:
     2019-01-07 21:09:46   battery         100
     2019-01-10 11:48:49   batterystate    high
     2019-01-07 21:09:46   reachable       1
     2019-01-07 21:09:46   state           4002
   helper:
     devtype    S
     reachable  0
     update_timeout 1
     setList:
Attributes:
   IODev      hueBridge1
   alias      Master Aus Schalter
   group      Vorraum
   icon       taster_ch
   initialized 1
   room       System
   userattr   initialized


unsigned char Überlauf im Module?

[justme1968]

nein. ich hatte gehofft es liegt an einer falschen reihenfolge

eine ideen zum testen:

in 31_HUEDevice.pm in zeile 375 das +10 mal deutlich erhöhen. damit wird die erst abfrage erst mal verzögert. geht es dann mit dem start?

[popy]

nein. ich hatte gehofft es liegt an einer falschen reihenfolge

eine ideen zum testen:

in 31_HUEDevice.pm in zeile 375 das +10 mal deutlich erhöhen. damit wird die erst abfrage erst mal verzögert. geht es dann mit dem start?

Habs mal auf +80 gestellt da bei mir das offsetUTC meistens 53 Sekunden dauerte bis der Helper vom bridge IODEV den Wert hatte.
Mit +80 3x neu gestartet und das Problem beim starten ist weg.

Das Problem während Betrieb kann ich noch nicht sagen ob es weg ist. Das dauert immer länger.
Vermutlich aber nicht.

Hätte eine Idee und Frage.
Die Frage zuerst: Ist die einzige Stelle wo das notify/event ausgelöst wird im "my lastupdated" in der 31_HUEDevice.pl?
Nun die Idee: Falls ja, mann könnte doch einbauen dass wenn kein offsetUTC vorhanden (Fehlerfall bei mir beim starten und vll. auch während Betrieb) dass er den offset vom system nimmt.
Ich vermute dass zu 99% auf der Bridge und am fhem die gleiche Zeitzone sind.

So währen vll. beide Fälle erschlagen 
Was sagst du dazu?

Danke
pOpY

[justme1968]

ich muss mal überlegen wir man den start synchronisieren kann. so lange zu warten gefällt mir nicht.

das sollte die einzige stelle sein.
damit wäre nicht abgefangen wenn auf der bridge etwas falsches oder gar nichts gesetzt ist.

hast du eigentlich pollDevices gesetzt ?

das ganze kann auch nichts mit dem problem beim betrieb zu tun haben.

[popy]

ich muss mal überlegen wir man den start synchronisieren kann. so lange zu warten gefällt mir nicht.

das sollte die einzige stelle sein.
damit wäre nicht abgefangen wenn auf der bridge etwas falsches oder gar nichts gesetzt ist.

hast du eigentlich pollDevices gesetzt ?

das ganze kann auch nichts mit dem problem beim betrieb zu tun haben.

ok, ich vermute dass das problem während dem Betrieb das gleiche ist.
Was ist z.B.': wenn die bridge neu startet, braucht dann das offsetUTC auch wieder eine Zeit bis es gesetzt wird?

Ja, pollDevices ist auf 2. Wollte die bridge damit entlasten und lt. div, Threads & Wiki soll es dann ja auch so sein, oder?

[justme1968]

nein. die internen werte im modul gehen nicht verloren so lange fhem nicht neu gestartet wird.

ja. pollDevices ist gut.

[popy]

nein. die internen werte im modul gehen nicht verloren so lange fhem nicht neu gestartet wird.

ok, dann is gut 

ja. pollDevices ist gut.

ok, danke für die Bestätigung.



Ist, ja echt komisch dass fhem bzw. meine bridge so lange benötigt bis die Daten da sind.
Habe auch httpUtils auf 1, da ich ansonsten FHEMWEB extrem langsam wurde (blockierte).
(muss dazu sagen dass ich aber sehr zu viele Geräte mit Intervall 1 hatte, die ich jetzt reduziert habe. Habs dann nicht mehr umgstellt von httputils 1).
Passt das auch ?

[popy]

ich muss mal überlegen wir man den start synchronisieren kann. so lange zu warten gefällt mir nicht.

Kann ich dich mit Tests da irgendwie Unterstützen?

[justme1968]

sobald mir etwas einfällt

[popy]

sobald mir etwas einfällt

Ok

Gesendet von meinem ONEPLUS A6013 mit Tapatalk

[popy]

@justme1968:
Ich habe eine Idee 
Einen neuen internal namens lastupdated_UTC machen.
In diesem wird immer der von der bridge gesendete UTC timestamp geschrieben und gegen den gespeicherten state/hash verglichen.
Ist er anders wird erst die Zeitumrechnung gemacht und der lastupdated aktualisiert (welcher dann in localzeit ist).
So würde es egal sein wann offsetUTC daherkommt, es würde lediglich lastupdated nach einem boot nicht passen.

Was hältst du davon?

pOpY

[popy]

sobald mir etwas einfällt

Was sagst du zu meiner Idee für das startup Problem?

Hatte wieder das Problem dass einfach so das letzte Event ausgelöst wird (nach ~1 Tag Laufzeit).
Um die rpi sdcard zu schonen habe ich nun das Log auf einen Samba Share auf meinen Windows Server mit HDD umgestellt.
Bei dem DEV & der Bridge ist verbose 5 gesetzt.
So sehen wir hoffentlich von was das Problem ausgelöst wird.

Heute wie das Problem aufgetreten ist, ist mir folgendes Aufgefallen:
Ich habe ein notify welches einen "batterystate" als reading beim Gerät setzt:

Code Auswählen Erweitern


(BM_.*|DIM_.*):battery.* {
#Device have low battery?
    if (ReadingsNum($NAME, "battery", 0) < 10) {
#device has low battery
if (ReadingsVal($NAME, "batterystate", "high") eq "high") {
#speak alexa and log entry
fhem("set pushmsg_all message Batterie im Gerät ".$NAME." fast leer, bitte tauschen! ".FmtTime(time()));
Log 1, "act_BM_Battery: Batterie im Gerät ".$NAME." fast leer, bitte tauschen! ";
}

#set low battery state
        fhem("setreading ".$NAME." batterystate low");
    }

#battery high again
    #if (ReadingsNum($NAME, "battery", 0) >= 100 && (ReadingsVal($NAME, "batterystate", "low") eq "low") ) {
    if (ReadingsNum($NAME, "battery", 0) >= 80) {
#battery is high again
fhem("setreading ".$NAME." batterystate high");
    }
}


Da setzte ich mit setreading "high" oder "low" je nach battery Wert, aber verhindere somit mehrfache ausgaben auf Alexa bzw. ans Handy.
Im Log wurde 2x state vom DImmer geändert, das schreibe ich ins log:

Code Auswählen Erweitern


Log:
2019.01.11 15:04:53 1: act_on_Master: EVENT TO DEBUG: 4002 !!!!!!!!!!!!!!!!!!!!! HIER SCHAUEN!!!!!!!!
2019.01.11 15:05:53 1: act_on_Master: EVENT TO DEBUG: 4002 !!!!!!!!!!!!!!!!!!!!! HIER SCHAUEN!!!!!!!!


Habe dann 2h später wie ich Zeit hatte ein list vom DImmer gemacht:

Code Auswählen Erweitern


Internals:
   DEF        sensor 22 1 IODev=hueBridge1
   ID         S22
   INTERVAL   1
   IODev      hueBridge1
   NAME       DIM_VR_Master_Dimmer
   NR         265
   STATE      4002
   TYPE       HUEDevice
   lastupdated 2019-01-07 21:09:46
   manufacturername Philips
   modelid    RWL021
   name       Schalter Eingang
   on         1
   reachable  1
   swversion  5.45.1.17846
   type       ZLLSwitch
   uniqueid   00:17:88:01:04:ef:29:44-02-fc00
   READINGS:
     2019-01-07 21:09:46   battery         100
     2019-01-11 15:05:53   batterystate    high
     2019-01-07 21:09:46   reachable       1
     2019-01-07 21:09:46   state           4002
   helper:
     devtype    S
     reachable  0
     update_timeout 1
     setList:
Attributes:
   IODev      hueBridge1
   alias      Master Aus Schalter
   group      Vorraum
   icon       taster_ch
   initialized 1
   room       System
   userattr   initialized


Interessant ist die Zeit vom batterystate reading, diese wurde aktualisiert und deckt sich mit dem wo das notify ausgelöst wurde

Code Auswählen Erweitern


List: 2019-01-11 15:05:53   batterystate    high
Log: 2019.01.11 15:05:53 1: act_on_Master: EVENT TO DEBUG: 4002 !!!!!!!!!!!!!!!!!!!!! HIER SCHAUEN!!!!!!!!


Habe dann versucht mittels:

Code Auswählen Erweitern


setreading DIM_VR_Master_Dimmer batterystate high
setreading DIM_VR_Master_Dimmer batterystate low
setreading DIM_VR_Master_Dimmer battery 99
setreading DIM_VR_Master_Dimmer battery 100


Das Problem ev. nachzustellen aber ohne Erfolg, das Notify wird nicht ausgelöst.

Was sagst du dazu? Mache ich da was falsch?

Jetzt läuft mal das Log und dann sehen wir weiter.

Danke
pOpY

[Jamo]

Ich habe das gleich bei mir auch beobachtet, nach dem neustart von FHEM wird immer zumindest bei einem Hue Dimmer einmal ein Event ausgelöst. Nachdem ich den Thread gelesen habe, ist die Ursache anscheinend gefunden. Also popy ist nicht der Einzige wo das auftritt. Beste Grüsse und schönes Wochenende!

[popy]

Ich habe das gleich bei mir auch beobachtet, nach dem neustart von FHEM wird immer zumindest bei einem Hue Dimmer einmal ein Event ausgelöst. Nachdem ich den Thread gelesen habe, ist die Ursache anscheinend gefunden. Also popy ist nicht der Einzige wo das auftritt. Beste Grüsse und schönes Wochenende!

Yeah, ich bin nicht alleine 
Probier mal als workaround:

in 31_HUEDevice.pm in zeile 375 das +10 auf +80 ändern

Dann "shutdown restart" bei mir ist das Problem weg.
Ist aber nur ein Workaround, sprich das erste Update wird er nach 80 Sekunden gemacht.

Mal schauen was @justme1968 für Ideen hat um es schöner zu lösen 

Eine Frage Interessiert mich brennend, hast auch du nach ~1-2 Tage auf einmal ein Notify was auslöst weil ein Schalter den gleichen state wiederholt?
Also das einfach Schaltbefehle ausgeführt werden, obwohl keiner gedrückt hat.

pOpY