coiot-control: Shellys (RBGW2, Bulb & Bulb RGBW) per Coap steuern

Seven of Nine

Hallöchen,

wer die Release-Notes zur Firmware 1.9 aufmerksam verfolgt hat wird vermutlich über das Feature "coap light control" gestolpert sein und sich fragen was das ist.. damit lassen sich verschiedene Shellys via Coap steuern..

Funktionell klappt das beim RGBW2, bei der alten (Color) Bulb und bei der neuen SHelly Bulb RGBW.

Bevor die Funktion nutzbar ist, muss sie zunächst im Shelly aktiviiert werden. Das geht nur über die Weboberfläche, der JHaken "Listen to Coap for color change commands" befindet sich wie die MQTT Einstellungen unter Advanced - Developer Settings.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

ich hatte im Rahmen des QA Testings ein kleines Programm gebaut, mit der sich die Funktion testen lässt..

Funktionsweise:

Code

./coiot-control -ip 192.168.178.70 -payload 255,255,0,0,100,10,1000,1

Erläuterung der Parameter:

-ip IP-Adresse, steuert einen einzelnen Shelly an

-payload damit kontrolliert man das Verhalten der Werte: ROT, GRÜN, BLAU, WEISS, GAIN, BRIGHTNESS, TRANSITIONTIME, ON_OFF

- rot, grün, blau und weiss unterstützten Werte von 0 bis 255 (RGB Farben)

- gain steuert die Helligkeit der Farben

- brightness steuert (theoretisch) die Helligkeit der weißen Kanäle beim RGBW2, wird hier aber nicht genutzt.

- transitiontime steuert die Zeit in Millisekunden für einen Übergang von einem Zustand zu einem anderen.

- on/off 1 für an, oder 0 für aus

Grundsätzlich lässt sich alles davon zwar auch per REST-API steuern, hat allerdings einen Vorteil.

wenn man die IP einfach weglässt, wird das Coap-Kommando an die Multicast-Adresse geschickt und ALLE Shellys, bei denen die Funktion aktiviert wurde, schalten gleichzeitig.

in Kombination mit einem einfachen Shellscript kann man damit seine eigenen Farbabläufe zusammen bauen:

Code

./coiot-control -ip 192.168.178.186 -payload 255,0,0,0,100,10,2000,1
sleep 2
./coiot-control -ip 192.168.178.186 -payload 255,0,0,0,1,10,2000,1
sleep 2
./coiot-control -ip 192.168.178.186 -payload 255,0,0,0,100,10,2000,1
sleep 2
./coiot-control -ip 192.168.178.186 -payload 255,0,0,0,1,10,2000,1
sleep 2
./coiot-control -ip 192.168.178.186 -payload 255,0,0,0,100,10,2000,1
sleep 2
./coiot-control -ip 192.168.178.186 -payload 255,0,0,0,100,10,2000,0

Alles anzeigen

In der ZIP-Datei oben befinden sich Binarys für Linux und Windows (64bit)
Download: http://archive.shelly-faq.de/coiot-control.zip

Das Tool darf ohne meine ausdrückliche Genehmigung weder gewerblich genutzt werden noch weiter verbreitet werden!

Viel Spaß beim Testen Vielleicht kann es ja tatsächlich jemand sinnvoll gebrauchen.

Domingo

Zitat von Seven of Nine

Grundsätzlich lässt sich alles davon zwar auch per REST-API steuern, hat allerdings einen Vorteil.

wenn man die IP einfach weglässt, wird das Coap-Kommando an die Multicast-Adresse geschickt und ALLE Shellys, bei denen die Funktion aktiviert wurde, schalten gleichzeitig

Eine kurze Frage dazu:

Allterco plant ja den Support für Multicast einzustellen. Da ich meine Shellys in HomeKit in der aktuellen FW v1.10.1 aus noch ungeklärten Gründen nur noch in Unicast ansprechen kann, hab ich bei allen devices schon auf unicast gewechselt. Bedeutet der Wechsel auf unicast auch, dass dein genannter Vorteil von „Listen CoAp for color change commands“ ALLE Shellys gleichzeitig steuern zu können wegfällt? Oder hören die Shellys selbst weiterhin auf Multicast Traffic auch wenn sie einen unicast Peer eingetragen haben. Dann würde der eingetragene Peer nur für den ausgehenden Traffic der Shellys gelten. Hast du da etwas mehr Durchblick als ich?

Whity

du kannst anstatt der unicast adresse auch "mcast" reinschreiben, dann funktionieren sie auch wieder im multicast

Seven of Nine

Zitat von Domingo

Bedeutet der Wechsel auf unicast auch, dass dein genannter Vorteil von „Listen CoAp for color change commands“ ALLE Shellys gleichzeitig steuern zu können wegfällt?

hab es gerade mal getestet, das funktioniert nur, wenn auch im Shelly "mcast" als Ziel eingetragen ist..

Sobald man den Shelly auf Unicast umstellt, werden gar keine Befehle mehr über CoIoT entgegen genommen..

Domingo

Zitat von Seven of Nine

hab es gerade mal getestet, das funktioniert nur, wenn auch im Shelly "mcast" als Ziel eingetragen ist..
Sobald man den Shelly auf Unicast umstellt, werden gar keine Befehle mehr über CoIoT entgegen genommen..

Könnte tatsächlich sein, dass die Shellys im unicast Mode nur noch ihren eigenen State per CoAP an den Peer senden können.

Die andere Richtung — Kommandos vom Peer an den Shelly — dann aber zwingend per HTTP/REST erfolgen muss und CoAP da nicht mehr klappt. Das wird dann wohl auch Standard werden, denn Shelly wird den multicast Support in einer der nächsten FW Versionen definitiv komplett einstellen.

Entweder ist dann „Listen CoAp for color change commands“ useless oder es soll mit dieser Einstellung für die RGB Produkte weiterhin möglich gemacht werden, per CoAP zumindest Farbbefehle senden zu können.

Wundert mich allerdings, dass dann die aktuelle Implementierung im Zusammenspiel mit diesem CoAP Listen und HA im unicast Mode gar nicht mehr läuft, wie du es sagst.

Eigentlich soll ja gerade HA mehr oder weniger nativ unterstützt sein. Oder es kommt noch ein Update im HA Plugin sobald multicast im Shelly komplett gedroppt wurde.

So aktuell macht es ja wenig Sinn, wenn das angestrebte unicast alles lahmlegt.

Man wird sehen. Bin gespannt.