Zigbee 1.6.6 Update kein Ansteuern der Aussensirene
-
Sehe ich das richtig? send_payload ist ein Datenpunkt, der von dir eingerichtet wurde, um die ohnehin vorhandenen Datenpunkte gleichen Namens auf einen Streich mit den übergebenen Werten zu belegen.
Ich habe mir ein BlocklySkript erstellt, in dem ich alle Werte recht bequem editieren kann. Ist das in Ordnung so? Sollte ich ggf. die Bestätigung des Befehls aktivieren?
Dann heißt's jetzt wohl: Bitte Daumen drücken!
-
@legro Ich empfehle Dir Dich für einen Test darauf zurück zu ziehen das du eine oder mehrere Standard-Kombinationen einfach als Text zusammen stellst und dann im blockly sendest..
Alarm = '{"warning": {"mode": "emergency", "level": "high", "strobe_level": "high", "strobe": true, "strobe_duty_cycle": 10, "duration": 60}}'; SireneAn = '{"warning": {"mode": "fire", "level": "high", "strobe": false,"duration": 120}}'; SireneAus = '{"warning": {"mode": "off"}}';Dann kannst du zwar das ganze nicht so feingliedrig machen, kannst aber feste Signale für feste "Events" vorgeben.
A.
-
Vielen Dank für dein Hilfe! Gute Arbeit! Du hast natürlich recht: Erst mal die Pflicht, dann die Kür.
Endlich können wir unser Alarmsystem für Rauch, Einbruch, Wasser und Gas wieder in Betrieb setzen.
Mit SireneAn und SireneAus kann ich nun endlich unser Alarmsystem wieder zum Leben erwecken. Wenn ich das Ganze umgesetzt habe, gehe ich an das Austesten, was die übrigen Parameter bei meinen Geräten so alles (nicht) auslösen. Ich habe nur Geräte aus der ersten Generation. Vermutlich stellen diese gar nicht die vielfältigen Optionen bereit, die man über send_payload auslösen können sollte.
Erst gestern habe ich den Tag mit den Arbeiten zu unserm NUKI, das ich austauschen musste, zugebracht. Ich bastle eigentlich recht gerne, aber im Moment, wird's mir dann doch zu viel.
-
@legro
Es freut mich das es funktioniert. den entsprechenden PR auf den Haupt-Adpater gibt es am Wochenende, dann ist das auch ohne die Sonderversion von mir so verfügbar.A.
-
Wenn ich die Arbeiten und Tests (hoffentlich) erfolgreich abgeschlossen bekomme, kann ich gerne eine kleine Dokumentation über Verwendung und Auswirkung der vielen Parameter erstellen.
-
@asgothian said in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:
Es freut mich das es funktioniert. ..
Und schon gibt's erste Ergebnisse meiner Tests.
Unsere Rauchmeldern 902010/24 geben keinen Ton von sich, wenn sie einen Parameterwert erhalten, den sie nicht zu unterstützen scheinen. Andererseits wirkt sich eine Änderung eines Parameters überhaupt nicht aus.
Zwei Beispiele ..
Verändere ich den Parameter "level: high -> low", so bleibt die Sirene still.
Hingegen bei "mode: fire -> burglar" funktioniert die Signalisierung und ist unverändert.Interessant wird's wohl, wenn ich die Außensirene teste. Die sollte - so die vollmundigen Ankündigungen von der Telekom zu ihrem System MSH alias Qivicon - für unterschiedliche Alarme ausgelegt sein. Nur haben die Telekomiker das nie hinbekommen. Vielleicht gelingt es ja uns nun doch noch.
Im Gegensatz zu den Rauchmeldern verfügt die Außensirene 902010/29 nicht nur über einen akustischen, sondern auch über einen optischen Melder.
-
Nun habe ich eifrig alles Mögliche getestet. Offenbar können die alten Rauchmelder 902010/24 von BITRON allzu viel. Die meisten Optionen zeigen keine Wirkungen.
Rauchmelder 902010/24
„mode“- „stop“: Sirene ist still
- „burglar“: Sirene schrillt
- „fire“: wie bei „burglar“
- „emergency“: wie „burglar“
- „police_panic“: wie „burglar“
- „fire_panic“: wie „burglar“
- „emergency_panic“: wie „burglar“
„level"- low -> Sirene bleibt still
- medium -> Sirene schrillt die in „duration“ angegebenen Sekunden
- high -> Sirene schrillt mit Unterbrechungen von 1s die in „duration“ angegebenen Sekunden
- very_high -> dasselbe Verhalten wie unter „medium“
„strobe“- „true“: Sirene ist still
- „false“: Sirene schrillt
„strobe_level“- „low“, „medium“, „high“, „very_high“ haben keinen Einfluss
- Sirene bleibt stets still, wenn „strobe“ = true
- Sirene schrillt nur bei „strobe" = false wie oben beschrieben
Die weiteren Optionen habe ich nicht weiter getestet. Das Ganze erscheint mir unnötig.
Mutig geworden habe ich nun versucht, anstelle deine Datenpunktes send_payload die vom herdsman zur Verfügung gestellten Datenpunkte direkt anzusteuern. Das scheint so nicht zu funktionieren, wie die nachfolgende Abbildung zeigt.
Sehe ich das richtig, dass du via send_payload Konvertierung der Daten vornimmst? Gilt es darüber hinaus eine Reihenfolge beim Beschreiben der Datenpunkte vom herdsman einzuhalten?
-
@legro sagte in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:
Mutig geworden habe ich nun versucht, anstelle deine Datenpunktes send_payload die vom herdsman zur Verfügung gestellten Datenpunkte direkt anzusteuern. Das scheint so nicht zu funktionieren, wie die nachfolgende Abbildung zeigt.
Sehe ich das richtig, dass du via send_payload Konvertierung der Daten vornimmst? Gilt es darüber hinaus eine Reihenfolge beim Beschreiben der Datenpunkte vom herdsman einzuhalten?
Das siehst du falsch. Die expliziten Datenpunkte und deren Ansteuerung funktioniert vollständig nicht. Es gibt einen Ansatz das umzustellen, welcher aber einen "breaking change" erzeugt, weswegen ich damit vorsichtig bin.
Das send_payload sendet die Daten so wie sie eingetragen werden direkt an das Gerät und hat keine weitere Verbindung zu den States. Wenn auf Basis des send_payload das Gerät einen Status bestätigt werden auf Grund dieser Antwort die States aktualisiert werden.A.
-
@asgothian said in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:
Das siehst du falsch. Die expliziten Datenpunkte und deren Ansteuerung funktioniert vollständig nicht. Es gibt einen Ansatz das umzustellen, welcher aber einen "breaking change" erzeugt, weswegen ich damit vorsichtig bin.
Dann werde auch ich vorsichtig sein und brav dein send_payload verwenden.
Vielen Dank für eure gute Arbeit.
Ich probiere als nächstes die Außensirene aus. Diese hat ja einen akustischen und optischen Alarmgeber. Vielleicht kann diese etwas mit den "strobe"-Parametern anfangen. In den Anfängen von dem Smarthome der Telekom - MSH/Qivicon - hatten einige stolz berichtet, dass ihre Außensirene unterschiedliche Signalisierungen für Rauch und Einbruch ausgäbe. Bei mir hat das jedoch nie funktioniert, allerdings war zu meiner Zeit das Alarmsystem durch die Telekomiker völlig zurückgebaut und funktionierte nur noch rudimentär: Wenn ein Sensor, ob Wasser, Fensterkontakt, Rauch, .. auslöste, stets tröteten alle Sirenen los.
Bevor ich mich jedoch daran wage, werde ich sie wohl abmontieren oder meine Nachbarschaft vorwarnen müssen. Am Ende steht sonst die gesamte Nachbarschaft bei mir vor der Tür.
Ich werde berichten.
-
Meine hier gepostete Auflistung spiegelt leider nicht wider, was es alles zu bedenken gilt. Offenbar sind einige Parameter nicht obsolet.
Beispiel ..
Wird als JSON der String {"warning": {"mode": "fire", "medium": "high", "strobe": false, "duration": 60}} verwendet, funktioniert die Sirene und die Parameter medium (durchgängiges Heulen) und high (Heulen mit Unterbrechung) funktionieren wie beschrieben. Setzt man "strobe": true so bleibt die Sirene stumm.
Lässt man jedoch den Parameter "strobe" komplett weg, bleibt die Sirene ebenfalls stumm.
Um dieses Rätsel zu lösen, müsste der Mantel des Schweigens rund um den Datenpunkt send_payload gelüftet werden. Wie ist die Logik dahinter implementiert? Wie werden die vom herdsman durchgereichten Datenpunkten angesteuert? Werden bei nicht vorhandenen Parameter Standardwerte (Defaults) übermittelt? Usw.
Ohne weitere Informationen zu send_payload ist das Ganze wie ein Fischen im Trüben.
-
Es keine Logik dahinter.
Das was du einträgst wird 1:1 so an den Converter gesendet. Keine Modifikation.
Leider gibt es die Erklärung nur auf englisch: https://www.zigbee2mqtt.io/devices/AV2010_24.html
Daher habe ich das weiter oben im Thread geholt und übersetzt.
A.
-
@asgothian said in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:
Es keine Logik dahinter.
Das was du einträgst wird 1:1 so an den Converter gesendet. Keine Modifikation.Entspricht send_payload somit dem Datenpunkt warning des Adapter eins-zu-eins? Mithin wäre es dann am Adapter nicht angegebene Parameter mit seinen Standardwerten zu füllen.
Irgendwie verstehe ich das Ganze wohl einfach noch nicht ausreichend.
Sei's d'rum! Um unser Alarmsystem soweit fit machen, dass es wieder funktioniert wie zuvor, dazu muss ich das auch nicht in aller Tiefe verstehen.
Die Außensirene werde ich einmal abbauen und an ihr die Wirkung der Parameter, die bei den Rauchmeldern (so gut wie) keine Reaktion hervorrufen (z.B. jene mit strobe im Namen), austesten. Die Nachbarn sind vorgewarnt, denn die Sirene ist dermaßen laut, dass sie auch außen zu hören ist, wenn sie im Haus losheult.
Was dabei herauskommt, werde ich hier berichten.
-
@legro sagte in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:
Entspricht send_payload somit dem Datenpunkt warning des Adapter eins-zu-eins? Mithin wäre es dann am Adapter nicht angegebene Parameter mit seinen Standardwerten zu füllen.
Irgendwie verstehe ich das Ganze wohl einfach noch nicht ausreichend.Zwischen dem Datenpunkt "send_payload" und den anderen Datenpunkten des Adapters gibt es gar keine Verbindung. Eigentlich ist "send_payload" dazu gedacht Funktionen anzusteuern die nicht als Datenpunkte zur Verfügung gestellt werden.
Was also in den Datenpunkten "excute_warning", "level", "mode", "strobe", "strobe_duty_cycle", "strobe_level", "duration" und "level" drin steht ist für die Nutzung des Datenpunktes "send_payload" irrelevant.
Problematisch ist das die zigbee-herdsman-converters erwarten das die Werte der Datenpunkte "level", "mode", "strobe", "strobe_duty_cycle", "strobe_level", "duration" und "level" gemeinsam als "warning" an das Gerät geschickt werden. Dieses setzt der Adapter (noch) nicht sauber um. Ich würde daher empfehlen die genannten States einfach nicht weiter zu nutzen.
Ich habe mir auch noch einmal angeschaut was als früher durch den state "execute_warning" gesendet wurde. Du kannst versuchen nur dieses an die Sirene zu schicken, da das ja bisher funktioniert hatte. In diesem Fall müsste bei "send_payload" der Wert
"{'strobe':false, 'duration':x}"eingetragen werden, wobei statt x die Dauer des Signals angegeben werden muss (in Sekunden, 0 für aus)Ansonsten würde ich empfehlen einzelne substates einfach nicht mit Werten zu belegen wenn sie nicht wichtig sind. Insbesondere die Werte fuer "strobe" und "strobe_level" können entfallen.
A.
-
@asgothian said in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:
Zwischen .. "send_payload" und den anderen Datenpunkten .. gibt es gar keine Verbindung. ..
.. Problematisch ist das die zigbee-herdsman-converters erwarten das die Werte der Datenpunkte "level", "mode", "strobe", "strobe_duty_cycle", "strobe_level", "duration" und "level" gemeinsam als "warning" an das Gerät geschickt werden. ..
.. Dieses setzt der Adapter (noch) nicht sauber um. Ich würde daher empfehlen die genannten States einfach nicht weiter zu nutzen.Vielen Dank für diese klärenden Erläuterungen. Ich hatte dies nach meinen Tests ja bloß nur vermuten können und meine Programmierung darauf abgestimmt.
.. Du kannst versuchen nur dieses an die Sirene zu schicken, da das ja bisher funktioniert hatte. In diesem Fall müsste bei "send_payload" der Wert
"{'strobe':false, 'duration':x}"eingetragen werden, ..Innerhalb meines Alarmsystems verwende ich zur Ansteuerung (derzeit) nur
{"warning": {"mode": "fire", "level": "high", "strobe": false,"duration": 120}}en detail ..
- mode verwende ich zum Abschalten (off oder stop), ansonsten ist's wohl egal, was ich da reinschreibe.
- Mit level kann ich eine unterschiedliche Signalisierung bewirken (medium kontinuierliches, high unterbrochenes Heulen).
- strobe muss ich auf false setzen.
- Alle übrigen Parameter lasse ich (derzeit noch) weg.
Könntest du uns bitte informieren, wenn sich in Sachen herdsman etwas tut?
Ich untersuche/teste nun, wie's um die Ansteuerung der Außensirene bestellt ist und werde hier berichten.
-
@legro sagte in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:
Könntest du uns bitte informieren, wenn sich in Sachen herdsman etwas tut?
Die Notwendigen Anpassungen werden nicht im Herdsman sondern im Zigbee Adapter vorgenommen werden. Und ja, ich informiere darüber - schon weil sich dadurch verhältnismässig viel ändert.
A.
-
Nun bin ich eifrig die Außensirene am Testen. Die reagiert offensichtlich auf Befehle, die bei den Rauchmeldern keine Reaktion auslösten. Sowohl das Blinken (strobe) als auch die Tonsignale können beeinflusst werden.
Jetzt kommt mein hier erstelltes Blockly doch noch zum Einsatz.
Sobald ich einen Überblick habe, gibt's hier eine Dokumentation darüber.
PS:
Den Telekomikern bei MSH/Qivicon können wir also bald Nachhilfe geben.
-
Nun bin ich mit meiner ersten Testserie durch. Die Ergebnisse sind äußerst verwirrend.
Beispielsweise scheint es egal zu sein, ob "strobe" auf true oder false gesetzt wird. Warum allein die Änderung beim Parameter "level" sich auch das Blinken verändert, kann ich mir nicht erklären. Dafür scheinen Änderungen im Parameter "strobe_level" keine Auswirkungen zu haben.
Da scheint wohl noch einiges im Argen zu liegen. Aber das soll mich nun nicht weiter stören, kann ich doch endlich an der Außensirene unsere Alarmarten (Rauch, Einbruch, Wasser, Gas) mit den bereits zur Verfügung stehenden Mitteln optisch und akustisch unterschiedlich signalisieren.
-
Hier einmal eine Rückmeldung vom ZigBee-Adapter:
Diesen Fehler habe ich ausgelöst, indem ich die Parameterwerte low und medium ohne Anführungszeichen eingab.
Ein Beispiel aus meiner Testsequenz ..
In diesem Beispiel erzeugt die Sirene 902010/29 optisch ein horizontal hin- und herlaufendes Lauflicht und gibt akustisch piep - piep - piep .. aus.
Fazit ..
Mein Vorschlag: Ausgehend von einem funktionierenden Beispiel sollte man die Parameterwerte systematisch ändern. So findet man - allerdings mit viel Mühe - nach und nach heraus, was geht und was nicht.
Ich bin, auch wenn ich noch nicht alles verstehe, alles in allem recht zufrieden.
-
@legro sagte in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:
Hier einmal eine Rückmeldung vom ZigBee-Adapter:
Es gibt an dieser Stelle 3 mögliche Reaktionen:
- eine Warnmeldung wenn die übergebenen Daten vom Format her falsch sind (Das Beispiel von @legro gehört dazu)
- eine Warnmeldung das es keinen Konverter für einen Schlüssel gibt - diese Meldung kommt immer dann wenn die Implementierung in den zigbee-herdsman-converters den Initialen Schlüssel im JSON nicht akzeptieren. Im Beispiel oben ist "warning" der initiale Schlüssel
- Eine Fehlermeldung 'error Send command to .. failed with ... - diese Meldung entsteht wenn das Gerät die Nachricht nicht erhält oder den Erhalt nicht bestätigt. Sie deutet in den meisten Fällen auf ein problem mit dem Funknetzwerk hin.
A.
-
Hallo, irgendwie knaubeln viele an dem neuen Problem.
ich habe es mal in ein Script gefaßt, jetzt ist es wenigstens wieder laut.
Ich denke es wird wohl auch nur eine vorübergehende Lösung sein. Eingestellt wird es über den Datenpunkt Alarmsound<xml xmlns="https://developers.google.com/blockly/xml"> <variables> <variable type="interval" id="Intervall">Intervall</variable> <variable id="eeE_d!2Ey;9v%Qk9#*e!">Alarm erstellen</variable> <variable id="uIH]RFlkkm@Km41QGhaA">SireneAn</variable> </variables> <block type="timeouts_setinterval" id="?8hK!-J!G%AAa9N}!}i7" x="13" y="-387"> <field name="NAME">Intervall</field> <field name="INTERVAL">5000</field> <field name="UNIT">ms</field> </block> <block type="on" id="wl[o7J|ZgCK_n%fGy;a)" x="-512" y="13"> <field name="OID">zigbee.3.00124b0008b76e21.mode</field> <field name="CONDITION">ne</field> <field name="ACK_CONDITION"></field> <statement name="STATEMENT"> <block type="controls_if" id="2{XK@.Cyr`It+,rZ9{4^"> <value name="IF0"> <block type="logic_compare" id=".lVhjuRW,$$ackB9*=Qf"> <field name="OP">NEQ</field> <value name="A"> <block type="get_value" id=".x,whcjOEE0$to(M(Z*c"> <field name="ATTR">val</field> <field name="OID">zigbee.3.00124b0008b76e21.mode</field> </block> </value> <value name="B"> <block type="text" id=";dkr5}gI@fkNV^33;gyj"> <field name="TEXT">stop</field> </block> </value> </block> </value> <statement name="DO0"> <block type="variables_set" id="sZW,Yr8IfPP8YfXws==^"> <field name="VAR" id="eeE_d!2Ey;9v%Qk9#*e!">Alarm erstellen</field> <value name="VALUE"> <block type="text_join" id="`PhFOo7m~lCXd/]YQPN4"> <mutation items="9"></mutation> <value name="ADD0"> <block type="text" id="a7HB86`x#0,H2mxt4uY["> <field name="TEXT">{"warning": {"mode": "</field> </block> </value> <value name="ADD1"> <block type="get_value" id="?ydvm5{xrd!H(7mj.J2%"> <field name="ATTR">val</field> <field name="OID">zigbee.3.00124b0008b76e21.mode</field> </block> </value> <value name="ADD2"> <block type="text" id=":bmrU,b=74,Jxh~x?-8|"> <field name="TEXT">", "level": "</field> </block> </value> <value name="ADD3"> <block type="get_value" id="prF%[7$-uW%36^H|raZe"> <field name="ATTR">val</field> <field name="OID">zigbee.3.00124b0008b76e21.level</field> </block> </value> <value name="ADD4"> <block type="text" id="yfqtoefyW@xG*#v%M@Pk"> <field name="TEXT">", "strobe_level": "</field> </block> </value> <value name="ADD5"> <block type="get_value" id="NrFLOB.HcSy_^dXbNR=?"> <field name="ATTR">val</field> <field name="OID">zigbee.3.00124b0008b76e21.strobe_level</field> </block> </value> <value name="ADD6"> <block type="text" id="QxX[Xl`OHC*ROdQ.9v@@"> <field name="TEXT">", "strobe":</field> </block> </value> <value name="ADD7"> <block type="get_value" id=":92PW0z!T69A2a8k;]75"> <field name="ATTR">val</field> <field name="OID">zigbee.3.00124b0008b76e21.strobe</field> </block> </value> <value name="ADD8"> <block type="text" id="?oT4~+UzcfPQ%[*!+nr:"> <field name="TEXT">, "strobe_duty_cycle": 10, "duration": 60}}</field> </block> </value> </block> </value> <next> <block type="control" id="h9`^F[o$h4B,|KHL!LmB"> <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="false"></mutation> <field name="OID">zigbee.3.00124b0008b76e21.send_payload</field> <field name="WITH_DELAY">FALSE</field> <value name="VALUE"> <block type="variables_get" id="5G|#`UWzx00qJK*P.G/z"> <field name="VAR" id="eeE_d!2Ey;9v%Qk9#*e!">Alarm erstellen</field> </block> </value> <next> <block type="variables_set" id="mBohDA[S(aMT.[G,OFS4"> <field name="VAR" id="uIH]RFlkkm@Km41QGhaA">SireneAn</field> <value name="VALUE"> <block type="text_join" id="TdNQ,}|q`gFxvZLwy$*8"> <mutation items="7"></mutation> <value name="ADD0"> <block type="text" id="Mb/%XCjvWonC$fO/?ls`"> <field name="TEXT">{"warning": {"mode": "</field> </block> </value> <value name="ADD1"> <block type="get_value" id="e(uG!N{D9[LxaAxPY+/d"> <field name="ATTR">val</field> <field name="OID">zigbee.3.00124b0008b76e21.mode</field> </block> </value> <value name="ADD2"> <block type="text" id="hbhm0T96nEr1AiU1OVhS"> <field name="TEXT">", "level": "</field> </block> </value> <value name="ADD3"> <block type="get_value" id="12-`Kc(])8|d-cj2HOM*"> <field name="ATTR">val</field> <field name="OID">zigbee.3.00124b0008b76e21.level</field> </block> </value> <value name="ADD4"> <block type="text" id="/A0Py]A=1U~]{8!)~jt+"> <field name="TEXT">", "strobe":</field> </block> </value> <value name="ADD5"> <block type="get_value" id="`lYLjrPFw@H#P7fCt0Q1"> <field name="ATTR">val</field> <field name="OID">zigbee.3.00124b0008b76e21.strobe</field> </block> </value> <value name="ADD6"> <block type="text" id="sM|q$*Tl-j)D%KxM52GM"> <field name="TEXT">,"duration": 120}}</field> </block> </value> </block> </value> <next> <block type="control" id="x%TnFrN(xRxN.6Lc==bc"> <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="true"></mutation> <field name="OID">zigbee.3.00124b0008b76e21.send_payload</field> <field name="WITH_DELAY">TRUE</field> <field name="DELAY_MS">3</field> <field name="UNIT">sec</field> <field name="CLEAR_RUNNING">FALSE</field> <value name="VALUE"> <block type="variables_get" id="~Jp=F]w~yx=9N~*MSM*z"> <field name="VAR" id="uIH]RFlkkm@Km41QGhaA">SireneAn</field> </block> </value> </block> </next> </block> </next> </block> </next> </block> </statement> </block> </statement> </block> </xml>Viele Grüße aus Zwickau und mal schauen ob es in einer Woche noch geht.
René
