Einbindung der Ubiquiti mPower Steckdosenleisten

[mweb]

So, bitte schön: https://github.com/magcode/openhab/t...binding.mpower

ACHTUNG:

Das ist nur eine erste alpha zum testen. Nicht "produktiv" einsetzen.

Was dringend gemacht werden muss ist eine Reduktion der Updates auf eine Minute (oder so). Aktuell pumpt er die Daten direkt und ohne Unterbrechung in den OH Eventbus...

[michaeljk]

Danke, werde ich mir am Wochenende mal ansehen - meine Steckdosenleiste kam auch heute wie geplant an

Wenn ich es richtig gesehen habe, dann hast du bisher auch noch nicht die Möglichkeit zur Ansteuerung von mehreren Steckdosenleisten eingeplant, oder?

[michaeljk]

Hallo,

ich habe zwischenzeitlich das System auf der mPower Steckdosenleiste genauer betrachtet. Zunächst einmal sollte man die Firmware prüfen (meine wurde mit 2.0.4 ausgeliefert). Unter der folgenden URL kann man die neueste Firmware herunterladen:

Ubiquiti Networks - Downloads

Zum Upgrade selbst gibt es hier weitere Informationen, vor allem wenn man eine Firmware < 2.0 noch hat und das ganze per SSH einspielen muss:

https://community.ubnt.com/t5/mFi-Fr...ly/ta-p/485311

In meinem Fall war zwar bereits eine Version > 2.0 installiert, aber ich hatte keinen Menüpunkt in der Weboberfläche für das Firmware-Update auffinden können. Die URL muss manuell angesteuert werden:

http://<IP>/system.cgi

Unten links kann man nun den Button "Firmware" anklicken. Default Login für die Weboberfläche ist im übrigen ubnt/ubnt (User/Passwort). In der aktuellen Version 2.1.4 kamen nette Sachen hinzu, z.B. eigene Timer zum aktivieren/deaktivieren von Ports, einen "Vacation"-Mode und auch Port Mirroring sowie ein automatisches Power-Off, wenn bestimmte Werte erreicht/unterschritten werden. In Verbindung mit openHAB ist das natürlich weniger interessant - was man aber auf jedenfall konfigurieren sollte, ist ein eigener Systemaccount und Kennwort unter dem Menüpunkt "System". Diese Daten müssen später im openHAB-Binding verwendet werden. Weitere Änderungen sind nur dann notwendig, wenn man Wifi aktivieren möchte oder z.B. die LED ausgeschaltet bleiben soll.

Die Steckdosenleiste arbeitet mit einem Read-Only Root-Filesystem, alles in /tmp ist aber beschreibbar. Dort liegt unter anderem die Datei "system.cfg", welche mit "vi" per SSH bearbeitet werden kann. Die Datei muss anschliessend in das Root-FS aufgenommen werden mit folgendem Befehl:

cfgmtd -f /tmp/system.cfg -w

Nach einem Reboot werden die neuen Einstellungen automatisch geladen. In der system.cfg lassen sich auch weitere User definieren, das Passwort kann per crypt-Befehl erzeugt werden:

php <<< '<?php echo crypt("my_password", "SL");'

Beim Booten blinkt die LED im übrigen Orange und bleibt dann auch in dieser Farbe stehen, sofern die Steckdosenleiste nicht mit einem Connector verbunden ist/wurde. Laut Anleitung leuchtet die LED blau, sobald ein erfolgreicher Connect stattfand, per SSH-Shell mit folgendem Befehl machbar:

echo 1 > /proc/led/status

Möglicherweise kann man das noch einbauen um einen visuellen Feedback für die korrekte Binding-Verbindung zu erhalten.


Was ich bisher noch nicht herausgefunden habe:

- Ist Wifi komplett abschaltbar? In der system.cfg läßt sich zwar ein "disabled" setzen, in der Weboberfläche ändert sich die Anzeige aber nicht. Ist die Standardeinstellung sicher, wenn man dort nichts einträgt - wird also kein Access-Point oder ähnliches ohne Kennwort erzeugt?


Grüsse,

Michael


Edit:
In der /tmp/system.cfg Datei gibt es den Wert "radio.status". Wenn dieser in der Konfiguration disabled wird:

radio.status=disabled

dann konfiguriert die Steckdosenleiste die Wifi-Devices (ath0 / wifi0) nicht mehr, somit ist WLAN komplett inaktiv.

[mweb]

Hallo,


In meinem Fall war zwar bereits eine Version > 2.0 installiert, aber ich hatte keinen Menüpunkt in der Weboberfläche für das Firmware-Update auffinden können. Die URL muss manuell angesteuert werden:

http://<IP>/system.cgi

Genau so habe ich es auch gemacht. Werde ich mal in die Doku aufnehmen. Danke.

anschliessend in das Root-FS aufgenommen werden mit folgendem Befehl:

cfgmtd -f /tmp/system.cfg -w

Geht auch mit "save" glaube ich.

Möglicherweise kann man das noch einbauen um einen visuellen Feedback für die korrekte Binding-Verbindung zu erhalten.

Aktuell habe ich im Binding keine SSH Verbindung. Deswegen ist das steuern der LEDs aktuell nicht möglich. Bei mir verschwindet das Dings eh hinterm Schrank, da brauch ich gar keine LED

In der /tmp/system.cfg Datei gibt es den Wert "radio.status". Wenn dieser in der Konfiguration disabled wird:

radio.status=disabled

dann konfiguriert die Steckdosenleiste die Wifi-Devices (ath0 / wifi0) nicht mehr, somit ist WLAN komplett inaktiv.

Sehr gut! Danke. Ich hatte es nicht hinbekommen.

[michaeljk]

Aktuell habe ich im Binding keine SSH Verbindung. Deswegen ist das steuern der LEDs aktuell nicht möglich. Bei mir verschwindet das Dings eh hinterm Schrank, da brauch ich gar keine LED

Die SSH-Verbindung würde sich wohl auch nur dann anbieten, wenn man weitere grundlegende Funktionen darüber steuern möchte - nur für die LED alleine ist das sicherlich zuviel Aufwand Ich werde meine Steckdosenleiste demnächst erstmal ordentlich an die Wand montieren und meinen Kabelsalat am Fernseher bereinigen, bevor ich die Softwareseitige Konfiguration anfange.

Mich würde eventuell auch noch die Funktionsweise des mFi Controllers interessieren, z.B. über welches Protokoll dort die Kommunikation mit den Endgeräten läuft. Möglicherweise könnte man so auch zukünftig ein eigenes Gateway oder Binding für alle unterstützten mFi Geräte bauen. Neben den Steckdosenleisten hätte man dann auch den Zugriff auf günstige Temperatursensoren und vieles mehr

[mweb]

Update fürs Binding:

* HTTPS/WSS unterstützt
* Update nur wenn sich Werte geändert haben
* sync des ON/OFF Status mit dem Webinterface/der App (allerdings nicht sofort, sondern erst nach refresh)
* refresh konfigurierbar
* mehrere Leisten (ungetestet)

[teichsta]

Hi,

So, bitte schön: https://github.com/magcode/openhab/t...binding.mpower

klasse!

Zur Info: Du könntest auch gerne eine Pull Request schicken, den Du dann einfach weiterpflegst. Im Grunde ist ein PR ja nur ein Branch aus Deinem Repo. Der Vorteil ist, dass der Code automatisch gebaut wird, was Dir die Distribution des Binaries vereinfacht.

Danke und Gruß,

Thomas E.-E.

[michaeljk]

Update fürs Binding:
* Update nur wenn sich Werte geändert haben
* refresh konfigurierbar

Kurze Rückfrage hierzu:
Die Voltage-Werte ändern sich sekündlich soweit ich dies auf der integrierten Weboberfläche gesehen habe - natürlich immer nur minimal, im Falle der EU-Steckerleisten aber immer um den Wert 230 Volt (+- 3-4 Volt). Möglicherweise könnte man hier also einige Updates zum openHAB-Bus einsparen.

Gleiches gilt für den aktuellen Energieverbrauch in Watt. Die Lastspitzen wird man auch durch geringe Poll-Intervalle nicht genau genug erfassen können, möglicherweise bietet sich hierfür ein Durchschnittswert der letzten x Sekunden/Minuten an? Die Alternative wäre den jeweiligen Wert in Realtime auszulesen, bietet openHAB hierfür überhaupt eine entsprechende Möglichkeit?

[mweb]

Kurze Rückfrage hierzu:
Die Voltage-Werte ändern sich sekündlich soweit ich dies auf der integrierten Weboberfläche gesehen habe - natürlich immer nur minimal, im Falle der EU-Steckerleisten aber immer um den Wert 230 Volt (+- 3-4 Volt). Möglicherweise könnte man hier also einige Updates zum openHAB-Bus einsparen.

Ja, guter Punkt. Da könnte man was einbauen. Magst Du einen Pull Request machen? Das sollte konfigurierbar sein (wir hoffen doch auf US-Kundschaft, oder? )
Ich selbst brauche eigentlich "Voltage" gar nicht. (Interessiert mich nicht wirklich wieviel Volt anliegen.) Ich werde dann einfach die Items nicht definieren und dann gibts auch keine Updates.

Gleiches gilt für den aktuellen Energieverbrauch in Watt. Die Lastspitzen wird man auch durch geringe Poll-Intervalle nicht genau genug erfassen können, möglicherweise bietet sich hierfür ein Durchschnittswert der letzten x Sekunden/Minuten an? Die Alternative wäre den jeweiligen Wert in Realtime auszulesen, bietet openHAB hierfür überhaupt eine entsprechende Möglichkeit?

Ja, ist schon richtig. Es "zappelt" ganz schön. Evtl könnte man hier auch runden auf volle Watt. Wegen "realtime" hatte ich schon mal in meinem EC3000 binding eine "real time modus" eingebaut. Dann würde er wirklich alle updates mitbekommen und man kann das zum sehr genauen Messen (und via Persistence auch zum Loggen) benutzen. Der Modus war per "switch" item einschaltbar. Vielleicht baue ich das noch mit ein.

[mweb]

Hi,



klasse!

Zur Info: Du könntest auch gerne eine Pull Request schicken, den Du dann einfach weiterpflegst. Im Grunde ist ein PR ja nur ein Branch aus Deinem Repo. Der Vorteil ist, dass der Code automatisch gebaut wird, was Dir die Distribution des Binaries vereinfacht.

Danke und Gruß,

Thomas E.-E.

OK, ich versuche das demnächst mal. Wo genau muss die Wiki *.md Datei liegen?

[teichsta]

OK, ich versuche das demnächst mal. Wo genau muss die Wiki *.md Datei liegen?

Du könntest erstmal mit der README.md arbeiten, die im Root-Verzeichnis des Bindings liegt. Den Inhalt dieser Datei kannst man dann später leicht zur Wiki-Seite machen. Wiki-Seiten legst Du einfach über das Web-Interface an.

Gruß,

Thomas E.-E.

[michaeljk]

So, Steckdose hängt ordentlich an der Wand und ist komplett mit Wohnzimmer-Geräten belegt. Ich habe es allerdings noch nicht hinbekommen das Binding zu testen, da die Erstellung des JAR-Files noch nicht so will wie ich möchte (ich werde das nachher direkt mal per Vagrant probieren anstatt über das lokale OS X).

Hast du auch bereits fertige Binaries zum Download?

[mweb]

Hast du auch bereits fertige Binaries zum Download?

Nein leider nicht. Schick mir Deine Email per PN, dann kommt es via Mail.

Hi,
Der Vorteil ist, dass der Code automatisch gebaut wird, was Dir die Distribution des Binaries vereinfacht.

Ich habe noch keine Ahnung was ich GENAU machen muss um den Pullrequest ans Openhab zu schicken... Irgendwann finde ich die Zeit mich damit zu beschäftigen. Ich will aber erstmal das Binding stabil (und dokumentiert) bekommen.

[mweb]

Kurzer Stand der Entwicklung:

Das Binding war zu 90% fertig. Allerdings stellte sich die Websocket Connection zwar als performant aber nicht besonders stabil heraus. Ich habe die Websocket API auch nie so richtig in den Griff bekommen.

Ich schreibe das aktuell auf SSH Verbindung um. Das MUSS stabil sein.
Die HTTP/REST Api nutze ich nicht, weil ich denke dass SSH performanter ist und die API mir nicht den Energieverbrauch (Summe) liefert.

Beim Energieverbrauch (enery_sum) hab ich leider ein fieses Problem:

Scheinbar zählt er nicht die Wirkleistung sondern die Scheinleistung (Bin da kein Experte) Jedenfalls stimmen die Werte einfach nicht. Laut energy_sum würde mein Server doppelt so viel verbrauchen.

[michaeljk]

Ich schreibe das aktuell auf SSH Verbindung um. Das MUSS stabil sein.
Die HTTP/REST Api nutze ich nicht, weil ich denke dass SSH performanter ist und die API mir nicht den Energieverbrauch (Summe) liefert.

Steht der Verbrauch pro Port nicht in der Variable "thismonth" aufsummiert? Ich habe das ganze derzeit per Exec-Binding mit der HTTP-API umgesetzt und die Werte erscheinen mir plausibel - zumindest die aktuelle Geräteleistung in Watt, den Verbrauch müsste ich mal gegenchecken. Wenn du ein seperates Strommessgerät hast, dann kannst du das ja mal zwischen den Verbraucher und dem mPower-Port stecken und vergleichen.

Wie möchtest du denn den SSH-Login automatisieren, wo ja leider kein PubKey-Verfahren möglich ist?