UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[legro]

@asgothian

Nein, das habe ich noch nicht versucht.

Leider habe ich schon wieder vergessen, wie das geht. In meinem Alter gilt die Regel: "Ich kann mir zwar schlecht etwas merken, aber vergessen kann ich gut". Ich muss mich erneut damit beschäftigen.

Gibt es kein Archiv, in dem die alten Versionen abgelegt werden?

[Thomas Braun]

@legro sagte in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:

Gibt es kein Archiv, in dem die alten Versionen abgelegt werden?

Doch. Im github...

[legro]

@thomas-braun said in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:

Doch. Im github...

Könntest du mir bitte vielleicht sagen, wo (ggf. Link) ich das Ganze finden kann?

[Thomas Braun]

@legro Den Link von arteck in den Adapter-Installationen (ggf. Experten-Ansicht einschalten) angeben.

[legro]

@arteck said in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:

.. mecker aber dann nicht dass der coordinator nicht mehr geht.. da ist so viel geändert worden.. kein plan ob das Netz danach noch geht

Das sind ja tolle Aussichten.

Naiverweise dachte ich, 1.6.0 drauf und alles ist gut, wenn's doch damit funktionierte. Was vergesse ich denn dabei zu bedenken?

Und nochmals zu meinem hier geschilderten Problem, das Ganze zu installieren ..

• Sichern der SSD mittels ApplePiBaker
• Icon Katze klicken und ..
• .. in dem sich öffnenden Dialog das Register Benutzerdefiniert selektieren und schließlich ..
• .. unter Adapter auswählen den Link eingeben
• Ggf.: Wenn's schief geht, die SSD mit ApplePiBaker wiederherstellen
  

[Thomas Braun]

@legro

Dort unter 'Benutzerdefiniert'
den Link einkopieren.

[legro]

@thomas-braun said in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:

@legro

Dort unter 'Benutzerdefiniert' den Link einkopieren.

Vielen Dank für deinen Hinweis. Ich habe mein Vorgehen oben angepasst.

[legro]

@arteck said in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:

https://github.com/ioBroker/ioBroker.zigbee/tarball/71ae960c4a0353018024f87fe05d8ea6e958a9c6

mecker aber dann nicht dass der coordinator nicht mehr geht.. da ist so viel geändert worden.. kein plan ob das Netz danach noch geht

Welche Version ist das? Die 1.6.0 oder die von Axel angepasste?

Ich habe nun mein System mittels ApplePiBaker gesichert und bin bereit das ein oder andere zu testen.

[legro]

@Asgothian

Leider bekomme ich deine Version nicht installiert. Es wird angemeckert, dass ..

NPM version: 6.14.15
Installing ... (System call)
ERROR: Process exited with code 33

.. installiert werden soll. Ich habe erst vor ein paar Tagen nodejs aktualisiert und dabei sollte doch auch wohl npm auf die neue Version umgestellt worden sein. Oder sehe ich das falsch?

Im Terminal habe ich mir daher zur Sicherheit die aktuell bei mir installierten Versionen angeschaut. Hier das Ergebnis ..

[Asgothian]

@legro Du musst schon die vollständige Fehlermeldung des Installvorgangs posten. Im Zweifelsfall im Dialog in dem du den Adapter installierst den haken für "mehr info" mit setzen.

A.

[legro]

@asgothian said in Zigbee 1.6.6 Update kein Ansteuern der Aussensirene:

@legro Du musst schon die vollständige Fehlermeldung des Installvorgangs posten.

Ich habe also das Ganze nochmals zu installieren versucht, um die von dir gewünschten Fehlermeldungen zu erhalten. Und siehe da, es scheint alles funktioniert zu haben.

Allerdings wird mir nach wie vor die Version 1.6.16 angezeigt, obwohl während des Installationsprozesses mir 1.6.17 angezeigt wurde.

Kann ich irgendwie überprüfen, ob ich die gewünschte Version jetzt in meinem System habe?

[Asgothian]

@legro

Bitte den Adapter neu starten und im log nach der exakt installierten Version des Adapters schauen - sie wird im Log gemeldet (info: zigbee.0 (5413) starting. Version 1.6.16 in /opt/iobroker/node_modules/iobroker.zigbee, node: v12.22.8, js-controller: 3.3.22)

A.

[legro]

@asgothian

Vielen Dank.

Der ZigBee-Adapter wurde ja schon direkt nach seiner Neuinstallation gestartet. Im Protokoll ist in der Tat die Version 1.6.17 vermerkt. Insoweit scheint das Ganze geklappt zu haben.

Nun werde ich mich mit einmal daran versuchen, den neuen Datenpunkt send_playload via Blockly anzusteuern.

[legro]

@asgothian

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!:blush:

[Asgothian]

@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.

[legro]

@asgothian

Vielen Dank für dein Hilfe! Gute Arbeit! Du hast natürlich recht: Erst mal die Pflicht, dann die Kür.:smiley:

Endlich können wir unser Alarmsystem für Rauch, Einbruch, Wasser und Gas wieder in Betrieb setzen.:+1: :smiley:

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.

[Asgothian]

@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.

[legro]

@asgothian

Wenn ich die Arbeiten und Tests (hoffentlich) erfolgreich abgeschlossen bekomme, kann ich gerne eine kleine Dokumentation über Verwendung und Auswirkung der vielen Parameter erstellen.

[legro]

@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.

[legro]

@Asgothian

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?