NEWS
Zigbee Adapter 2.* & BWM
-
@neuschwansteini
Ich habe erst jetzt ausfgrund Deiner Message bemerkt, dass der Timeout-Punkt fehlt.
Habe zwar schon lange keinen mehr eingebaut, aber soweit ich weiss, war der Timeout default 300 sec. Ich habe sie damit dann immer auf 60 sec gestellt.
Wenn das nicht mehr funktioniert, dann kann man den Default ja nicht mehr verstellen. Und das wäre blöd.naja, das stand aber dick und fett bei den Breaking changes und der fette rote grosse Button im Adapter ist ja auch nicht zu uebersehen.. :D
Wenn du nach Anleitung vorgegangen bist, und davon gehe ich aus, hast du ja die alten Datenpunkte geloescht.
Oder machst du etwa Beta Test und liest die changes und Dokus nicht?.. ei ei ei... :) -
@Neuschwansteini
Das war mal wieder so ein Update, was ich kurz vor dem Urlaub erledigt hatte und da lese ich auch nicht wirklich alles zumal es sehr selten vorkommt und das im Beta, dass mal was nicht geht, oder eine Änderung im Adapter noch eine Änderung meiner Scripte nach sich zieht.
Der Dev hat ein Beispiel genannt, habe aber kein Plan was ich damit abfangen soll.Es fehlt auch nicht nur der eine DP sonder auch der Reset DP sonder auch noch der "no_motion" (einige andere welche ich nicht verwende ebenfalls) und genau die zwei hatte ich für die Funktion der Scripte gebraucht.
Ich schau mal dass ich das umbaue, da ich nicht wusste, dass occupancy nach 60 Sekunden wieder auf false stellt und ich eine paar Scripte habe, die eigentlich unter 60 Sekunden das Licht wieder ausschalten sollte, wenn keine weitere Bewegung erkannt wird.So sehen meine Scripte dazu aus und ohne die dazugehörigen DPs, muss ich hier einiges umbauen:
-
@Neuschwansteini
Das war mal wieder so ein Update, was ich kurz vor dem Urlaub erledigt hatte und da lese ich auch nicht wirklich alles zumal es sehr selten vorkommt und das im Beta, dass mal was nicht geht, oder eine Änderung im Adapter noch eine Änderung meiner Scripte nach sich zieht.
Der Dev hat ein Beispiel genannt, habe aber kein Plan was ich damit abfangen soll.Es fehlt auch nicht nur der eine DP sonder auch der Reset DP sonder auch noch der "no_motion" (einige andere welche ich nicht verwende ebenfalls) und genau die zwei hatte ich für die Funktion der Scripte gebraucht.
Ich schau mal dass ich das umbaue, da ich nicht wusste, dass occupancy nach 60 Sekunden wieder auf false stellt und ich eine paar Scripte habe, die eigentlich unter 60 Sekunden das Licht wieder ausschalten sollte, wenn keine weitere Bewegung erkannt wird.So sehen meine Scripte dazu aus und ohne die dazugehörigen DPs, muss ich hier einiges umbauen:
-
naja, das stand aber dick und fett bei den Breaking changes und der fette rote grosse Button im Adapter ist ja auch nicht zu uebersehen.. :D
Wenn du nach Anleitung vorgegangen bist, und davon gehe ich aus, hast du ja die alten Datenpunkte geloescht.
Oder machst du etwa Beta Test und liest die changes und Dokus nicht?.. ei ei ei... :) -
@Neuschwansteini
Das war mal wieder so ein Update, was ich kurz vor dem Urlaub erledigt hatte und da lese ich auch nicht wirklich alles zumal es sehr selten vorkommt und das im Beta, dass mal was nicht geht, oder eine Änderung im Adapter noch eine Änderung meiner Scripte nach sich zieht.
Der Dev hat ein Beispiel genannt, habe aber kein Plan was ich damit abfangen soll.Es fehlt auch nicht nur der eine DP sonder auch der Reset DP sonder auch noch der "no_motion" (einige andere welche ich nicht verwende ebenfalls) und genau die zwei hatte ich für die Funktion der Scripte gebraucht.
Ich schau mal dass ich das umbaue, da ich nicht wusste, dass occupancy nach 60 Sekunden wieder auf false stellt und ich eine paar Scripte habe, die eigentlich unter 60 Sekunden das Licht wieder ausschalten sollte, wenn keine weitere Bewegung erkannt wird.So sehen meine Scripte dazu aus und ohne die dazugehörigen DPs, muss ich hier einiges umbauen:
@jan1 sagte in Zigbee Adapter 2.* & BWM:
@Neuschwansteini
Das war mal wieder so ein Update, was ich kurz vor dem Urlaub erledigt hatte und da lese ich auch nicht wirklich alles zumal es sehr selten vorkommt und das im Beta, dass mal was nicht geht, oder eine Änderung im Adapter noch eine Änderung meiner Scripte nach sich zieht.
Der Dev hat ein Beispiel genannt, habe aber kein Plan was ich damit abfangen soll.Es fehlt auch nicht nur der eine DP sonder auch der Reset DP sonder auch noch der "no_motion" (einige andere welche ich nicht verwende ebenfalls) und genau die zwei hatte ich für die Funktion der Scripte gebraucht.
Ich schau mal dass ich das umbaue, da ich nicht wusste, dass occupancy nach 60 Sekunden wieder auf false stellt und ich eine paar Scripte habe, die eigentlich unter 60 Sekunden das Licht wieder ausschalten sollte, wenn keine weitere Bewegung erkannt wird.So sehen meine Scripte dazu aus und ohne die dazugehörigen DPs, muss ich hier einiges umbauen:
Das dieses Skript funktioniert hat ist meines Erachtens nach Absoluter Zufall.
Der Datenpunkt no_motion hat jede Sekunde seinen Wert geändert, bis ein interner Threshold eingestellt ist.
Zusätzlich schaltest du im ersten Teil deines Skriptes sowohl wenn der BWM auf wahr geht (Bewegung erkannt) als auch wenn er auf Falsch geht (keine Bewegung erkannt). Das ist Unsinn.Was du aktuell machen sollst:
- den ersten deiner Trigger umstellen auf 'ist grösser als vorher'
- den zweiten deiner Trigger umstellen auf den DP
occupancy, trigger auf 'ist kleiner als vorher'. - den Timeout im Trigger auf 50 sekunden erhöhen
- die Abfrage von
wertim Falls block entfernen
Fettich
A.
Nachtrag: Alternativ kannst du:
- den Gerätetyp als Local override eintragen (Siehe Bild)
- prüfen ob er geht. Wenn ja, gut. Wenn nein musst Du jemanden finden der den alten Code gängig macht. Ich kann (und will) das nicht mehr leisten.
- wenn der geht deine alten Skripte beibehalten
Wichtig : diese Einstellung
- betrifft alle baugleichen Geräte deren Typen eingetragen wird
- erzwingt die Nutzung von veraltetem Code der durch die reguläre Adapter-Entwicklung nicht weiter gewartet wird.
- ist nur aus der Konfiguration erreichbar, da ein Neustart des Adapters zur Aktivierung erforderlich ist
- birgt das Risiko das durch Adapter-Updates der Code in der Zukunft nicht mehr funktioniert, da weder auf der Bibliotheks-Seite (Zigbee-Herdsman-Converters) noch auf der Adapter Seite (ioBroker.zigbee) die Kompatibilität geprüft wird.
A.
-
@jan1 Da ist der Unterschied 10 Sekunden, ich denke das sollte man verschmerzen können. Ist halt etwas Arbeit, dann aber schnell erledigt.
-
@neuschwansteini
Ich habe erst jetzt ausfgrund Deiner Message bemerkt, dass der Timeout-Punkt fehlt.
Habe zwar schon lange keinen mehr eingebaut, aber soweit ich weiss, war der Timeout default 300 sec. Ich habe sie damit dann immer auf 60 sec gestellt.
Wenn das nicht mehr funktioniert, dann kann man den Default ja nicht mehr verstellen. Und das wäre blöd.@diwoma sagte in Zigbee Adapter 2.* & BWM:
@neuschwansteini
Ich habe erst jetzt ausfgrund Deiner Message bemerkt, dass der Timeout-Punkt fehlt.
Habe zwar schon lange keinen mehr eingebaut, aber soweit ich weiss, war der Timeout default 300 sec. Ich habe sie damit dann immer auf 60 sec gestellt.
Wenn das nicht mehr funktioniert, dann kann man den Default ja nicht mehr verstellen. Und das wäre blöd.Bei den 300 sekunden ging es immer nur um den
no_motionDatenpunkt. Die Geräte haben generell keine per Zigbee einstellbare Reaktionszeit - haben sie nie gehabt.
Die Standard Zeit zum widerauslösen bei den Geräten ist 60 s. Sie lässt sich durch Hardware-Modifikation auf 10 s senken.A.
-
@diwoma sagte in Zigbee Adapter 2.* & BWM:
@neuschwansteini
Ich habe erst jetzt ausfgrund Deiner Message bemerkt, dass der Timeout-Punkt fehlt.
Habe zwar schon lange keinen mehr eingebaut, aber soweit ich weiss, war der Timeout default 300 sec. Ich habe sie damit dann immer auf 60 sec gestellt.
Wenn das nicht mehr funktioniert, dann kann man den Default ja nicht mehr verstellen. Und das wäre blöd.Bei den 300 sekunden ging es immer nur um den
no_motionDatenpunkt. Die Geräte haben generell keine per Zigbee einstellbare Reaktionszeit - haben sie nie gehabt.
Die Standard Zeit zum widerauslösen bei den Geräten ist 60 s. Sie lässt sich durch Hardware-Modifikation auf 10 s senken.A.
@asgothian
Im ersten Teil des Script wird erkannt, ob Schalten durch Bewegung, oder durch manuelles Schalten am Taster, was dann im zweiten Teil ausgewertet wird und diese Scripte liefen so nicht nur zufällig, sonder absolut zuverlässig die letzten Jahre. Taster, Licht bleibt dauerhaft an, Bewegung und das Licht wird automatisch an/aus geschaltet ;)Die HW Modifikation ist mir bekannt, was aber nur die Zeitspanne einer erneuten Erkennung auf 10s erlaubt. Das wiederum ist eigentlich egal. Bin ich länger im Zimmer, dann ist die nächste Erkennung der Bewgung normal eh abgefangen un d bin ich etwas zu kurz drin, dann geht das Licht früher aus, was auch nicht stört.
-
@asgothian
Im ersten Teil des Script wird erkannt, ob Schalten durch Bewegung, oder durch manuelles Schalten am Taster, was dann im zweiten Teil ausgewertet wird und diese Scripte liefen so nicht nur zufällig, sonder absolut zuverlässig die letzten Jahre. Taster, Licht bleibt dauerhaft an, Bewegung und das Licht wird automatisch an/aus geschaltet ;)Die HW Modifikation ist mir bekannt, was aber nur die Zeitspanne einer erneuten Erkennung auf 10s erlaubt. Das wiederum ist eigentlich egal. Bin ich länger im Zimmer, dann ist die nächste Erkennung der Bewgung normal eh abgefangen un d bin ich etwas zu kurz drin, dann geht das Licht früher aus, was auch nicht stört.
@jan1 sagte in Zigbee Adapter 2.* & BWM:
Im ersten Teil des Script wird erkannt, ob Schalten durch Bewegung, oder durch manuelles Schalten am Taster, was dann im zweiten Teil ausgewertet wird und diese Scripte liefen so nicht nur zufällig, sonder absolut zuverlässig die letzten Jahre
Soll erkannt werden. Wie schon gesagt - das das geht ist eher lotto. Der code wird aktiv in 2 Situationen :
- der BWM erkennt das jemand im Raum ist
- der BWM erkennt das niemand mehr im Raum ist.
Mindestens die 2. Aktivierung ist Unsinn.
Durch die Umstellung des Triggers auf 'ist grösser als vorher' bleibt die Erkennung wie eingeschaltet wird durchaus erhalten
A.
-
@diwoma sagte in Zigbee Adapter 2.* & BWM:
@neuschwansteini
Ich habe erst jetzt ausfgrund Deiner Message bemerkt, dass der Timeout-Punkt fehlt.
Habe zwar schon lange keinen mehr eingebaut, aber soweit ich weiss, war der Timeout default 300 sec. Ich habe sie damit dann immer auf 60 sec gestellt.
Wenn das nicht mehr funktioniert, dann kann man den Default ja nicht mehr verstellen. Und das wäre blöd.Bei den 300 sekunden ging es immer nur um den
no_motionDatenpunkt. Die Geräte haben generell keine per Zigbee einstellbare Reaktionszeit - haben sie nie gehabt.
Die Standard Zeit zum widerauslösen bei den Geräten ist 60 s. Sie lässt sich durch Hardware-Modifikation auf 10 s senken.A.
@asgothian sagte in Zigbee Adapter 2.* & BWM:
Die Standard Zeit zum widerauslösen bei den Geräten ist 60 s. Sie lässt sich durch Hardware-Modifikation auf 10 s senken.
OK, dann ist es ja kein Problem.
Mit den 10 sec wusste ich, aber das brauche nicht (vor allem weil ich auch keine Lust am Basteln an dieser Hardware hatte :) )Das sich generell was an der neuen Version geändert hat, habe ich bemerkt, weil mein Button nicht mehr funktioniert hat.
Wie kann ich eigentlich den aktuellen Status der Datenpunkte herstellen, wenn ich jetzt schon auf Version 2.0.4 bin?
-- diwoma
ioBroker in LX-Container in Proxmox
Zigbee-Coordinator: CC2652P2-TCP FW: 20230507 -
@asgothian sagte in Zigbee Adapter 2.* & BWM:
Die Standard Zeit zum widerauslösen bei den Geräten ist 60 s. Sie lässt sich durch Hardware-Modifikation auf 10 s senken.
OK, dann ist es ja kein Problem.
Mit den 10 sec wusste ich, aber das brauche nicht (vor allem weil ich auch keine Lust am Basteln an dieser Hardware hatte :) )Das sich generell was an der neuen Version geändert hat, habe ich bemerkt, weil mein Button nicht mehr funktioniert hat.
Wie kann ich eigentlich den aktuellen Status der Datenpunkte herstellen, wenn ich jetzt schon auf Version 2.0.4 bin?
@diwoma sagte in Zigbee Adapter 2.* & BWM:
Wie kann ich eigentlich den aktuellen Status der Datenpunkte herstellen, wenn ich jetzt schon auf Version 2.0.4 bin?
Diese Frage verstehe ich nicht.
Ab der Version 2.0.2 werden alle Datenpunkte im Namespace des Zigbee Adapters (also unter zigbee.0.<deviceid> die nicht weiter vom Adapter verwendet werden farblich markiert. Alle fehlenden Datenpunkte werden beim Start des Adapters angelegt.
A.
-
@diwoma sagte in Zigbee Adapter 2.* & BWM:
Wie kann ich eigentlich den aktuellen Status der Datenpunkte herstellen, wenn ich jetzt schon auf Version 2.0.4 bin?
Diese Frage verstehe ich nicht.
Ab der Version 2.0.2 werden alle Datenpunkte im Namespace des Zigbee Adapters (also unter zigbee.0.<deviceid> die nicht weiter vom Adapter verwendet werden farblich markiert. Alle fehlenden Datenpunkte werden beim Start des Adapters angelegt.
A.
@asgothian sagte in Zigbee Adapter 2.* & BWM:
Ab der Version 2.0.2 werden alle Datenpunkte im Namespace des Zigbee Adapters (also unter zigbee.0.<deviceid> die nicht weiter vom Adapter verwendet werden farblich markiert. Alle fehlenden Datenpunkte werden beim Start des Adapters angelegt.
OK, die kann ich also löschen.
Und neue werden automatisch angelegt?-- diwoma
ioBroker in LX-Container in Proxmox
Zigbee-Coordinator: CC2652P2-TCP FW: 20230507 -
@asgothian sagte in Zigbee Adapter 2.* & BWM:
Ab der Version 2.0.2 werden alle Datenpunkte im Namespace des Zigbee Adapters (also unter zigbee.0.<deviceid> die nicht weiter vom Adapter verwendet werden farblich markiert. Alle fehlenden Datenpunkte werden beim Start des Adapters angelegt.
OK, die kann ich also löschen.
Und neue werden automatisch angelegt? -
@asgothian sagte in Zigbee Adapter 2.* & BWM:
Ab der Version 2.0.2 werden alle Datenpunkte im Namespace des Zigbee Adapters (also unter zigbee.0.<deviceid> die nicht weiter vom Adapter verwendet werden farblich markiert. Alle fehlenden Datenpunkte werden beim Start des Adapters angelegt.
OK, die kann ich also löschen.
Und neue werden automatisch angelegt?@diwoma sagte in Zigbee Adapter 2.* & BWM:
OK, die kann ich also löschen.
Und neue werden automatisch angelegt?Ja.
Zum Löschen bietet der Adapter sogar einen eigenen Button der nur verfügbar ist wenn es auch etwas zu löschen gibt. (siehe hier)
Das mit dem Markieren und Anlegen ist automatisch bei jedem start. Sprich insbesondere auch wenn man wie ich weiter oben im Thread beschrieben einzelne Gerätetypen auf den Legacy-Modus umstellt.
A.
-
@diwoma
Du kannst einfach alles löschen und den Adapter neu starten, dann ist das auch egal, da dann definitiv nix altes mehr da ist und das was der Adapter noch liefert, eh frisch angelegt wird.@jan1 sagte in Zigbee Adapter 2.* & BWM:
@diwoma
Du kannst einfach alles löschen und den Adapter neu starten, dann ist das auch egal, da dann definitiv nix altes mehr da ist und das was der Adapter noch liefert, eh frisch angelegt wird.Vorsicht - bei dieser Methode werden auch alle DP spezifischen Eigenschaften (History, Lovelace, ...) gelöscht. Ich rate davon ab. Besser ist es, die im diesem Post beschriebene Methode zum Löschen der unbenutzten DP zu verwenden.
Da kommt dann sogar eine Warnung wenn ein DP nicht gelöscht wurde weil dieser über eine DP-spezifische Konfiguration verfügt.
A.
-
@jan1 sagte in Zigbee Adapter 2.* & BWM:
@diwoma
Du kannst einfach alles löschen und den Adapter neu starten, dann ist das auch egal, da dann definitiv nix altes mehr da ist und das was der Adapter noch liefert, eh frisch angelegt wird.Vorsicht - bei dieser Methode werden auch alle DP spezifischen Eigenschaften (History, Lovelace, ...) gelöscht. Ich rate davon ab. Besser ist es, die im diesem Post beschriebene Methode zum Löschen der unbenutzten DP zu verwenden.
Da kommt dann sogar eine Warnung wenn ein DP nicht gelöscht wurde weil dieser über eine DP-spezifische Konfiguration verfügt.
A.
@asgothian
Alles Löschen wäre nicht von Vorteil, weil ich alle verwendeten Datenpunke als Alias gelinkt habe.
Danke für den Link. Ich werde es durchlesen und entsprechend handelnUnd das nächste mal die Breaking Changes durchlesen und beherzigen
-- diwoma
ioBroker in LX-Container in Proxmox
Zigbee-Coordinator: CC2652P2-TCP FW: 20230507 -
@asgothian
Alles Löschen wäre nicht von Vorteil, weil ich alle verwendeten Datenpunke als Alias gelinkt habe.
Danke für den Link. Ich werde es durchlesen und entsprechend handelnUnd das nächste mal die Breaking Changes durchlesen und beherzigen
@diwoma sagte in Zigbee Adapter 2.* & BWM:
@asgothian
Alles Löschen wäre nicht von Vorteil, weil ich alle verwendeten Datenpunke als Alias gelinkt habe.Das ist genau einer der Gründe warum
- der Adapter die betroffenen DP farbig markiert. Dann kannst du durchgehen und die Alias korrigieren
- der Adapter eine Funktion zum löschen hat. (die man nutzt nachdem man vorher die Alias alle korrigiert hat)
A.
p.s. Breaking changes bedeuten Arbeit. Das ist uns klar. In diesem Fall haben wir sogar versucht Hilfe dabei zu bekommen diese Abzumildern - allein, es kann sehr wenig, so das wir dazu gezwungen waren die von aussen vorgegebenen Breaking changes 1:1 durchzureichen.
Wir (die Adapter Entwickler) haben einfach nicht alle betroffenen Geräte im Einsatz, und die Zeiten wo ich bereit war mir ein Gerät zu besorgen damit wer anders das benutzen kann der mir dann (vielleicht) unfreundliche Posts schreibt sind inzwischen vorbei. Das tut mir durchaus etwas leid - für die die damit besser umgegangen sind - es war aber auf Dauer nicht mehr haltbar.
A.
Support us
391
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge