Einbindung der Ubiquiti mPower Steckdosenleisten

[mweb]

Hallo zusammen. Ich habe meine mFi mPower PRO erhalten und will mich jetzt mit der Integration in OH beschäftigen.
Was ich vorgefunden habe:

• SSH Zugang
• Eine REST API
• CGI's sind read only

Die Rest API funktioniert prima.

curl -X POST -k -d "username=ubnt&password=ubnt" -b "AIROS_SESSIONID=01234567890123456789012345678901" https://192.168.0.121/login.cgi
curl -k -b "AIROS_SESSIONID=01234567890123456789012345678901" https://192.168.0.121/sensors/6/voltage
curl -X POST -k -d "output=0" -b "AIROS_SESSIONID=01234567890123456789012345678901" https://192.168.0.121/sensors/1
curl -X POST -k -d "output=1" -b "AIROS_SESSIONID=01234567890123456789012345678901" https://192.168.0.121/sensors/1
curl -k -b "AIROS_SESSIONID=01234567890123456789012345678901" https://192.168.0.121/logout.cgi

Leider gibt es keine HTTP basic auth. Man muss ein login vorher ausführen.


Per SSH kann man eigentlich auch alles machen (Schalten, messen)

MF.v2.1.4# cat /proc/power/relay6
1

Frage an Euch: Wie würdet Ihr vorgehen?

• Ein Binding schreiben, welches per HTTP einen Login (und dann POSTs und GETs macht)
• Ein Binding schreiben, welches per SSH einen Login macht (und dann Scripte aufruft)

Danke und Grüße

[Spectre]

Definitiv Variante 1. Das hat den Vorteil das die gesamte Logik an einem Ort liegt und nicht verteilt im Netzwerk.

Die Geräte würde ich so Dumm wie möglich halten - das erspart dir einiges an Pflegeaufwand und du kannst vorhandene Skripte wiederverwenden wenn Du Dir eine zweite, dritte oder mehr Leisten holst.

[EDIT]
Hast Du eine Dokumentation für die REST-Api gefunden?
[/EDIT]

[EDIT2]
Was meinst Du mit "CGI's sind read only"?

Können kleinere Bash-Scripte auf der Leiste gespeichert werden?
[/EDIT2]

[EDIT3]
In welchem Format kommen die Daten aus der REST-API denn zurück? Plain? XML? JSON?

Kannst Du mal ein Screenshot von nem Request machen?
[/EDIT3]

[mweb]

Definitiv Variante 1. Das hat den Vorteil das die gesamte Logik an einem Ort liegt und nicht verteilt im Netzwerk.

Die Geräte würde ich so Dumm wie möglich halten - das erspart dir einiges an Pflegeaufwand und du kannst vorhandene Skripte wiederverwenden wenn Du Dir eine zweite, dritte oder mehr Leisten holst.

Ich tendiere gerade eher zu SSH. Weil:
* Die Android App macht das auch
* Es gibt eine perl und pyhton Lösung die auch SSH nutzt
* Die HTTP Session stirbt nach ein paar Minuten
* Die Zeit für Login/Datenholen/Logout wird wohl richtung 5 Sekunden gehen
* mittels offener SSH session kann man nahezu Echtzeit "pollen"

Hast Du eine Dokumentation für die REST-Api gefunden?

mPower, mFi Switch and mFi In-Wall Outlet HTTP API - Ubiquiti Networks Community

Was meinst Du mit "CGI's sind read only"?

Können kleinere Bash-Scripte auf der Leiste gespeichert werden?

Ich habe noch keine Möglichkeit gefunden Scripte darauf zu speichern oder zu manipulieren.

In welchem Format kommen die Daten aus der REST-API denn zurück? Plain? XML? JSON?

Kannst Du mal ein Screenshot von nem Request machen?

[michaeljk]

Meine 6er Steckdosenleiste wird auch am Freitag eintreffen. Per SSH scheint eine Steuerung problemlos möglich, da man alles über das Proc-Dateisystem auslesen/setzen kann.

Wie Spectre bereits erwähnt hat, würde ich die Steckdose nur minimal einrichten (z.B. eigene Zugangsdaten zur Absicherung setzen) und sonst keinerlei Konfiguration über die eingebaute Weboberfläche vornehmen. Anschliessend sollte man schauen, welche API's bereits zur Verfügung stehen - das Polling und Schalten der Steckdosen per SSH ist in jedem Fall einfach umzusetzen, über HTTP könnte das aber noch einfacher sein (sofern dort auch alle Funktionen zur Verfügung gestellt werden).

Edit:
Eben deinen Screenshot noch gesehen, das ist eine einfache JSON-Rückgabe. Damit sollte man doch bereits einiges machen können, oder?

[Spectre]

Danke für die Infos. Besonders begeistert bin ich von dem standardisiertem Output (JSON). Alleine deswegen würde ich schon die REST-Api nutzen. Standardisierte Sachen möchte man unbedingt verwenden, denn sie ändern sich nicht wenn irgendwo Updates eingespielt werden.

Werde mir mal die Doku anschauen und dann gleich mal 3 Leisten ordern

[mweb]

Ok, Ihr schlagt beide HTTP vor.
Wie würdet Ihr denn das Login coden?

• Das Binding macht beim starten ein POST auf Login.
• Dann fängt es an zu pollen und ggfs die Dosen ein/auszuschalten.
• Wenn irgendwas schief geht (weil die Session abgelaufen ist) macht es ein erneutes Login.

So in etwa?

Die Dauer zum Auslesen des JSON ist zwischen 1 und 2,5 Sekunden. Wäre das für Euch ok?

Will mich jemand beim Coden unterstützen?

Sonst noch Argumente SSH vs HTTP?

Bezüglich Einrichtung: da muss man nicht viel machen. Firmware aktualisieren, Passwort ändern, ggfs WIFI ausschalten und eine statische IP setzen.

[Spectre]

Naja, hast Du nicht vor regelmässig nach dem Stromverbrauch zu fragen? Wenn ja, dann bräuchtest Du nur einmal einloggen und jeder weitere Pull verlängert die Session... Ansonsten, wie Du bereits meintest, wenn etwas schief läuft einfach nochmal autorisieren.

Willst Du echt jede Sekunde neue Werte von dem Gerät ziehen? Ich hätte da ehr so an min 5 sek. Intervall gedacht. Andernfalls müsste man prüfen wie sehr das die Hardware belastet jede Sekunde angefragt zu werden.

Bzw. oder mal ins System schauen und gucken wie der Webserver die Daten rausholt. Wenn der Webserver auch nur in /proc/ nachschaut dann dürfte imho ein 1 sek. Intervall kein Problem darstellen.

Vergiss SSH für solche Spielereien, das hat für solche Sachen einen ziemlichen overhead.

Folgendes wäre jedoch eine Option:

Per HTTP werden alle Daten gepullt. Hierfür kann dann ein read-only User benutzt werden - da ist es auch nicht schlimm das die Credentials Plain durch das Netzwerk sausen. Wenn es denn ums schalten geht, was ja eigentlich nicht im sekunden-takt passiert, dann kann dafür SSH genutzt werden. Hier sind die credentials dann verschlüsselt im Netzwerk. Im Idealfall kann hier sogar mit SSH-Keys gearbeitet werden, was die ganze Sache um einiges Sicherer macht.

Bietet Die Steckleiste HTTPS?

[michaeljk]

Standardisierte Sachen möchte man unbedingt verwenden, denn sie ändern sich nicht wenn irgendwo Updates eingespielt werden.

Hierzu sei aber die Notiz bei dem API-Link zu bemerken:

"This API isn’t formally supported. While we don’t intend to change it, it’s not necessarily fully regression tested on each release. So beware."

Es könnten sich also durchaus Änderungen in der Zukunft ergeben - da die Abfrage/Rückgabe aber relativ einfach durchzuführen sind, kann man diese notfalls auch leicht wieder ändern.

Ein direktes Polling per SSH dürfte allerdings auch nicht allzu aufwendig sein, denn schliesslich genügt ein Login um alle Ports auszulesen. Mittels PubKey hat man direkt eine verschlüsselte Verbindung, aber man muss natürlich die Steckdosenleiste erstmal dafür konfigurieren, dies läßt sich vermeiden wenn man die HTTP-API nutzt. Daher würde ich auch letztere bevorzugen.

Werde mir mal die Doku anschauen und dann gleich mal 3 Leisten ordern

Die mPower sind in Sachen Preis/Leistung richtig gut! Es gibt noch die Energenie-Leisten mit 6 Ports, aber davon sind nur 4 schaltbar und eine Leistungsmessung ist dort ebenfalls nicht verfügbar. Richtig klasse wäre natürlich, wenn man ein eigenes Binding für die mPower Steckdosenleisten zur Einbindung in openHAB hätte, anstatt über HTTP- oder Exec-Bindung zu gehen. Ich helfe beim Coden natürlich gerne - bis Freitag vertreibe ich mir aber noch die Zeit mit dem Lesen der API-Beschreibung

[Spectre]

...

Die mPower sind in Sachen Preis/Leistung richtig gut! Es gibt noch die Energenie-Leisten mit 6 Ports, aber davon sind nur 4 schaltbar und eine Leistungsmessung ist dort ebenfalls nicht verfügbar. Richtig klasse wäre natürlich, wenn man ein eigenes Binding für die mPower Steckdosenleisten zur Einbindung in openHAB hätte, anstatt über HTTP- oder Exec-Bindung zu gehen. Ich helfe beim Coden natürlich gerne - bis Freitag vertreibe ich mir aber noch die Zeit mit dem Lesen der API-Beschreibung

Huh? Die mPower Pro mit den 6 Ports ist doch komplett Schaltbar und Messbar?!

[michaeljk]

Huh? Die mPower Pro mit den 6 Ports ist doch komplett Schaltbar und Messbar?!

Die mPower ja, aber die "Energenie"-Leisten nicht (für diese gibt es aber bereits ein openHAB-Binding)

[mweb]

Hierzu sei aber die Notiz bei dem API-Link zu bemerken:

"This API isn’t formally supported. While we don’t intend to change it, it’s not necessarily fully regression tested on each release. So beware."

Richtig. Allerdings würde ich denselben Aufruf nutzen, der auch im Webclient verwendet wird. Große Änderungen wird es nicht geben. Und wenn dann hoffentlich zuerst eine bessere Authentifizierung.

Mittels PubKey hat man direkt eine verschlüsselte Verbindung, aber man muss natürlich die Steckdosenleiste erstmal dafür konfigurieren, dies läßt sich vermeiden wenn man die HTTP-API nutzt. Daher würde ich auch letztere bevorzugen.

Ich wüßte jetzt nicht wie genau ich die Keys auf dem Server einrichten soll (read only FS). Ich bezweifele dass das geht.

wenn man ein eigenes Binding für die mPower Steckdosenleisten zur Einbindung in openHAB hätte, anstatt über HTTP- oder Exec-Bindung zu gehen. Ich helfe beim Coden natürlich gerne - bis Freitag vertreibe ich mir aber noch die Zeit mit dem Lesen der API-Beschreibung

Ja, klar. Was denkst Du denn. Da kommt ein ordentliches Bindung her!

Je nach Kopfschmerz mache ich mich morgen mal dran ans Coding.

Ich schlage vor die erste Version macht HTTP mit dem Read-only user.
Dann schauen wir ob wir für das Senden HTTPS (ja, das ist unterstützt!) oder SSH benutzen.

Kommt gut ins neue Jahr!

[mweb]

Kurzer Status: Habe noch was neues entdeckt: Der aktuelle webclient nutzt websockets. Das habe ich im Lesemodus mal ganz grob im Binding implementiert und siehe da...funzt

16:13:02.025 DEBUG o.o.b.m.i.WebSocketListener[:45] - []: Message received: { "v": 1, "sensors": [ { "index": "power6",
"port": 6, "output": 1, "power": 1.055221, "current": 0.020375, "voltage": 234.977000, "powerfactor": 0.220405, "energy"
: 6.250000 } ] }

[mweb]

So...funzt schon mal grob.

Der speed ist beachtlich! Schalten via websocket ohne merkliche Verzögerung. Das Auslesen dauert 1-2 Sekunden.

[michaeljk]

Coole Sache... hast du auch schon ein wenig Code mit dem man morgen testen kann, z.B. auf GitHub?

[mweb]

sorry, brauche noch ein paar Stunden um es halbwegs testbar zu machen. Noch ein bisschen Geduld bitte