Test Adapter hue v2.2.x
-
@Stefan-Hanke ja klar, nur zur Info. Für die Heizungssteuerung habe ich eine sehr gut funktionierende Homematic IP Umgebung. Aber als ioBroker Nutzer will man aus jedem Teil auch alles herauskitzeln, oder?
-
@SmartHomie said in Test Adapter hue v2.2.x:
Für die Heizungssteuerung habe ich eine sehr gut funktionierende Homematic IP Umgebung.
Kunststück
Die Teile kommunizieren untereinander, da brauchste noch nicht mal was zu scripten.
Gesteuert ( Wandthermostat, Tür/Fensterkontakte ) wird bei mir auch über HMIP, die Heizkörper Thermostate sind jedoch Comet DECT.Aber Blockly machts möglich
-
@SmartHomie
Hi,ich hatte schon einige Zeit die Temperatur über Node Red abgefragt und bin jetzt auf das Objekt im Hue Adapter gegangen. Der Werte sind alle stimmen überein und scheinen sinnvoll zu sein.
Gruß Philippe
-
@SmartHomie sagte in Test Adapter hue v2.2.x:
@Stefan-Hanke ...Aber als ioBroker Nutzer will man aus jedem Teil auch alles herauskitzeln, oder?
Absolut korrekt, genau so ist es...
-
@sabphil22 Ja, seit einem Löschen und Neuimport des Sensors liefert er über den Hue Adapter auch neuerdings plausible Temperaturwerte. Zuviel Genauigkeit darf man da sicher nicht erwarten, aber als Zirkawert reicht mir der Hue Sensor aus.
-
Ich habe immer wieder mal ähnliche Fehler im Log:
2019-11-06 09:58:34.818 - warn: hue.0 (20206) groupQueue: job groups.get:0:945b5b55e61738ee1c25ff4cd9aecf09 failed: Error 2019-11-06 09:58:34.818 - warn: hue.0 (20206) groupQueue: retry [1/10] job groups.get:0:945b5b55e61738ee1c25ff4cd9aecf09Und das zu einer Zeit wo nichts geschaltet oder geregelt wird. Mit dem Hue-extended Adapter habe ich nichts dergleichen. Woran liegt das?
Edit: Mir ist eingefallen, dass ich das gleiche Problem schon mal hatte (https://forum.iobroker.net/topic/23933/hue-adapter-0-6-9-liefert-warnungen). Ist das immer noch nicht behoben?
Mich irritiert vor allem, dass diese Fehler auch kommen wenn nichts gesteuert wird (keiner zuhause / kein Skript aktiv).
-
Ich habe seit längerem nal wiedere ein update gemacht und folgenden neue Einstellung gesucht:
- ListenpunktMöglichkeit die Leuchtmittel mit den letzten Einstellungen anzuschalten (wie es die Hue App auch macht). Hierzu in den Adaptereinstellungen ‘natives Einschaltverhalten’ wählen
leider kann ich diesen trotz 2.3.1 nicht finden. Ich habe auch schon die Instanz einmal gelöscht und neu installiert...
-
@sveni_lee
Hab auch die 2.3.1 installiert. Bei mir gibt es de Punkt "natives Einschaltverhalten":
Bei dir im Screenshot fehlen einige Optionen...
-
@sveni_lee
mach mal einen Upload -
@Dr-Bakterius gepollt wird auch wenn du nichts steuerst. Ist kein Fehler, heißt nur dass er die Anfrage zurückhält, weil die Queue voll ist, so lange er nicht 10/10 loggt mit dem error zieht das nur eine minimale Verzögerung mit sich.
Hat @arteck dir allerdings damals schon mitgeteilt.
-
@foxriver76 sagte in Test Adapter hue v2.2.x:
Hat @arteck dir allerdings damals schon mitgeteilt.
Richtig. Er hat aber auch durchklingen lassen, dass das so nicht beabsichtigt ist und ich ein Issue erstellen soll (wurde von @apollon77 ohne Lösung geschlossen). Warnungen verunsichern nun einmal. Und bei einer kleinen Verzögerung ist eine Warnung IMHO auch nicht notwendig.
Interessant wäre auch, wie der Queue nur beim Pollen voll laufen kann?
-
@Dr-Bakterius sagte in Test Adapter hue v2.2.x:
Interessant wäre auch, wie der Queue nur beim Pollen voll laufen kann?
wen nein Gerät nicht antwortet weil du es vom Netz genommen hast versuchst es aber zu schalten .. nicht nur einmal . sonsder 10 mal.. dann wartet die Queue auf ein Timeout.. das stockt.. deshalb nie ein Device das im Zigbee Netz ist vom Strom nehmen..
-
@arteck Sorry, aber ich nehme fast alle meine Hue-Birnen immer vom Netz. Ist auch kein Problem. Ich schalte sie ein, und erst wenn sie erreichbar ist wird bei Bedarf eine Regel gestartet. In Verbindung mit Shellys kann ich so mit meinen alten Lichtschaltern schalten (WAF!) und das Licht auch smart (Alexa, ioBroker) steuern. Zu diesem erwähnten Zeitpunkt wurde aber nichts geschaltet (keiner zuhause - kein Skript aktiv)!
-
@Dr-Bakterius welches issue? Ich mache nur issues zu wenn es mit dem dev abgesprochen ist.
Ansonsten: auch ich nehme Shelly’s die aber nur das schalt Signal abgreifen. Meine Hues behalten dauerstrom. War mir zu nervig das Helligkeit und so beim einschalten ständig weg war weil 100% zu hell sind.
geht auch -
@apollon77 Issue ist oben (und hier auch) verlinkt.
Die Hue-Birnen merken sich den letzten Zustand (wenn in den Einstellungen aktiviert) und stellen diesen wieder her wenn sie eingeschaltet werden. Andere Hersteller (Innr, Osram, ...) können das aber nicht - zumindest mit der Hue-Bridge.
Edit: Wenn ich die Hue-Birnen vom Strom nehme, funktioniert das Ein- und Ausschalten unabhängig vom ioBroker. Also auch falls dieser oder mein Netzwerk ausfällt, kann man wie gewohnt das Licht schalten.
-
@Dr-Bakterius sagte in Test Adapter hue v2.2.x:
Edit: Wenn ich die Hue-Birnen vom Strom nehme, funktioniert das Ein- und Ausschalten unabhängig vom ioBroker.
Hm, kein Strom kein schalten? Oder checke ich da was nicht.
-
@sigi234 Ich schalte mit den herkömmlichen Lichtschaltern über die Shellys die Lampen. Strom aus - Lampe aus. Strom an - Lampe (mit den letzten Einstellungen wie Farbe und Helligkeit) an. Nach ca. 3 Sekunden sind sie über die Bridge erreichbar und können gesteuert werden. Alternativ kann ich den Strom über den Shelly schalten - also auch mit ioBroker ein- und ausschalten.
-
@Dr-Bakterius sagte in Test Adapter hue v2.2.x:
über die Shellys die Lampen
Das war der entscheidende Hinweis.
-
@Dr-Bakterius Die GroupQueue läuft schnell voll, weil nur eine Anfrage pro Sekunde für Gruppen von Philips selbst empfohlen wird und die Queue sich daran hält. Im Polling Interval wird nun einmal das Config Objekt gepollt, was in die GroupQueue fließt und anschließend die Gruppe 0 ('all'), muss leider extra gepollt werden. Somit kann es sein, dass sich das leicht in die Quere kommt und die Queue es etwas nach hinten verlagert.
Ich habe hier oder auf GitHub auch schon mal geschrieben, dass ich nur einen komplett nicht ausgeführten Befehl auf warn/err loggen würde. Habe es bislang allerdings nicht geändert, u. a. weil ich skeptisch war ob sich der Entwickler (jmaus) was näheres dabei gedacht hat.
-
@foxriver76 sagte in Test Adapter hue v2.2.x:
ob sich der Entwickler (jmaus) was näheres dabei gedacht hat.
Anfangs mag das bei der Entwicklung durchaus von Interesse sein um zu sehen wie sich der Queue bei den Usern verhält. Mittlerweile erkenne ich aber keinen Mehrwert das zu loggen. Vielleicht unter 'debug' oder wenn es sein soll als 'info' aber bitte nicht als 'warn' oder gar 'error'!
