Bug in Edomi HUE-Bridge v1.5 (19000195_lbs.php)

[Tekener]

Hallo zusammen

Dies ist mein erster Post hier, deswegen zuerst ein Hallo an alle Edomi Benutzer und ein Dankeschön an alle Entwickler, Edomi rocked!

Ich habe ein Problem mit der Benutzung der Edomi HUE-Bridge v1.5 (19000195_lbs.php) festgestellt.
An der Bridge waren diverse Hue Motion Sensoren registriert. Nachdem ich einen Motion Sensor via Hue App deaktiviert habe, hat ein anderer kein Motion Signal mehr in Edomi gesendet. (HUE Motion Sensor v0.3 - 19000585_lbs: A2)

Gemäss 19000585 Log hatte das presence Attribut keinen Wert zugewiesen:

1. 2022-09-07 17:36:04 281395 28437 debug EXE19000585 [v0.3]: ================ ARRAY/OBJECT START ================
   2022-09-07 17:36:04 281424 28437 debug EXE19000585 [v0.3]: presence =>
   2022-09-07 17:36:04 281449 28437 debug EXE19000585 [v0.3]: name => EG Esszimmer - Motion Sensor
   2022-09-07 17:36:04 281471 28437 debug EXE19000585 [v0.3]: type => ZLLPresence
   2022-09-07 17:36:04 281495 28437 debug EXE19000585 [v0.3]: modelId => SML003
   2022-09-07 17:36:04 281517 28437 debug EXE19000585 [v0.3]: manufacturer => Signify Netherlands B.V.
   2022-09-07 17:36:04 281546 28437 debug EXE19000585 [v0.3]: swVersion => 2.53.6
   2022-09-07 17:36:04 281567 28437 debug EXE19000585 [v0.3]: uniqueId => XXX
   2022-09-07 17:36:04 281589 28437 debug EXE19000585 [v0.3]: on => 1
   2022-09-07 17:36:04 281611 28437 debug EXE19000585 [v0.3]: alert => none
   2022-09-07 17:36:04 281634 28437 debug EXE19000585 [v0.3]: ledindication =>
   2022-09-07 17:36:04 281655 28437 debug EXE19000585 [v0.3]: usertest =>
   2022-09-07 17:36:04 281677 28437 debug EXE19000585 [v0.3]: reachable => 1
   2022-09-07 17:36:04 281698 28437 debug EXE19000585 [v0.3]: battery => 100
   2022-09-07 17:36:04 281719 28437 debug EXE19000585 [v0.3]: sensitivity => 2
   2022-09-07 17:36:04 281740 28437 debug EXE19000585 [v0.3]: sensitivitymax => 4
   2022-09-07 17:36:04 281764 28437 debug EXE19000585 [v0.3]: sensorId => 90
   2022-09-07 17:36:04 281785 28437 debug EXE19000585 [v0.3]: cmd => statusUpdate
   2022-09-07 17:36:04 281822 28437 debug EXE19000585 [v0.3]: ================ ARRAY/OBJECT END ================

Bei der Analyse des 19000195_lbs.php Source Codes ist mir folgendes aufgefallen:

                case 'ZLLPRESENCE':
                    $presence = $state->presence;
                    if ($sensorFirstRun[$sid] || $presence !== $sensor_old_presence[$sid]) {
                        $sensor_old_presence[$sid] = $presence;
                        if ($config->on && isset($lightlevel))
                            $sensorUpdate[$sid]['presence'] = $presence;
                    }
                    getSensorDefaults($id, $hueSensor, $sensorUpdate, $sensorFirstRun);
                    break; 

if ($config->on && isset($lightlevel))

Es wird eine Prüfung des lightlevels eines Light Sensors vor dem eigentlichen Motion Sensor gemacht. In meinem Fall war dies der augeschaltete Sensor. Der wird vom Hue API trotzdem übermittelt wie folgt:

"85": {
"state": {
"lightlevel": null,
"dark": null,
"daylight": null,
"lastupdated": "none"
},
"swupdate": {
"state": "noupdates",
"lastinstall": "2022-09-06T15:00:29"
},
"config": {
"on": false,
"battery": 100,
"reachable": true,
"alert": "none",
"tholddark": 16000,
"tholdoffset": 7000,
"ledindication": false,
"usertest": false,
"pending": []
},
....
}
},

Ich habe das Problem bei mir zurzeit gelöst, in dem ich die Lightlevel Prüfung auskommentiert habe:
Zeile 795 in 19000195_lbs.php:

if ($config->on) // && isset($lightlevel)) 

Ich kann nicht abschätzen, ob es diese Prüfung grundsätzlich braucht oder nicht. Aber wenn es sie braucht, dann müsste wohl der zum Motion Sensor Device gehörige Lichtsensor verwendet werden... (Scheint via Vergleich der vom Hue API gelieferten uniqueid der Sensoren, könnten die zusammengehörenden Sensoren erkannt werden.)

Viele Grüsse

Philip

[jonofe]

Tekener Danke für deinen Bugreport.

Leider kann ich mich nicht mehr genau erinnern, wofür der lightlevel berücksichtigt wurde, aber für irgendwas was das nötig.
Ohne das jetzt im Detail geprüft zu haben, scheint da aber der lightlevel nicht abhängig der Sensor-ID verwendet zu werden.

Folgende Änderungen in der function updateSensorStatus() sollten eigentlich das Problem lösen (ungetestet):

$lightlevel als Array deklarieren:

static $lightlevel = array(); 

Jedes Vorkommen von

$lightlevel 

ersetzen durch

$lightlevel[$sid] 

Vielleicht kannst du mal testen, ob das so auch funktioniert.

[Tekener]

Danke für die schnelle Antwort!

So wie ich den Code interpretiere, werden die Sensoren in der Reihenfolge wie sie von der Bridge kommen verarbeitet, und dann kommen leider die Lichtsensoren immer nach den zugehörigen Motion Sensoren an. Das heisst, bei der ersten Verarbeitung der Motion Sensoren Daten wäre $lightlevel[$sid] noch nicht gesetzt. Aber das wäre wohl nicht so schlimm...

Habe case 'ZLLPRESENCE wie folgt umgebaut:

 case 'ZLLPRESENCE':
                    $presence = $state->presence;
                    if (isset($lightlevel[$sid+1]) && ($sensorFirstRun[$sid] || $presence !== $sensor_old_presence[$sid])) {
                        $sensor_old_presence[$sid] = $presence;
                        if ($config->on)
                            $sensorUpdate[$sid]['presence'] = $presence;
                    } 

• Die Lightlevel Prüfung wird als erstes gemacht, damit "$presence !== $sensor_old_presence[$sid]" später ein Updaten nicht verhindern würde.
• isset($lightlevel[$sid]) würde nie true sein, weil die sid des Motion und des Lichtsensors sind ja nicht identisch.

Scheint soweit zu funktionieren, ich teste das hier mal ein wenig...

[Tekener]

Habe die Lösung noch verbessert. Wollte mich nicht darauf verlassen, dass die Lichtsensor Id eins höher wie die Motion Sensor Id ist:

                case 'ZLLPRESENCE':
                    $mac = strtok($hueSensor->getUniqueid(), '-');  
                    $presence = $state->presence;                
                    if (isset($lightlevel[$mac]) && (!array_key_exists($sid, $sensor_old_presence)|| $presence !== $sensor_old_presence[$sid])) {
                        $sensor_old_presence[$sid] = $presence;
                        if ($config->on)
                            $sensorUpdate[$sid]['presence'] = $presence;
                    }
                    getSensorDefaults($id, $hueSensor, $sensorUpdate, $sensorFirstRun);
                    break;
                case 'ZLLLIGHTLEVEL':
                    $mac = strtok($hueSensor->getUniqueid(), '-');
                    $lightlevel[$mac] = $state->lightlevel;
                    if ($sensorFirstRun[$sid] || $lightlevel[$mac] != $sensor_old_lightlevel[$sid]) {
                        $sensor_old_lightlevel[$sid] = $lightlevel[$mac];
                        if ($config->on)
                            $sensorUpdate[$sid]['lightlevel'] = $lightlevel[$mac];
                    }
                    getSensorDefaults($id, $hueSensor, $sensorUpdate, $sensorFirstRun);
                    break; 

Gemäss Hue API Dokumentation, sollte im uniqueid Feld immer die Mac Addresse stehen.

[Tekener]

Hallo jonofe

Die angepasste Version des 19000195_lbs.php ist bei mir seit September ohne Probleme im Einsatz.

Im Baustein 19000585_lbs_mod.php habe ich auch noch ein Problem gefixed:

case 'on':
      setLogicLinkAusgang($id, $outputOffset + 1, empty($value) ? 0 : $value);[/INDENT][INDENT]break;[/INDENT]
case 'reachable':
      setLogicLinkAusgang($id, $outputOffset + 2, empty($value) ? 0 : $value);[/INDENT][INDENT]break;[/INDENT]

und

 case 'ledindication':
      setLogicLinkAusgang($id, $outputOffset + 11, empty($value) ? 0 : $value);
      break;
case 'usertest':
     if (intval($value)==1) $timeOffset = 5; else $timeOffset=10;
     setLogicLinkAusgang($id, $outputOffset + 12, empty($value) ? 0 : $value);
     break;​

Wenn LBS 19000195 via msg queue 'false' dem LBS 19000585 übergeben hat, wurde '' empfangen. Ich weiss nicht warum, aber mit dem "empty($value)" check habe ich es gefixed, dass korrekt '0' im LBS Ausgang steht.

Durch Admin/Mod entfernt.

Grüsse
Philip

[vento66]

Die Zeile mit dem Copyright in den LBS sind nur zum Code auffüllen?

[starwarsfan]

Hallo miteinander

Durch Admin/Mod entfernt.

Die Zeile mit dem Copyright in den LBS sind nur zum Code auffüllen?

Das muss man jetzt nicht wirklich verstehen oder? Sind wir jetzt schon so weit, dass man nichtmal mehr Fehler korrigieren darf? Da findet sich jemand, der nicht nur Probleme sondern auch Lösungen hat, spricht den Autor des Bausteins an und stellt die Korrektur zur möglichst einfachen Übernahme zur Verfügung und dann sowas? Na super...

[vento66]

starwarsfan Ich wars nicht ...... Wie die Mods/Admins mit solchen Sachen umgehen, liegt nicht bei mir! Ausserdem gibt es bestimmt andere Möglichkeiten, ausser den ganzen veränderten LBS hier öffentlich zum DL zu stellen!

[Tekener]

Hallo jonofe

Am einfachsten wäre es wohl, wenn ich dir die modizierten Versionen der PHP Bausteine zukommen lassen könnte. Scheint dieses Forum ist dafür aber der falsche Ort.

----

Etwas anderes was mir noch mit dem Baustein 19000585_lbs_mod.php aufgefallen ist:

Wenn "E24 - Off timer" aktiviert ist, und "Motion Dark A5" mit 1 getriggered wird, wenn danach die Helligkeit unter dem mit "E19 lux dark" definierten Schwellenwert fällt, wird der Ablauf des Off Timers für "Motion Dark A5" ignoriert.

Ich benutze deswegen A5 nur für Motion On events, und A2 für Motion Off events. Ist das absichtlich so implementiert?

Viele Grüsse

Philip

[jonofe]

Wenn "E24 - Off timer" aktiviert ist, und "Motion Dark A5" mit 1 getriggered wird, wenn danach die Helligkeit unter dem mit "E19 lux dark" definierten Schwellenwert fällt, wird der Ablauf des Off Timers für "Motion Dark A5" ignoriert.

Das hab ich nicht verstanden. Wenn A5 eine 1 ausgibt, dann ist die Helligkeit doch schon unter dem E19 Werte, denn dieser ist doch gerade die Grenze dafür, dass DARK getriggert wird, oder? Kannst du das nochmal genauer erklären?
Nach meiner Erinnerung und kurzem Blick auf den Code sollte es so sein, dass der Ausgang der die Bewegung triggert nach der Nachlaufzeit (E24) auf 0 gesetzt werden sollte.

P.S.: Die Updates der LBSe HUE Bridge (v1.6) und HUE Motion Sensor (v0.4) sind jetzt im DL Portal verfügbar.

[Tekener]

Die Updates der LBSe HUE Bridge (v1.6) und HUE Motion Sensor (v0.4) sind jetzt im DL Portal verfügbar.

Cool!

Nach meiner Erinnerung und kurzem Blick auf den Code sollte es so sein, dass der Ausgang der die Bewegung triggert nach der Nachlaufzeit (E24) auf 0 gesetzt werden sollte.

Das ist immer so bei A2, bei A5 ist es nur dann so, wenn zum Zeitpunkt wo die Nachlaufzeit abgelaufen ist, die Helligkeit immer noch unter dem Schwellenwert ist.

[jonofe]

Das ist immer so bei A2, bei A5 ist es nur dann so, wenn zum Zeitpunkt wo die Nachlaufzeit abgelaufen ist, die Helligkeit immer noch unter dem Schwellenwert ist.

Okay. Wenn ich nochmal drüber nachdenke, macht alles andere ja auch keinen Sinn, d.h. Helligkeitsschwellen machen ja nur Sinn fürs Einschalten und da ja dann i.d.R. ohnehin die Helligkeit hochgeht (es wird ja eine Lampe angeschaltet), weiss man ja nie an welchem Ausgang das AUS-Signal kommt. Oder in kurz: Nachlaufzeit und Ausschalten haben bei einem BWM nichts mit der Helligkeit zu tun. Daher auch nur das AUS Signal an A2.

Oder siehst du da einen anderen Usecase?

[Tekener]

Ne, ich sehe das genau so.

Zurzeit ist es aber so, dass das Aus Signal auch an A5 kommt, wenn die Helligkeit zu dem Zeitpunkt unter dem Schwellenwert ist. Der Schwellenwert sollte aber nur für das Ein Signal von belang sein.

Wenn das Aus Signal an A5 immer kommen würde, nachdem unter Berücktigung der Helligkeit das Ein Signal an A5 übermittelt worden ist, kann unter Umständen das Handling mit dem LBS vereinfacht werden, weil dann nur A5 berücksichtigt werden muss. Das A5 Verhalten wäre dann ähnlich wie beim LBS "Sperre mit Halten".

[jonofe]

Wenn das Aus Signal an A5 immer kommen würde, nachdem unter Berücktigung der Helligkeit das Ein Signal an A5 übermittelt worden ist, kann unter Umständen das Handling mit dem LBS vereinfacht werden, weil dann nur A5 berücksichtigt werden muss. Das A5 Verhalten wäre dann ähnlich wie beim LBS "Sperre mit Halten".

Ich vermute das Problem ist, dass während der Nachlaufzeit ein weiterer Motiontrigger erfolgt ist und dadurch der gesicherte Output auf dem das AUS Signal gesendet werden soll, überschrieben wurde. Kann es sein, dass das AUS Signal also nicht ignoriert sondern an einem anderen Ausgang (A3/A4) erscheint?
Ich tendiere eher dazu an A3-A5 gar keine Null mehr zu senden.
Der einzige Usecase für AUS Signale an A3-A5 wäre aus meiner Sicht, wenn man bei unterschiedlichen Helligkeitsstufen unterschiedliche Leuchten schalten will. Ehrlich gesagt, hab ich für eine solche Anpassung im Moment zu wenig Zeit. Falls du das anpassen willst kann ich das gerne in den LBS übernehmen.

[Tekener]

Hmm, es wäre wohl am einfachsten keine Aus Events mehr auf A3 bis A5 zu senden. Und wohl auch Okey für die gebräuchlichen UseCases. Es wäre allerdings ein breaking Change und könnte sein das ein LBS Nutzer seine Logik umstellen müsste.