Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
ich habe schon länger die HS4.12 im Einsatz, früher noch als Beta, zurvor hatte ich die HUE2.0 am laufen gehabt.
Da kann ich leider nichts zu sagen, ob das bei der HS 4.11 auch so ist.
Habt Ihr das Delay alle nur mit der FW 4.12? Hat sich in 4.12 irgendwas an der Python-Version geändert?
Ich hatte vor ewigen Zeiten ein ähnliches Problem mit den damals von Dacom bereitgestellten Logikbausteinen für den Russound CAV/CAM: Bis Firmware 2.3 funktionierten die einwandfrei, nach Upgrade auf 2.4 (mit neuerer Python-Version) bei jedem Schaltvorgang ein Delay von ca. 30 Sek.! Das war nachher sogar Chefsache von Oliver Herrmann bei Dacom, führte aber auch zu keiner Lösung.
Version 3.x des Bausteins hatte ich nie mit 4.11 laufen. Version 2.0 hingegen hatte ich länger mit 4.11 in Betrieb und nun mit 4.12. In beiden Fällen ist bei Version 2.0 kein Delay feststellbar.
Zum Eingangsproblem:
Hier habe ich schon die Vermutung geäußert, dass man bei zu langem Delay eventuell auf die Idee kommen könnte, dass der Eingang (On/Off) nicht funktioniert. Wie beschrieben habe ich ausschließlich diesen verwendet. Vielleicht ist es also zweimal das selbe Problem?
Nun zum Delay:
Fehlt dir etwas in meiner Aufbaubeschreibung (siehe ausführliche Beschreibung)? Wenn ja, kann ich gerne noch nachliefern.
Ablaufbeschreibung: Setzen des E8 (On/Off) auf 1 oder 0 => Lampe schaltet nach einem Delay x an, bzw. aus
Passiert immer
verwendete Versionen: 3.3, 3.4, 3.6, 3.7 und 3.9
bei < 3.3 konnte ich nichts testen, da die Verbindung zur Bridge nicht funktioniert hat
meiner Ansicht nach sind somit alle 3.x Versionen betroffen
Bei der Online-Überwachung des Arbeitsblatts kommt das Signal 1 oder 0 des Schalters am Baustein auf E8 (On/Off) ohne Verzögerungen an. Danach kann es aber verschieden lange dauern bis die Lampe als Resultat schaltet. Gibt es sonst noch einen relevanten Ein- oder Ausgang?
Auf der Debug-Seite unter HSL2.0 stehen für den Hue-Baustein keine zusätzlichen Meldungen, wenn ich im Baustein die Bridge-IP angebe. Lediglich bei den Versionen ohne diese Option sind beim Initialisieren (fast) immer Timeouts zur Bridge (siehe hier).
Sollte ich noch weitere Bereiche auf der Debug-Seite näher betrachten?
[*]Ablaufbeschreibung: Setzen des E8 (On/Off) auf 1 oder 0 => Lampe schaltet nach einem Delay x an, bzw. aus
Passiert immer[*]verwendete Versionen: 3.3, 3.4, 3.6, 3.7 und 3.9
Das Problem ist, dass ich das Problem nicht habe und daher nicht debuggen kann. Um hinter die Ursache zu kommen, müssen wir also tiefer einsteigen.
Was mir aber erst jetzt auffällt: Ich nutze den Get-Status-Eingang nicht. Lasse den mal leer und schaue, was passiert.
Auf der Suche nach dem Delay, schaue dir mal mit Wireshakr o.ä. an, wann der HS eine Nachricht zur Bridge schickt.
Das Problem ist, dass ich das Problem nicht habe und daher nicht debuggen kann. Um hinter die Ursache zu kommen, müssen wir also tiefer einsteigen.
Was mir aber erst jetzt auffällt: Ich nutze den Get-Status-Eingang nicht. Lasse den mal leer und schaue, was passiert.
Auf der Suche nach dem Delay, schaue dir mal mit Wireshakr o.ä. an, wann der HS eine Nachricht zur Bridge schickt.
Das dachte ich mir schon fast, daher bereits die ausführliche erste Beschreibung meines Setups.
1. Den Get-Status-Eingang nicht zu nutzen scheint den Delay bei mir beseitigt zu haben. Die Lampen reagieren sofort 🤩
2. Sowohl mit, als auch ohne Get-Status passieren zwischendurch mal TCP-Fehler, aber das hier passiert nur beim Get-Status und scheint die Bridge zu beschäftigen:
Nachdem 1. funktioniert hat, noch eine "kleine" Frage:
Um mehrere Lichter eines Raumes zu schalten, soll man die Grouped Light ID als itemID nutzen oder? Hierbei werden nämlich mit der 3.9 die Lampen nicht erkannt und die folgenden Logs produziert:
ja wie oben beschrieben. Es reagiert sofort.
In einen der Post wurde in einem Beispiel die Get-Abfrage alle 30s zyklisch abgefragt.
Das hatte ich auch noch drin gehabt.
Jetzt läuft es zeitlich prima.
Ich steuere nur Szenen an, eine AUS-Szene gibt´s ja leider nicht.
Deswegen schalte ich das über den E8 aus.
Dieser klappt jedoch nicht in der 3.9.
Hier ein neuer Versuch zum Testen https://github.com/En3rGy/14100_Hue/releases/tag/v3.10
Eingang 1 sollte nur bei Bedarf oder in sehr großen Intervallen getriggert werde, da hier doch etwas an Netzerklast zusammenkommt.
Vielen Dank für den Baustein auch von mir. Habe ihn erfolgreich in Betrieb setzen können. Als Hinweis für stetige Verbesserungen: Die Hilfeseite geht immer noch von einem Port-Eingang aus, weshalb ab Eingang 3 die Nummerierung nicht mehr stimmt. Aber das hält ja jeden nur dazu an, mitzudenken.😉
Mir ist auch die Farbtemperatur-Ansteuerung einer RGB-Leuchte gelungen, allerdings sehe ich keine Möglichkeit diese bei Tunable White-Leuchten einzustellen bzw. auszulesen (und das sind die meisten ZigBee-Leuchten, die ich habe). Habe ich in den 26 Thread-Seiten etwas überlesen? Mir schien so, als wenn der Ur-Baustein dieses gekonnt hätte.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar