In meinem vorhergehenden Beitrag habe ich darüber berichtet warum ich die Shellys als die Top-Produkte im Smarthome-Bereich betrachte. Hier Soll es nun darum gehen, die Geräte in eine Bestehende Infrastruktur mit der CCU / RaspberryMatic als Zentrale einzubinden.
Natürlich reicht es im Prinzip aus, wenn man die Shellys mit dem Smartphone – sei es über das integrierte WEB-Interface und / oder die HTTP API – fernbedienen kann.
Das widerspricht allerdings dem Gedanken der Automation im Haus oder Büro. Man will ja ggf. auch z.B. bestimmte Licht-Stimmungen mit dem HomeMatic HM-PB-4Dis-WM-2 Funk-Display steuern, wenn man das Smartphone gerade mal nicht zur Hand hat.
Jens Maus hat uns mit dem CUxD ein Werkzeug zur Einbindung vielerlei Fremd-Technik in die HomeMatic-Welt an die Hand gegeben. Wie der CUxD grundsätzlich eingerichtet wird, soll hier nicht das Thema sein. Hier sind die Suchmaschinen eure Freunde 😉
Diesen Beitrag nutze ich selbst – quasi als Notizzettel – wenn mal Erinnerungslücken auftreten ;-).
Was mit dieser Vorgehensweise auf jeden Fall geht:
- Ein- und Ausschalten aller Shellys, welche die Switch-Funktion unterstützen. Also auch die Plugs.
- Ggf. Einstellen fester Werte (Z.B. Festlegen eines Dim-Level?) mittels der HTTP API der Shellys. Hier wären allerdings Experimente mit anderen CUxD-Geräten eventuell sinnvoll.
Was mit etwas mehr Experimentierfreudigkeit lösbar erscheint:
Hier liste ich denkbare Lösungsansätze auf (Ungetestet, einfach ein paar Iddeen!).
Es ist die eigene Kreativität gefragt:
- Festlegen des Dim-Levels eines Shelly Dimmers mittels kurzem Tastendruck auf einem CUxD-Gerätes des Typ “(40) 16 Kanal Universalsteuerung” und Control-Typ “Dimmer” (CMD_EXEC aktivieren und nutzen, “curl” nicht vergessen 😉 ). URLs z.B.: “http://[IPAdresseDesShelly]/light/0?dim=up” bzw. “http://[IPAdresseDesShelly]/light/0?dim=down”
Zum Ein- / Ausschalten verwendet man dann den langen Tastendruck und kann hierzu z.B. die URLs http://[IPAdresseDesShelly]/light/0?turn=on bzw. http://[IPAdresseDesShelly]/light/0?turn=off verwenden.
- Festlegen eines Dim-Levels des Shelly Dimmers mit Hilfe einer Systemvariablen und einem Zentralen-Programms und Script auf der CCU. Shelly-URL “http://[IPAdresseDesShelly]/light/0?brightness=[WertAusDerSystemvariablen]” (Deutlich fortgeschritteneres Wissen über Scripting und Programme auf der CCU nötig!)
- In ähnlicher Form können sehr wahrscheinlich z.B. auch die einzelnen Farb-Werte eines Shelly RGBW2 mittels mehrerer Taster eingestellt werden
- Auch das Auslesen der Energie-Werte eines Shelly 1 PM ist mit Fortgeschrittenen-Wissen denkbar
Mit Sicherheit sind noch einige Möglichkeiten mehr denkbar, vielleicht habt Ihr ja auch ein paar Iddeen.
Nachfolgend geht es an die Einrichtung:
Schritt 1: Erzeugen des /der benötigten CUxD-Geräte(s)
In meinem Szenario steuere ich mehrere Shelly One über die verschiedenen Kanäle des CUxD-Gerätes. Daher benenne ich das Gerät zur Gedankenstütze gleich mit den Host-Teilen der IPv4-Addressen. Der Geräte-Name und die Namen der einzelnen Kanäle lassen sich im Nachgang auch über das WEB-Interface der CCU noch ändern.
Die CUxD-Admin-Seite öffnet man über die Systemsteuerung der CCU.
Sobald die Admin-Seite des CUxD geöffnet ist und man auf “Geräte” geklickt hat, erscheint auf der linken Seite bereits eine Auswahlliste mit verschiedenen Geräten.
Hier Wählt man ein Gerät des Typ “(28) System” aus und die Funktion “Exec”, das Geräte-Icon ist im Prinzip egal, als Contorl nimmt man “Schalter”. Nach einem Klick auf “Gerät auf CCU erzeugen!” landet dieses im Geräte-Posteingang der CCU:
Nachdem man das frisch erzeugte Gerät im Posteingang bestätigt hat geht es zu:
Schritt 2: Eintragen der Befehle zum Ein- / Ausschalten mittels der URLs
In den Geräte-Einstellungen der CCU findet sich unser CUxD-Gerät wieder. Zum Belegen und Bearbeiten der jeweiligen Kanalparameter kann man entweder in der Zeile des Gerätes selbst, oder in der jeweiligen Zeile des Kanals rechtes auf “Einstellen” klicken”:
In den Einstellungen eines Kanals legt man unter “SWITCH|CMD_SHORT” den Ausschaltbefehl für einen der Shellys fest, unter “SWITCH|CMD_LONG” den Einschaltbefehl. (Achtung, die URL und die IP-Adresse des Shellys steckt im Befehl, wer hier direkt “http://xyz” einträgt, kommt nicht zum Ziel!):
Die kompletten Einträge setzen sich aus dem Befehl und der URL des Shellys zusammen. Es ist zu beachten, dass wir die URL auch gleich “encodiert” verwenden, also das Gleichheitszeichen durch “~3d” ersetzen. Im Browser wäre die URL zum Ausschalten wie folgt zu verwenden:
http://[IPAdresseDesShelly]/relay/0?turn=off
Wir brauchen zum Ausschalten im Feld “SWITCH|CMD_SHORT” den Wert:
/usr/local/addons/cuxd/curl -s http://[IPAdresseDesShelly]/relay/0?turn~3doff
und zum Einschalten im Feld “SWITCH|CMD_LONG”:
/usr/local/addons/cuxd/curl -s http://[IPAdresseDesShelly]/relay/0?turn~3don
Wenn wir diese beiden Werte eingetragen und übernommen haben, können wir einen Shelly schon über die CCU bedienen. Nach einem Test können wir jetzt die restlichen Shellys genau so einrichten. Der Bequemlichkeit halber verwende ich einen Text-Editor und bereite mir die URLs alle schon mal mit den verschiedenen IP-Adressen vor, dann spare ich mir beim Eintragen in die CCU das Nachdenken und arbeite der Reihe nach nur noch stumpf per copy/paste ab.
Schritt 3: Rückmeldung des Shelly an das CUxD-Gerät
Unter “I/O URL actions” bieten die Shellys die Möglichkeit die Rückmeldung an den CUxD (oder ach einen anderen x-beliebigen Deamon mit WEB-Interface) zu realisieren:
Wichtig ist, die sog. Action-URLs für den Ausgang zu verwenden, wir möchten ja der CCU / dem CUxD das Ergbnis des Schaltvorgangs mitteilen.
Zunächst ist die URL für “OUTPUT SWITCHED ON URL” mit “Enabled” zu aktivieren und dann einzutragen. Mit “SAVE” speichen wir die URL im Shelly.
Auch hier ist zu beachten, die URL gleich “encodiert” einzutragen. So wird aus dem Apostroph ‘[NameDesKanals]’ dann %27[NameDesKanals]%27.
Zum setzen des Wertes für “Ein” verwenden wir die 1:
http://[IPAdresseDerCCU]:8181/cuxd.exe?ret=dom.GetObject(%27[NameDesKanals]%27).State(1)
Bei “OUTPUT SWITCHED OFF URL” verwenden wir nach Aktivierung die Null:
http://[IPAdresseDerCCU]:8181/cuxd.exe?ret=dom.GetObject(%27[NameDesKanals]%27).State(0)
und speichern wieder.
Wenn wir die Kanäle nicht umbenannt haben, wird auch “[NameDesGeraetes]:Nummer” akzeptiert. –> Also kein Problem!
Das war’s auch schon!
Wenn jetzt der Shelly über den Schalter-Eingang oder auch den ioBroker bedient wird, bekommt die CCU den aktuellen Status übermittelt und wir können damit auch in Zentralen-Programmen arbeiten.
Hinweis bei schlechtem WLAN-Empfang:
Einer meiner Shellys liegt etwas ungünstig und hat deshalb keinen sonderlich guten WLAN-Empfang. Interessanterweise funktioniert das Steuern des Shelly und die Kommunikation mit dem IoBroker-Adapter einwandfrei, ABER:
Da es anscheinend beim Auswerten der HTTP-Antwort von CCU / CUxD zu Problemen kommt, haut der Shelly den Aufruf einige Male raus, was zu einem “unschönen” Verhalten führt und der Zustand auf der CCU auch einige Male hin und her toggelt. Da der ioBroker sowieso 24/7 am werkeln ist und den Zustand des Shelly-Ausgangs zuverlässig kennt, habe ich das kurzerhand als “quick and dirty workaround” mit einem Stück Javascript im IoBroker für diesen kleinen Racker gelöst:
on({id: "shelly.0.SHSW-1#[IDDesShelly]#1.Relay0.Switch"}, function (obj) {
/*
Shelly-Workaround schlechter WLAN-Empfang
Keine Fehlerbehandlung, wenn der Request fehschlaegt ist mir das egal.
Ich will ja nicht x Mal versuchen den Status auf der CCU zu setzen
*/
if (obj.state.val == true){
var url = 'http://[IPAdresseDerCCU]:8181/cuxd.exe?ret=dom.GetObject(%27[NameDesKanals]%27).State(1)';
} else {
var url = 'http://[IPAdresseDerCCU]:8181/cuxd.exe?ret=dom.GetObject(%27[NameDesKanals]%27).State(0)';
}
request(url, function (err, state, body){
});
});