Hallo,
bei mir gab's eine Umstellung von der HUE Bridge 2 auf Conbee, dann wieder zurück auf die HUE Bridge. Jeweils mit Lampen/Dimmer komplett zurücksetzten und neu in FHEM einlernen.
Jetzt hab ich seit dem Rückstieg auf die HUE Bridge das Problem, dass hin und wieder eines meiner Lichter sporadisch angeht, ohne, dass ich etwas tun würde. Bevorzugt in der Nacht, was besonders unangenehm ist. Ich hatte zuerst eine HUE Birne im Verdacht und die ausgewechselt. Das war's aber nicht. Auch die neue zeigt das Verhalten. Und ein Gledopto RGBWW Dimmer auch.
Es gibt in meiner Automation keinen Grund, warum nur eine Lampe eingehen sollte. Die werden alle nur über Szenen gesteuert und da sind es dann immer mehrere, die gleichzeitig geschalten werden.
Habt ihr eine Idee, an was das liegen könnte? Und v.a., wie ich das debuggen kann?
Danke!
Stefan
Direkte Idee keine aber evtl. Hilfe bei der Fehlersuche.
Durch mein Problem hier (edit: Link repariert, danke Beta-User):
https://forum.fhem.de/index.php/topic,122075.msg1206701.html#msg1206701
Hab ich besser verstanden wie FHEM und HUE / Conbee kommunizieren.
Es gibt sowohl Push von neuen Events, aber auch Pollen.
Zumindest bei Letzterem kommen nun Daten in FHEM rein, bei denen FHEM entscheiden muss ob es schon Events dafür gefeuert hat oder nicht.
Conbee / HUE liefert hier mit dem aktuellen Wert auch den Timestamp mit.
Das FHEM Modul speichert sich nun auch den letzten Timestamp für eine Werteaktualisierung.
Ist der Wert neuer wird er übernommen und es gibt ein Event.
Ist der Wert nicht neuer, wird das Ganze ignoriert (da schon als bekannt erachtet) und auch kein Event gefeuert.
Bei meinem Problem war die Ursache für "Geisterevents" ein Absturz / Restart von FHEM.
Dadurch wurde das State-File nicht beim Beenden geschrieben und das HUE Modul hat "vergessen" dass es die Zustände der Bridge schon kannte (also der letzte FHEM bekannte Timestamp war plötzlich viel älter und der aktuelle Wert wurde fälschlicherweise als neu interpretiert).
Das Problem ist hier eben, dass Sensoren verschiedenster Art sein können.
Bei einem Temperatursensor macht es Sinn auch ältere noch aktuelle Werte noch zu übernehmen falls Fhem z.B. eine Zeit keine Verbindung zur HUEBridge hatte
Ein alter Tastendruck bei einem Wandtaster der plötzlich Stunden später eine Aktion auslöst führt hingegen zu einem mitunter etwas gruselig anmutenden Eigenleben. ;)
Dazu reichen allerdings keine Lampen alleine.
Bei mir waren es Zigbee Wandtaster, deren alter "Pressed"-State (1002 oder was auch immer das Reading dann hatte) als neu erachtet wurde, obwohl schon Stunden alt.
Dadurch lösten meine Notifies aus, welche dann eben z.B. Lampen einschalteten.
Denke es ist eher unwahrscheinlich, dass es bei dir das selbe Problem ist, aber
a) Kannst du ja mal schauen ob du da zufällig Fhem Restarts aus irgendeinem Grund hattest
b) Würde ich mal versuchen rauszufinden worüber die Lampe eingeschaltet wurde und ob das Problem gar nicht die Lampe selbst ist, sondern z.B. ein Taster + Notify (bei den Verdächtigen Defines evtl. mal ein Log einbauen)
c) Hilft ein wenig Einblick in die Art der Kommunikation & Auswertung ja auf andere Art und Weise deinem Problem auf die Spur zu kommen.
Weitere vage Ansätze:
- Stromausfall? (dann müßten aber mehrere Leuchten betroffen sein)
- "Geister-Bindings" bzw. "Geister-Gruppen"?
Es gibt ja auch bei ZigBee (je nach Taster usw.) die Möglichkeit, Verbindungen direkt in der Hardware herzustellen. Eigentlich sollte sowas nach einem Reset weg sein, aber ggf. "repariert" sich sowas automatisch, wenn man es nicht in allen betroffenen Geräten mehr oder weniger gleichzeitig entfernt?
Bei deconz hatte ich auch neulich den etwas sonderbaren Effekt, dass Devices wieder in Gruppen aufgetaucht sind, von denen ich angenommen hatte, ich hätte die da rausgelöscht und das ganze auch via phoscon gespeichert (allerdings ebenfalls ohne reset dazwischen). Dann schaltet schon mal ein Bewegungsmelder was im Schlafzimmer, das eigentlich längst vom Flur dahin umgezogen war...
PS: der link aus dem Vorpost funktioniert für andere nicht, hier der allgemeine: https://forum.fhem.de/index.php/topic,122075.msg1206701.html#msg1206701
Danke Euch!
Ich hab keine Notifys/DoIfs/etc., die die Lampen einzeln schalten. Und auch keine Schalter, die Lampen einzeln schalten. Auch keine FHEM Restarts.
Stromausfall war auch keiner, das würde ich an dem uralten Radiowecker im Wohnzimmer merken.
"Geister-Bindings/Gruppen"?
Das wäre das Licht, welches heute Nacht einging (inkl. probably associated). Hab ich dann wohl um 03:16 via LightScene ausgeschaltet. Wann sie einging, weiß ich nicht. 02:19 liegt aber nahe.
defmod HUEBridge_HUEDevice4 HUEDevice 4 IODev=HUEBridge
attr HUEBridge_HUEDevice4 userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr HUEBridge_HUEDevice4 IODev HUEBridge
attr HUEBridge_HUEDevice4 alias hueStripWzKasten01
attr HUEBridge_HUEDevice4 color-icons 2
attr HUEBridge_HUEDevice4 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr HUEBridge_HUEDevice4 group Wohnzimmer
attr HUEBridge_HUEDevice4 icon hue_filled_lightstrip
attr HUEBridge_HUEDevice4 model GL-C-008
attr HUEBridge_HUEDevice4 room Beleuchtung,HUEDevice,Wohnzimmer->Licht
attr HUEBridge_HUEDevice4 subType extcolordimmer
attr HUEBridge_HUEDevice4 webCmd rgb:rgb ff0000:rgb DEFF26:rgb 0000ff:ct 490:ct 380:ct 270:ct 160:toggle:on:off
defmod HUEBridge HUEBridge 10.168.1.69
attr HUEBridge devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr HUEBridge group HUEBridge
attr HUEBridge icon hue_filled_bridge_v2
attr HUEBridge key jHtL7jbCQUNUdghlLXR3-Iwik-BT38t6EUifZeJs
attr HUEBridge room HUEDevice
defmod HUEBridge_HUEGroup1 HUEDevice group 1 IODev=HUEBridge
attr HUEBridge_HUEGroup1 userattr createActionReadings:1,0 createGroupReadings:1,0
attr HUEBridge_HUEGroup1 IODev HUEBridge
attr HUEBridge_HUEGroup1 alias Wohnzimmer
attr HUEBridge_HUEGroup1 color-icons 2
attr HUEBridge_HUEGroup1 delayedUpdate 1
attr HUEBridge_HUEGroup1 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr HUEBridge_HUEGroup1 group HUEGroup
attr HUEBridge_HUEGroup1 icon hue_room_living
attr HUEBridge_HUEGroup1 room HUEDevice
setstate HUEBridge update done
setstate HUEBridge 2022-01-25 13:38:18 alert select
setstate HUEBridge 2022-01-25 13:38:18 bri 254
setstate HUEBridge 2022-01-31 16:47:36 groups 3
setstate HUEBridge 2022-01-30 00:08:14 lastError parameter, bri, is not modifiable. Device is set to off.
setstate HUEBridge 2022-02-10 15:02:41 lights 12
setstate HUEBridge 2022-01-25 13:38:18 onoff 1
setstate HUEBridge 2022-01-25 13:38:18 pct 100
setstate HUEBridge 2022-01-25 13:38:18 reachable 1
setstate HUEBridge 2022-01-31 16:47:36 rules 0
setstate HUEBridge 2022-01-31 16:47:36 scenes 0
setstate HUEBridge 2022-01-31 16:47:36 schedules 0
setstate HUEBridge 2022-01-31 16:47:36 sensors 2
setstate HUEBridge 2022-02-17 10:16:40 state update done
setstate HUEBridge 2022-02-01 03:14:39 swupdate BSB002 - 1.49SR4.1
setstate HUEBridge_HUEDevice4 off
setstate HUEBridge_HUEDevice4 2022-02-01 09:17:56 IODev HUEBridge
setstate HUEBridge_HUEDevice4 2022-02-01 09:17:57 alert select
setstate HUEBridge_HUEDevice4 2022-02-10 15:17:43 bri 254
setstate HUEBridge_HUEDevice4 2022-02-01 09:17:57 colormode xy
setstate HUEBridge_HUEDevice4 2022-02-01 09:17:57 ct 156 (6410K)
setstate HUEBridge_HUEDevice4 2022-02-01 08:56:39 dynamics_status none
setstate HUEBridge_HUEDevice4 2022-02-01 09:17:57 effect none
setstate HUEBridge_HUEDevice4 2022-02-17 02:19:37 hue 0
setstate HUEBridge_HUEDevice4 2022-02-17 03:16:59 onoff 0
setstate HUEBridge_HUEDevice4 2022-02-17 03:16:59 pct 0
setstate HUEBridge_HUEDevice4 2022-02-01 09:17:57 reachable 1
setstate HUEBridge_HUEDevice4 2022-02-10 15:26:02 rgb ffdc52
setstate HUEBridge_HUEDevice4 2022-02-10 15:26:41 sat 179
setstate HUEBridge_HUEDevice4 2022-02-17 03:16:59 state off
setstate HUEBridge_HUEDevice4 2022-02-01 08:56:39 v2effect no_effect
setstate HUEBridge_HUEDevice4 2022-02-10 15:26:02 xy 0.4333,0.4226
setstate HUEBridge_HUEGroup1 2022-02-10 15:02:41 .associatedWith HUEBridge_HUEDevice5 HUEBridge_HUEDevice1 HUEBridge_HUEDevice4 HUEBridge_HUEDevice11 HUEDevice12 HUEBridge_HUEDevice2
setstate HUEBridge_HUEGroup1 2022-02-01 09:17:56 IODev HUEBridge
setstate HUEBridge_HUEGroup1 2022-02-01 09:17:57 all_on 0
setstate HUEBridge_HUEGroup1 2022-02-17 08:50:39 any_on 0
Bringt das was, wenn ich Verbose bei Lampe und Bridge auf 5 stelle? Ich mein, sehe ich dann, wer das verursacht haben könnte?
Wenn du sehr sicher bist, dass es nicht was aktives in FHEM ist, würde ich eher mal versuchen, mehr über die "Internals" direkt auf der HUE-Bridge rauszufinden. Habe aber keine Ahnung, wie das geht (evtl. mit der HUE-Essentials-App?)...
Am IO zu loggen würde ggf. helfen um zu sehen, ob es "nur" eingehende Infos gibt oder auch was, was rausgeht. Von daher: loggen schadet vermutlich auch nicht, ist aber halt mühevoll in der Auswertung.
Also, verbose 5 bringt gar nichts leider.
Hab mir jetzt ein DOIF geschrieben, dass die Lampen automatisch wieder ausschaltet. Aber gute Lösung ist das nicht. Bin daher für weitere Vorschläge offen ;)
am desired internal solltest du erkennen können ob eine lampe aus fhem heraus eingeschaltet wurde.
um sicher zu sein das nicht kurze stromausfälle das problem verursachen schau noch mal nach ob er startup mode für alle lampen so eingestellt ist wie du es erwartest.
Ahhh, "desired" ist mir noch gar nicht aufgefallen. Nett!
Mit dem Startup Mode hab ich lange herum gespielt. Der ist so, wie er sein soll (ein/aus). Geht aber halt nur bei den HUE Birnen.
Zitat von: justme1968 am 18 Februar 2022, 09:13:53
am desired internal solltest du erkennen können ob eine lampe aus fhem heraus eingeschaltet wurde.
Hab mir mal zum Testen ein at angelegt:
defmod check at +*00:00:10 IF ([HUEBridge_HUEDevice2:&desired] == 0) (set HUEBridge_HUEDevice2 off)Ergibt:
check: IF: unknown internal: HUEBridge_HUEDevice2:desiredWas hab ich da falsch gemacht?
du musst mindestens ein mal aus fhem heraus geschaltet haben damit das internal da ist. ansonsten kann ich dir zu doif nichts sagen. das verwende ich nicht.
aber unabhängig davon: es ist besser desired mit onoff zu vergleichen und bei ungleich schalten. sonst schaltest du sehr oft unnötig.
und was ich vergessen habe: der weg über desired geht natürlich nur wenn du nur innerhalb von fhem schaltest und nie durch etwas anderes wie schalter, bewegungsmelder oder app.
Zitat von: justme1968 am 18 Februar 2022, 13:28:21
du musst mindestens ein mal aus fhem heraus geschaltet haben damit das internal da ist.
Das wäre eh da:
Internals:
DEF 2 IODev=HUEBridge
FUUID 61efef3b-f33f-dc90-a783-3b4733e3f4cb6845
FVERSION 31_HUEDevice.pm:0.256000/2022-01-31
ID 2
INTERVAL
IODev HUEBridge
NAME HUEBridge_HUEDevice2
NR 333
STATE on
TYPE HUEDevice
desired 1
has_events 1
Zitatansonsten kann ich dir zu doif nichts sagen. das verwende ich nicht.
Ooooch, jetzt hab ich extra at + if genommen statt einem doif ;)
Zitataber unabhängig davon: es ist besser desired mit onoff zu vergleichen und bei ungleich schalten
Super Tipp, danke!
Zitatund was ich vergessen habe: der weg über desired geht natürlich nur wenn du nur innerhalb von fhem schaltest und nie durch etwas anderes wie schalter, bewegungsmelder oder app.
Ja. Das passt so. Wird nur über FHEM geschalten.
So scheint das zu funktionieren:
defmod diEinzelLichtAus DOIF ((["HUEDevice:on"] and [$DEVICE:&desired] != [$DEVICE:onoff]) and (([?lightSceneWz] eq "AllesAus" or [?lightSceneWz] eq "Initialized")))(\
set $DEVICE off,\
{Log 3, "$DEVICE unerwartet ein;; Desired: [$DEVICE:&desired]"}\
)
attr diEinzelLichtAus do always
Aber falls noch jemand eine Idee haben könnte, was der Grund dafür ist, dass sich Lampen einfach so einschalten: Das wäre eigentlich interessanter ;)