Einschaltverhalten Zigbee Leuchtmittel
-
Hallo zusammen,
ich kenne es bei meinen Leuchtmitteln von Osram, dass man das Einschaltverhalten nach Stromzufuhr in den Leuchtmittel speichern kann. Da ich diese Leuchtmittel nun gerne über den Zigbeeadapter steuern möchte mussten die Leuchtmittel ja wieder auf Werkseinstellungen zurückgesetzt werden.
Gibt es eine Möglichkeit dieses Einschaltverhalten über den Adapter neu auf die Leuchtmittel zu übertragen? Das aktuelle Eisnchaltverhalten nach Stromzufuhr passt mir nicht so ganz. -
Hallo zusammen,
ich kenne es bei meinen Leuchtmitteln von Osram, dass man das Einschaltverhalten nach Stromzufuhr in den Leuchtmittel speichern kann. Da ich diese Leuchtmittel nun gerne über den Zigbeeadapter steuern möchte mussten die Leuchtmittel ja wieder auf Werkseinstellungen zurückgesetzt werden.
Gibt es eine Möglichkeit dieses Einschaltverhalten über den Adapter neu auf die Leuchtmittel zu übertragen? Das aktuelle Eisnchaltverhalten nach Stromzufuhr passt mir nicht so ganz.Ich habe das gleiche Problem mit den Ikea Lampen.
Ich glaube es gibt keinen anderen Weg, als das logisch abzubilden.
Ich speichere also meinen gewünschten/letzten Zustand als state und setze diesen sobald der Datenpunkt "available" von false auf true springt. -
So hätte ich es am Ende auch gemacht.
-
Ich habe das gleiche Problem mit den Ikea Lampen.
Ich glaube es gibt keinen anderen Weg, als das logisch abzubilden.
Ich speichere also meinen gewünschten/letzten Zustand als state und setze diesen sobald der Datenpunkt "available" von false auf true springt.@mickym
Sorry, dass ich diesen alten Thread nochmal ausgrabe.
Kannst du mir vielleicht mal erklären, wie du die States abspeicherst und dann beim zustandswechsel abfragst?Bin noch relativ neu im Thema und weiß auch nicht genau, nach was ich suchen soll.
Danke & Gruß
-
@mickym
Sorry, dass ich diesen alten Thread nochmal ausgrabe.
Kannst du mir vielleicht mal erklären, wie du die States abspeicherst und dann beim zustandswechsel abfragst?Bin noch relativ neu im Thema und weiß auch nicht genau, nach was ich suchen soll.
Danke & Gruß
@fornax76
Du schaltest einfach nicht den Datenpunkt direkt, sondern einen virtuellen Datenpunkt den Du erstellt hast.Nehmen wir mal an Du schaltest eine Lampe über einen von Dir erstellten Datenpunkt: z.Bsp:
0_userdata.0.states.licht.flur.decke =true oder false
Ein Script oder Flow schaltet dann je nachdem was in dem Datenpunkt steht die eigentlich Lampe unter dem Zigbee-Adapter - also:
Beispiel:
zigbee.0.ec1b999555adb1a.state = 0_userdata.0.states.licht.flur.decke (also true oder false).
Wenn die Verbindung verloren geht oder das System neu hochfährt frägst Du 0_userdata.0.states.licht.flur.decke ab und setzt zigbee.0.ec1b999555adb1a.state erneut.
Die Lampen haben wie gesagt die unangenehme Eigenschaft, wenn der Strom weg ist und wiederkommt, dass die Lampen angehen.
Es ist keine 100%ige Lösung. Wenn der Stom weggeht dann geht normalerweise zigbee.0.ec1b999555adb1a.available = false. Kommt dann der Strom wieder wird der Wert = true. Das triggert dann erneut einen Flow, der den State in 0_userdata.0.states.licht.flur.decke abfragt und in zigbee.0.ec1b999555adb1a.state setzt.
Das ist wie gesagt keine 100%ige Lösung - da es eine Zeit braucht bis zigbee.0.ec1b999555adb1a.available = false bzw. true gesetzt wird und ich habe auch schon festgestellt, das selbst das Schalten nicht immer 100% ist. Dass Zustand der Lampe zumindest von dem Adapter nicht rückgemeldet wird ist entweder ein Problem des Protokolls oder des Adapters. Das weiß ich aber nicht. Ich weiß nicht ob das mit Conbee mit der Phoscon Software besser ist. Mir ist es im Moment nur zu viel Aufwand, das auszuprobieren.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@fornax76
Du schaltest einfach nicht den Datenpunkt direkt, sondern einen virtuellen Datenpunkt den Du erstellt hast.Nehmen wir mal an Du schaltest eine Lampe über einen von Dir erstellten Datenpunkt: z.Bsp:
0_userdata.0.states.licht.flur.decke =true oder false
Ein Script oder Flow schaltet dann je nachdem was in dem Datenpunkt steht die eigentlich Lampe unter dem Zigbee-Adapter - also:
Beispiel:
zigbee.0.ec1b999555adb1a.state = 0_userdata.0.states.licht.flur.decke (also true oder false).
Wenn die Verbindung verloren geht oder das System neu hochfährt frägst Du 0_userdata.0.states.licht.flur.decke ab und setzt zigbee.0.ec1b999555adb1a.state erneut.
Die Lampen haben wie gesagt die unangenehme Eigenschaft, wenn der Strom weg ist und wiederkommt, dass die Lampen angehen.
Es ist keine 100%ige Lösung. Wenn der Stom weggeht dann geht normalerweise zigbee.0.ec1b999555adb1a.available = false. Kommt dann der Strom wieder wird der Wert = true. Das triggert dann erneut einen Flow, der den State in 0_userdata.0.states.licht.flur.decke abfragt und in zigbee.0.ec1b999555adb1a.state setzt.
Das ist wie gesagt keine 100%ige Lösung - da es eine Zeit braucht bis zigbee.0.ec1b999555adb1a.available = false bzw. true gesetzt wird und ich habe auch schon festgestellt, das selbst das Schalten nicht immer 100% ist. Dass Zustand der Lampe zumindest von dem Adapter nicht rückgemeldet wird ist entweder ein Problem des Protokolls oder des Adapters. Das weiß ich aber nicht. Ich weiß nicht ob das mit Conbee mit der Phoscon Software besser ist. Mir ist es im Moment nur zu viel Aufwand, das auszuprobieren.
-
@fornax76
Du schaltest einfach nicht den Datenpunkt direkt, sondern einen virtuellen Datenpunkt den Du erstellt hast.Nehmen wir mal an Du schaltest eine Lampe über einen von Dir erstellten Datenpunkt: z.Bsp:
0_userdata.0.states.licht.flur.decke =true oder false
Ein Script oder Flow schaltet dann je nachdem was in dem Datenpunkt steht die eigentlich Lampe unter dem Zigbee-Adapter - also:
Beispiel:
zigbee.0.ec1b999555adb1a.state = 0_userdata.0.states.licht.flur.decke (also true oder false).
Wenn die Verbindung verloren geht oder das System neu hochfährt frägst Du 0_userdata.0.states.licht.flur.decke ab und setzt zigbee.0.ec1b999555adb1a.state erneut.
Die Lampen haben wie gesagt die unangenehme Eigenschaft, wenn der Strom weg ist und wiederkommt, dass die Lampen angehen.
Es ist keine 100%ige Lösung. Wenn der Stom weggeht dann geht normalerweise zigbee.0.ec1b999555adb1a.available = false. Kommt dann der Strom wieder wird der Wert = true. Das triggert dann erneut einen Flow, der den State in 0_userdata.0.states.licht.flur.decke abfragt und in zigbee.0.ec1b999555adb1a.state setzt.
Das ist wie gesagt keine 100%ige Lösung - da es eine Zeit braucht bis zigbee.0.ec1b999555adb1a.available = false bzw. true gesetzt wird und ich habe auch schon festgestellt, das selbst das Schalten nicht immer 100% ist. Dass Zustand der Lampe zumindest von dem Adapter nicht rückgemeldet wird ist entweder ein Problem des Protokolls oder des Adapters. Das weiß ich aber nicht. Ich weiß nicht ob das mit Conbee mit der Phoscon Software besser ist. Mir ist es im Moment nur zu viel Aufwand, das auszuprobieren.
@mickym sagte in Einschaltverhalten Zigbee Leuchtmittel:
Das ist wie gesagt keine 100%ige Lösung - da es eine Zeit braucht bis zigbee.0.ec1b999555adb1a.available = false bzw. true gesetzt wird und ich habe auch schon festgestellt, das selbst das Schalten nicht immer 100% ist. Dass Zustand der Lampe zumindest von dem Adapter nicht rückgemeldet wird ist entweder ein Problem des Protokolls oder des Adapters. Das weiß ich aber nicht. Ich weiß nicht ob das mit Conbee mit der Phoscon Software besser ist. Mir ist es im Moment nur zu viel Aufwand, das auszuprobieren.
Da kann ich aushelfen. Das ist kein Problem des Adapters, sondern ein Problem der Leuchtmittel. Viele Lampen melden eine Statusänderung selbstständig an den Koordinator - damit bekommt der Adapter das mit. Leider tun das nicht alle Leuchtmittel von Haus aus. So melden z.Bsp. die Ikea Trafos es nicht wenn sie per Fernbedienung direkt ein- oder ausgeschaltet werden.
Dieses Verhalten kann über eine Konfiguration (zumeist) übersteuert werden. Allerdings geht diese Konfiguration (zumeist) verloren wenn die Geräte Stromlos geschaltet werden.An dieser Stelle beginnt das Problem.
Die von Dir vorgeschlagene Lösung alles über (unverbundene) eigene Datenpunkte zu lösen funktioniert so lange wie sämtliche Schaltvorgänge vom ioBroker ausgehen. Zusätzlich muss sicher gestellt werden das jede Lampe über genau einen Datenpunkt gesteuert wird. Die Nutzung von Gruppen oder Szenen im Zigbee-Adapter sowie die Verwendung von externen Fernbedienungen die direkt auf die Lampen wirken ist damit nicht möglich.
Warum sollte klar sein - damit die Lösung funktioniert darf es keine Rückkoppelung des Lampenstatus auf den "Schaltstatus" geben, ansonsten kann es passieren das beim Hochfahren der Zigbee-Adapter den Status aller Lampen abfragt und den Schaltstatus auf den dann vorhandenen Status (Lampe ist an) setzt. Damit wäre aber der gewünschte Zustand nicht mehr verfügbar.
Ohne diese Rückkoppelung ist aber eine 1:1 Zuordnung von Schaltdatenpunkt zu Lampe zwingend notwendig. Wenn es 2 Schalt-Datenpunkte gibt können diese auch unterschiedliche Werte beinhalten - die Lampe kann das nicht.Dieses bitte nicht als Kritik an Deiner Lösung verstehen. Ich will nur auf die Randbedingungen hinweisen, damit es hinterher nicht heisst "aber das geht nicht so wie ich das will"
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@mickym sagte in Einschaltverhalten Zigbee Leuchtmittel:
Das ist wie gesagt keine 100%ige Lösung - da es eine Zeit braucht bis zigbee.0.ec1b999555adb1a.available = false bzw. true gesetzt wird und ich habe auch schon festgestellt, das selbst das Schalten nicht immer 100% ist. Dass Zustand der Lampe zumindest von dem Adapter nicht rückgemeldet wird ist entweder ein Problem des Protokolls oder des Adapters. Das weiß ich aber nicht. Ich weiß nicht ob das mit Conbee mit der Phoscon Software besser ist. Mir ist es im Moment nur zu viel Aufwand, das auszuprobieren.
Da kann ich aushelfen. Das ist kein Problem des Adapters, sondern ein Problem der Leuchtmittel. Viele Lampen melden eine Statusänderung selbstständig an den Koordinator - damit bekommt der Adapter das mit. Leider tun das nicht alle Leuchtmittel von Haus aus. So melden z.Bsp. die Ikea Trafos es nicht wenn sie per Fernbedienung direkt ein- oder ausgeschaltet werden.
Dieses Verhalten kann über eine Konfiguration (zumeist) übersteuert werden. Allerdings geht diese Konfiguration (zumeist) verloren wenn die Geräte Stromlos geschaltet werden.An dieser Stelle beginnt das Problem.
Die von Dir vorgeschlagene Lösung alles über (unverbundene) eigene Datenpunkte zu lösen funktioniert so lange wie sämtliche Schaltvorgänge vom ioBroker ausgehen. Zusätzlich muss sicher gestellt werden das jede Lampe über genau einen Datenpunkt gesteuert wird. Die Nutzung von Gruppen oder Szenen im Zigbee-Adapter sowie die Verwendung von externen Fernbedienungen die direkt auf die Lampen wirken ist damit nicht möglich.
Warum sollte klar sein - damit die Lösung funktioniert darf es keine Rückkoppelung des Lampenstatus auf den "Schaltstatus" geben, ansonsten kann es passieren das beim Hochfahren der Zigbee-Adapter den Status aller Lampen abfragt und den Schaltstatus auf den dann vorhandenen Status (Lampe ist an) setzt. Damit wäre aber der gewünschte Zustand nicht mehr verfügbar.
Ohne diese Rückkoppelung ist aber eine 1:1 Zuordnung von Schaltdatenpunkt zu Lampe zwingend notwendig. Wenn es 2 Schalt-Datenpunkte gibt können diese auch unterschiedliche Werte beinhalten - die Lampe kann das nicht.Dieses bitte nicht als Kritik an Deiner Lösung verstehen. Ich will nur auf die Randbedingungen hinweisen, damit es hinterher nicht heisst "aber das geht nicht so wie ich das will"
A.
@Asgothian sagte in Einschaltverhalten Zigbee Leuchtmittel:
@mickym sagte in Einschaltverhalten Zigbee Leuchtmittel:
Das ist wie gesagt keine 100%ige Lösung - da es eine Zeit braucht bis zigbee.0.ec1b999555adb1a.available = false bzw. true gesetzt wird und ich habe auch schon festgestellt, das selbst das Schalten nicht immer 100% ist. Dass Zustand der Lampe zumindest von dem Adapter nicht rückgemeldet wird ist entweder ein Problem des Protokolls oder des Adapters. Das weiß ich aber nicht. Ich weiß nicht ob das mit Conbee mit der Phoscon Software besser ist. Mir ist es im Moment nur zu viel Aufwand, das auszuprobieren.
Da kann ich aushelfen. Das ist kein Problem des Adapters, sondern ein Problem der Leuchtmittel. Viele Lampen melden eine Statusänderung selbstständig an den Koordinator - damit bekommt der Adapter das mit. Leider tun das nicht alle Leuchtmittel von Haus aus. So melden z.Bsp. die Ikea Trafos es nicht wenn sie per Fernbedienung direkt ein- oder ausgeschaltet werden.
Dieses Verhalten kann über eine Konfiguration (zumeist) übersteuert werden. Allerdings geht diese Konfiguration (zumeist) verloren wenn die Geräte Stromlos geschaltet werden.An dieser Stelle beginnt das Problem.
Die von Dir vorgeschlagene Lösung alles über (unverbundene) eigene Datenpunkte zu lösen funktioniert so lange wie sämtliche Schaltvorgänge vom ioBroker ausgehen. Zusätzlich muss sicher gestellt werden das jede Lampe über genau einen Datenpunkt gesteuert wird. Die Nutzung von Gruppen oder Szenen im Zigbee-Adapter sowie die Verwendung von externen Fernbedienungen die direkt auf die Lampen wirken ist damit nicht möglich.
Warum sollte klar sein - damit die Lösung funktioniert darf es keine Rückkoppelung des Lampenstatus auf den "Schaltstatus" geben, ansonsten kann es passieren das beim Hochfahren der Zigbee-Adapter den Status aller Lampen abfragt und den Schaltstatus auf den dann vorhandenen Status (Lampe ist an) setzt. Damit wäre aber der gewünschte Zustand nicht mehr verfügbar.
Ohne diese Rückkoppelung ist aber eine 1:1 Zuordnung von Schaltdatenpunkt zu Lampe zwingend notwendig. Wenn es 2 Schalt-Datenpunkte gibt können diese auch unterschiedliche Werte beinhalten - die Lampe kann das nicht.Dieses bitte nicht als Kritik an Deiner Lösung verstehen. Ich will nur auf die Randbedingungen hinweisen, damit es hinterher nicht heisst "aber das geht nicht so wie ich das will"
A.
Ich bin hier ja gerne für andere Lösungsmöglichkeiten offen - aber mir ist halt als Laie nichts anderes eingefallen, um mir zu helfen. Sprich wenn jemand die Lampe aus der Steckdose zieht und wieder einsteckt - leuchten die Lampen und der iobroker bekommt es nicht mir - deshalb die Kombination mit dem available DP.
Nun was ich in Deiner Erklärung fett markiert habe ist aber der springende Punkt. Das kann man ggf. abwägen, aber ich finde es ehrlich gesagt schlimmer vom Adapter nicht den IST-Zustand mitzubekommen, als den SOLL-Zustand, da ich dann ggf. selbst mit einer Logik drauf reagieren kann. So bekomme ich es ja gar nicht mit, wenn der state false aufweist und die Lampen zum Beispiel nach Stromausfall munter brennen. Bei vielen anderen Geräten gibt es deshalb ja den "command" Datenpunkt, der sich von "state" unterscheidet.
Das man wie Du beschreibst die Tradfri Konfig (über-)steuern kann, dass sie den Status berichten - das aber verloren geht, wenn die stromlos sind, wäre doch ebenfalls Klasse, wenn man das dann konfigurieren könnte, dass z.Bsp beim Hochfahren des Adapters oder wenn Lampe/Gerät wieder verfügbar - sowas als Defaulteinstellung vom Adapter gepusht wird.
Das Hauptproblem ist doch, dass ICH als Anwender keine Möglichkeit habe den IST-Stand eines Gerätes verlässlich zu sehen und das in meinen Augen ein gewaltiges Manko ist, wofür ich keine Lösung habe und ich Deiner Antwort auch keine entnehmen kann. Ich würde immer in diesem Fall 2 DP bevorzugen, wenn ich aber abwägen müsste, dann lieber den IST-Zustand und damit den SOLL Zustand verlieren. IST hätte in meinen Augen immer Vorrang vor SOLL. Letztlich bin ich doch dann auch unabhängiger davon, ob eine Lampe nun durch die Fernbedienung, Stromausfall oder sonst was geschaltet würde. Wie man damit umgeht, wenn 2 Schaltpunkte unterschiedliche Werte haben, würde ich eigentlich dem Anwender überlassen und dies über Skript lösen.
Letztlich bin ich aber viel zu viel Laie um beurteilen zu können, ob man mit dem Zigbee Protokoll die Zustände eines Gerätes abfragen kann (z. Bsp. durch Polling) oder die Hersteller dieser Geräte ihren Zustand beim Wiederhochfahren (wenn wieder strom da ist) melden - oder warum bei den Tradfri Lampen überhaupt in diesem Fall Default das Ganze nicht aus ist. Im Prinzip habe ich KEINE Lösung als Laie den tatsächlichen Zustand meiner Lampen abzufragen, geschweige denn zu sehen und das ist ein gewaltiger Nachteil. Das ist auch keine Kritik - ich habe nur keine Lösung????
Warum meine Lösung auch nicht 100%ig ist und nicht das Gelbe vom Ei - das erlebe ich ja selbst. Ich schalte eine Lampe aus, die ist aber temporär nicht verfügbar (warum auch immer) - also bleibt sie an. Im Adapter ist sie aus - aber in Realität brennt sie, bis ich wieder einen An- Aus Zyklus vornehme. Im Prinzip speichere ich mit meinem DP nur den SOLL-Zustand und stochere im Nebel bei verschiedenen Anlässen (zum Bsp. Available= false oder Neustart des Systems) diesen zu setzen ohne zu wissen ob es notwendig ist, es geklappt hat usw. . Wie gesagt ich bin für alle Vorschläge dankbar die dieses Problem lösen.
-
@mickym sagte in Einschaltverhalten Zigbee Leuchtmittel:
Das ist wie gesagt keine 100%ige Lösung - da es eine Zeit braucht bis zigbee.0.ec1b999555adb1a.available = false bzw. true gesetzt wird und ich habe auch schon festgestellt, das selbst das Schalten nicht immer 100% ist. Dass Zustand der Lampe zumindest von dem Adapter nicht rückgemeldet wird ist entweder ein Problem des Protokolls oder des Adapters. Das weiß ich aber nicht. Ich weiß nicht ob das mit Conbee mit der Phoscon Software besser ist. Mir ist es im Moment nur zu viel Aufwand, das auszuprobieren.
Da kann ich aushelfen. Das ist kein Problem des Adapters, sondern ein Problem der Leuchtmittel. Viele Lampen melden eine Statusänderung selbstständig an den Koordinator - damit bekommt der Adapter das mit. Leider tun das nicht alle Leuchtmittel von Haus aus. So melden z.Bsp. die Ikea Trafos es nicht wenn sie per Fernbedienung direkt ein- oder ausgeschaltet werden.
Dieses Verhalten kann über eine Konfiguration (zumeist) übersteuert werden. Allerdings geht diese Konfiguration (zumeist) verloren wenn die Geräte Stromlos geschaltet werden.An dieser Stelle beginnt das Problem.
Die von Dir vorgeschlagene Lösung alles über (unverbundene) eigene Datenpunkte zu lösen funktioniert so lange wie sämtliche Schaltvorgänge vom ioBroker ausgehen. Zusätzlich muss sicher gestellt werden das jede Lampe über genau einen Datenpunkt gesteuert wird. Die Nutzung von Gruppen oder Szenen im Zigbee-Adapter sowie die Verwendung von externen Fernbedienungen die direkt auf die Lampen wirken ist damit nicht möglich.
Warum sollte klar sein - damit die Lösung funktioniert darf es keine Rückkoppelung des Lampenstatus auf den "Schaltstatus" geben, ansonsten kann es passieren das beim Hochfahren der Zigbee-Adapter den Status aller Lampen abfragt und den Schaltstatus auf den dann vorhandenen Status (Lampe ist an) setzt. Damit wäre aber der gewünschte Zustand nicht mehr verfügbar.
Ohne diese Rückkoppelung ist aber eine 1:1 Zuordnung von Schaltdatenpunkt zu Lampe zwingend notwendig. Wenn es 2 Schalt-Datenpunkte gibt können diese auch unterschiedliche Werte beinhalten - die Lampe kann das nicht.Dieses bitte nicht als Kritik an Deiner Lösung verstehen. Ich will nur auf die Randbedingungen hinweisen, damit es hinterher nicht heisst "aber das geht nicht so wie ich das will"
A.
@Asgothian Übrigens generell erst mal vielen Dank für Dein Feedback.
Aufgrund meiner Ausführungen von vorhin an Dich die Frage, kann ich den via Node-Red oder Javascript selbst den IST-Status der Lampen abfragen und in eigene Datenpunkte schreiben?
In dem Entwickler-Tab des Adapters kann ich ja Befehle eingeben. Ich weiß zwar nicht was ich da machen muss, aber wichtig wäre erst mal zu wissen, ob man von außen quasi über den Adapter was über den IST-Zustand der Lampen in Erfahrung bringen kann?
-
@Asgothian Übrigens generell erst mal vielen Dank für Dein Feedback.
Aufgrund meiner Ausführungen von vorhin an Dich die Frage, kann ich den via Node-Red oder Javascript selbst den IST-Status der Lampen abfragen und in eigene Datenpunkte schreiben?
In dem Entwickler-Tab des Adapters kann ich ja Befehle eingeben. Ich weiß zwar nicht was ich da machen muss, aber wichtig wäre erst mal zu wissen, ob man von außen quasi über den Adapter was über den IST-Zustand der Lampen in Erfahrung bringen kann?
Vielen Dank für die Diskussion.
Mir ging es bei meiner Frage noch um einen anderen Umstand.
Vielleicht mache ich aber auch nur was falsch.Folgendes Szenario:
E27 Trådfri Lampe über Zigbee Adapter am IOBroker.
Lampe ist auf 50%
Lampe aus und wieder an über IObroker, und die Lampe geht wieder auf 50% an.
Schalte ich die Lampe aber über einen Sprachbefehl ein, wird sie immer auf 100% eingeschaltet.Das ist wirklich sehr unpraktisch.
Gibt es dafür einen workaround?Gruß
Björn -
Vielen Dank für die Diskussion.
Mir ging es bei meiner Frage noch um einen anderen Umstand.
Vielleicht mache ich aber auch nur was falsch.Folgendes Szenario:
E27 Trådfri Lampe über Zigbee Adapter am IOBroker.
Lampe ist auf 50%
Lampe aus und wieder an über IObroker, und die Lampe geht wieder auf 50% an.
Schalte ich die Lampe aber über einen Sprachbefehl ein, wird sie immer auf 100% eingeschaltet.Das ist wirklich sehr unpraktisch.
Gibt es dafür einen workaround?Gruß
Björn -
@fornax76 Prüf mal bitte was dein "Sprachbefehl" als Aktion auslöst. Ich gehe davon aus das der explizit die Helligkeit mit setzt, weswegen diese auf 100% geht.
Das hat mit Zigbee und dem darunter liegenden Problem nichts zu tun.
A
@Asgothian
Danke für deine Antwort.
Du hast recht.
Der Befehl "Lampe an" führt zum Befehl set Brightness 100%
Wenn ich so drüber nachdenke irgendwie logisch.
Ich hab den Punkt "brightness" in der IOT Instanz angegeben, weil ich ja auch über den Sprachassistent dimmen will.
Aber sowohl state als auch brghtness anzugeben macht auch wenig Sinn, oder?Gruß
Björn -
@Asgothian
Danke für deine Antwort.
Du hast recht.
Der Befehl "Lampe an" führt zum Befehl set Brightness 100%
Wenn ich so drüber nachdenke irgendwie logisch.
Ich hab den Punkt "brightness" in der IOT Instanz angegeben, weil ich ja auch über den Sprachassistent dimmen will.
Aber sowohl state als auch brghtness anzugeben macht auch wenig Sinn, oder?Gruß
Björn
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden520
Online32.9k
Benutzer83.0k
Themen1.3m
Beiträge