FHEM Forum

FHEM - Hausautomations-Systeme => Sonstige Systeme => Thema gestartet von: pipp37 am 01 April 2015, 11:10:51

Titel: Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 01 April 2015, 11:10:51
Ich mache hierzu einen neuen Thread auf. Alle Änderungen/Infos  zu der Einbindung der Leiste stehen hier im 1. Beitrag.
Gemeinsam mit Wzut arbeiten wir aktuell an einem Fhem Modul.

Die aktuelle Diskusssion ist http://forum.fhem.de/index.php/topic,35514 (http://forum.fhem.de/index.php/topic,35514).

TODO Liste

Diese Funktionen werden von Wzut und Pipp37, soweit möglich, umgesetzt.



@wzut: Hallo. Mache bitte einfach das was du willst und wozu du Lust hast.
Vielen Dank.
Super finde ich z.B.  die Funktion off-for-timer, die ich als shell script ja schon länger bei mir und Kunden verwende. Die Leiste steckt auch in Serverräumen meiner Kunden und da kann ich einfach einen Port abschalten, 15 Sekunden warten, und wieder automatisch einschalten lassen wenn ein Gerät (Server ohne ILO/DRac oder Router usw. spinnt. 
Ich mache noch ein Shell-Utility für die Leiste. Fhem startet dann einfach das Tool per Telnet  z.B. mit /etc/persistent/bin/fhem-util.sh off-for-timer  1  30
Das  schaltet den Port für 30 Sekunde aus und dann wieder ein.

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 01 April 2015, 11:22:50
Informationen UBIQUITI mFi/mPower:



Fhem-WIKI Online
Alle neuen Infos sind nun  hier zu finden.
http://www.fhemwiki.de/wiki/Ubiquit_mFi/mPower


Hersteller
https://www.ubnt.com/mfi/mpower/

Datenblatt
http://dl.ubnt.com/datasheets/mfi/mFi_DS.pdf

IP-Address Ubiquiti Discovery Tool v2.3
http://www.ubnt.com/downloads/discovery/ubnt-discovery-v2.3.zip

Vertrieb
http://varia-store.com/Wireless-Systeme/UBIQUITI-mFi:::636_654.html

mPower™
Es sind 3 Modelle erhältlich. Alle verfügen über unabhängige, schaltbare AC-Ports und Energiemonitoring.

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 01 April 2015, 12:48:14
Erstinstallation einer Ubiquiti mPower Leiste ohne Controller.
Version 1.0a (4/2015)

Die Produkte wurden im April 2015 bei mir der Firmware Version 2.0.8 ausgeliefert. Diese Firmware ist schon ziemlich alt.
Folgende Versionen wurden von Ubiquiti zum Download freigegeben.

Die zum diesem Zeitpunkt aktuelleste Version ist 2.1.8.
Release Notes. https://community.ubnt.com/t5/mFi/mFi-release-2-1-8/m-p/1188368#U1188368 (https://community.ubnt.com/t5/mFi/mFi-release-2-1-8/m-p/1188368#U1188368)

Diese Seite im Ubiquiti Forum beschreibt die Upgrade Prozedur.
https://community.ubnt.com/t5/mFi-Frequently-Asked-Questions/mFi-Can-I-upgrade-mFi-device-firmware-manually/ta-p/485311


Um die Leiste mit der alten Firmware Version erstmalig im WLAN ohne Ubi-Controller Software einzurichten gibt es mehrere Wege.

Smartphone / z.B. mit dem  Iphone unter IOS7

Die UBI-Web-UI zeigt dann 2 neue Reiter wie im Anhang.
Im Reiter System stellen wir die Zeitzone ein.  GMT+1 Central European Time (Daylight Savings) und aktivieren Enable NTP Client mit dem Server pool-ntp.org.
Dann den Button "Change"  klicken und "Configuration contains changes. Apply these changes? APPLY"
Ab sofort hat die Leiste immer die richtige Zeit.




Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 01 April 2015, 13:12:19
 3. Standard  status Update nach jedem Befehl -> ist schon so
     sonst nach 300 Sekunden - Intervall Std=300 statt 30 -> ist User Sache dafür gibt es das attr interval
 4. Connect nur bei erfolgreichem Ping auf die Leiste - > wozu , entweder sie spricht oder nicht
     - recheck alle 10 Minuten 3x im Abstand von 10 Sekunden -> siehe interval
     - state setzen auf offline wenn leiste nicht erreichbar -> ist schon so , nennt sich error
 5. Update der Readings nur wenn sich ein Wert ändert -> ist Usersache , attr event-on-change-reading
 6. Befehle für jedes Port on-for-timer -> gibt es schon , siehe SetExtensions der Subdevices
 7. Aktualisieren der internen firmware variablen -> was geht das fhem an ?
 8. Installation der shell tools auf die leiste über fhem -> wozu ?
11. update firmware der leiste -> siehe 7
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 01 April 2015, 13:43:36
@wzut:
Hallo.
Ich bin mit den ersten Dingen soweit fertig, damit du dich weiter darum kümmern kannst. Danke.
Ich beschreibe die Liste noch genauer, damit es keine Mißverständisse gibt.
Danke für Deine Hilfe.
Anbei das UBI Modul. Das Infratec habe ich nicht angefasst. Ich setzte mich gleich an die Liste.
LG

Update: Liste ist fertig und im 1. Beitrag.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 02 April 2015, 01:08:57
@Wzut - Todo:

Als ich eine 2. Leiste definiert habe wird nur die 1. in der InfratecOut Gruppe angezeigt

Punkt 16 der TODO Liste ganz oben.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 02 April 2015, 19:13:37
ja ist klar ,weil bei den Infratec Leisten die Ports Namen haben können jetzt aber stur die Namen Out1 bis Outx vergeben werden:
Qick Fix : Out1-3 der ersten Leiste via Kommandozeile umbenennen , dann kann autocreate für die zweite Leiste wieder die Namen Out1 - 3 vergeben.
In meiner Version ist das schon gefixt das autocreate den Namen aus Basis Device +PortNr erzeugt.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 02 April 2015, 19:27:57
@wzut: Super. Thanks - hat mit rename funktioniert.
Punkt 16 - 100% fertig - wurde auf der 1. Seite abgehakt.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 05 April 2015, 15:29:11
Erstinstallation einer Ubiquiti mPower Leiste ohne Controller.

Um die Leiste mit der alten Firmware Version erstmalig im WLAN ohne Ubi-Controller Software einzurichten gibt es mehrere Wege.

Windows PC Window7


Die UBI-Web-UI zeigt dann 2 neue Reiter wie im Anhang.
Im Reiter System stellen wir die Zeitzone ein.  GMT+1 Central European Time (Daylight Savings) und aktivieren Enable NTP Client mit dem Server pool-ntp.org.
Dann den Button "Change"  klicken und "Configuration contains changes. Apply these changes? APPLY"
Ab sofort hat die Leiste immer die richtige Zeit.




Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 06 April 2015, 00:15:59
Fhem-WIKI Online
Alle neuen Infos sind nun  hier zu finden.
http://www.fhemwiki.de/wiki/Ubiquit_mFi/mPower
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: fhainz am 06 April 2015, 09:38:02
Hallo pipp37,

gerade den Wiki Artikel gelesen, ist sehr informativ geworden! Eine Anmerkung hab ich dennoch, vielleicht kannst du das mal überprüfen und anschließend wenn richtig einarbeiten.

Zitat
Nach einem Stromausfall (bzw. direkt nach dem Einstecken in eine Steckdose) werden die Ports nach dem Starten der Firmware immer eingeschaltet.
Stimmt nur wenn die Kontrollersoftware nicht installiert bzw. in der Software keine Gerät für den Port angelegt wurde. Nach dem anlegen der Devices schalten die Relais nach dem starten in den letztstand.

- Weiters kann man in der Kontrollersoftware einen Port sperren, damit er nicht mehr ein/aus geschaltet werden kann.
- Die Kontroller Software sollte auch auf einen Rpi laufen: http://community.ubnt.com/t5/mFi-Frequently-Asked-Questions/Installing-the-mFi-Controller-on-Raspberry-Pi/ta-p/1129462

Grüße
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 06 April 2015, 13:02:44
@fhainz: Thanks.
Wiki wurde geändert und die 2 Punkte in die TODO Liste im 1. Thread  aufgenommen. Punkt 18 u. 19.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 06 April 2015, 22:36:51
Das Wiki ist gut , allerdings hilft es einem nicht wirklich weiter wenn man wie ich das Pech hatte eine Uralt Version zu bekommen : 1.2.6 !!
Die beschriebene Update Methode via Browser läuft zwar durch, bewirkt allerdings nichts. Laut ubnt muss man bei 1.x Versionen auf die ssh Variante zum Upgrade wechseln : https://community.ubnt.com/t5/mFi-Frequently-Asked-Questions/mFi-Can-I-upgrade-mFi-device-firmware-manually/ta-p/485311
Damit hatte ich Erfolg , sollte IMHO auch noch ins Wiki
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 06 April 2015, 23:44:40
@Wzut.
Ein Wahnsinn. Diese Version ist ja echt uralt. Hast du die Leisten von varia-store bekommen?   Meine kürzlich gelieferten  Leisten hatten auch noch eine ziemlich alte 2.0.8 er Version.
Das noch so alte Firmwareleisten ausgeliefert werden wundert mich schon sehr. Darum hatte ich es eigentlich im Wiki nicht vorgesehen.
Das werde ich aber nun nachtragen. Thanks.


Ich arbeite ja schon seit über 2 Jahren mit Ubi Produkten  und die 1er mPower Versionen waren ohne Kontroller nur zum Ein- und Ausschalten zu gebrauchen.

Damals (2013) gab es noch die Ubiquiti Cloud. Mit desem System war Ubi ziemlich vorne dabei aber auf einmal haben sie die Cloud abgedreht.
Als ich dann endlich mehr Zeit dafür hatte, konnte ich mir keinen Account mehr sichern.
https://community.ubnt.com/t5/mFi/mFi-Cloud-closed-to-new-users-To-be-re-launched-at-a-later-date/td-p/581653


Dabei konnten sich die die Leisten in der Cloud anmelden und mit einem Account konnte man von überall die Ports schalten. Wenn ich mir jetzt die Firmware der Leiste ansehe, gibt es wahrscheinlich bald wieder etwas. Codeschnipsel sind in der aktuellem 2.1.8 Firmware zu finden.

Schlagwort: Internet for things. 
Eine Firma ist z.B.  https://www.pubnub.com/
Vielleicht gibt es ja auch mal ein Modul für Fhem - oder kennt jemand etwas Ähnliches ?

Ich arbeite ja schon seit über 2 Jahren damit und die 1er Versionen waren ohne Kontroller nur zum Ein- und Ausschalten zu gebrauchen.
LG
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: fhainz am 07 April 2015, 10:55:21
Hab vor ein paar tagen meinen Harmony Hub drangesteckt, power wird leider keine mitgeloggt aber der energy zähler zählt laaangsam hoch und steht derzeit bei mickrigen 26 wh.  ;D

Weiß jemand wieviel Leistung auf einem Port die Leiste mind. benötigt um sie darzustellen?


Grüße
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 07 April 2015, 11:17:00
Das Gerät sollte eigentlich alles zählen. Ich habe kurz mal nur einen Repeater am Port3 angesteckt.
Mit telnet/ssh  auf die Leiste gehen.
Unter /proc/power sind die ganzen Daten.

MF.v2.1.8# cat /proc/power/i_rms*
0.033566951
0.0
0.024948835

Dort zeigt  die Leiste 0.0249mA Stromaufnahme für den Repeater.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: fhainz am 07 April 2015, 11:34:30
Bei steht da leider 0.0.

Dort zeigt  die Leiste 0.0249mA Stromaufnahme für den Repeater.

0.0249A ;)

P = U * I
P = 230 * 0,0249
P = 5,72W

Das sollte für einen Repeater passen.

Der Harmony Hub verbrauch laut PCA301 nur 0.8 - 1.0W. Das wird anscheinend zu wenig für für die mfi sein. Hatte vorher meine Sonos Bridge dabei. 3.6W die noch registriert wurden, also muss die grende irgendwo dazwischen liegen :D
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: fhainz am 07 April 2015, 12:02:15
-rw-r--r--    1 mfi      admin           0 Apr  7 10:52 reset1
-rw-r--r--    1 mfi      admin           0 Apr  7 10:52 reset2
-rw-r--r--    1 mfi      admin           0 Apr  7 10:52 reset3
-rw-r--r--    1 mfi      admin           0 Apr  7 10:52 reset4
-rw-r--r--    1 mfi      admin           0 Apr  7 10:52 reset5
-rw-r--r--    1 mfi      admin           0 Apr  7 10:52 reset6

Die Files reset1-6 in /proc/power/ sind vermutlich zum energie zähler zurücksetzen. Muss ich da einfach eine 1 reinschreiben? Hast du eine Idee?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 07 April 2015, 13:29:17
Die Leiste zählt nur selber wenn sie ohne Kontroller läuft. Sonst übernimmt der Kontroller diese Sache.
tail -f /var/log/messages zeigt die die Logs.

Wenn die Leiste mit dem Kontroller eingestellt ist und der Kontroller offline ist, schaltet sie auf einen Standalone Betrieb zurück. (SELFRUN)

Mache mal einen Werksreset - 10 Sekunden die Microtaste drücken - oder lösche die Leiste aus dem Kontroller.

Auch vorsichtshalber  den laufenden Kontroller beenden.
Dann läuft alles mit der 2.1.8er Version.

Wichtig! Nach dem Reset in der Web Oberfläche alle Ports einmal aus- u. einschalten.

echo 1 >reset1 z.B setzt den Zähler zurück und schaltet das Port1 ab.

Bei der Berechnung der geringen Lasten den Powerfaktor nicht vergessen.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: fhainz am 07 April 2015, 14:32:58
Nein, das passt schon mit dem Kontroller. Der ist ganz praktisch und läuft auf dem OS X Server nach dem Launch im Hintergrund mit.

Ich hab gerade weitergetestet. Die minimalste Last die mir auf SD-Website angezeigt wurde waren 1.03W.
Eine FS20-Steckdose alle war noch zu wenig, mit einer 2. in serie wurden mir dann die 1.03W angezeigt. Der Schwellwert wird wohl bei 1W liegen, und der Harmony Hub ist knapp drunter :(

echo 1 >reset1 z.B setzt den Zähler zurück und schaltet das Port1 ab.
Danke, das probier ich gleich!
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: fhainz am 07 April 2015, 14:50:50
Nachdem man reset eine 1 geschickt hat muss man gleich eine 0 hinterher senden. Sonst klackt das Relais die ganze Zeit  ;D

echo 1 >reset1
echo 0 >reset1
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 07 April 2015, 15:08:52
sodele , hier nun endlich meine zweite Beta Version :)
Änderung zur bisherigen Version :
das Perl Modul JSON wird zusätzlich benötigt , bsp Raspi -> apt-get install libjson-perl
das Attribut autocreate wurde durch das Attrib subDevices ersetzt, Funktion :
ist subDevice = 1 oder nicht gesetzt werden Port bezogene Readings an das Subdevice weitergereicht ( erfordert 98_InfratecOut.pm ) , ist subDevice = 0 werden alle gelesenen Werte diesem einen Gerät zugeordnet. Das kann bei einer 8er Leiste recht schnell unübersichtlich werden.

Neues Attribut ignoreList : eine Liste mit Ports die bei einer Status Abfrage übergangen werden sollen , Bsp
1,3,7,8  oder 2 3 6 7

neue Get Kommandos : info & reboot
info = holt interen infos
reboot = reboot der Leiste 
 
die Set Outx lock & unlock Kommandos werden zwar schon angezeigt sind aber noch nicht umgesetzt

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: fhainz am 07 April 2015, 15:10:31
Danke! Werde gleich testen.

Ist der non-blocking zugriff schon dabei?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: fhainz am 07 April 2015, 15:50:55
Gerade am testen, die neuen all_* Readings sind super! Die standen schon auf meinem "wunschzettel" und non-blocking ist auch schon dabei wie ich merke. Klasse arbeit, deutlich performanter :)

Im Developer Bereich gab es mal eine Diskussion über Values + Einheiten (http://forum.fhem.de/index.php/topic,21247.0.html), es kam unterm strich raus das die (irgendwann mal) getrennt gespeichert werden. Auch für die Weiterverarbeitung und Darstellung (bei mir SmartVisu) sind Einheiten am Ende des Werts eher unpaktikabel. Möchstest du die wieder rausnehmen und sie nur in der Doku erwähnen?

Würdest du vielleicht auch nochmal über die Kommastellen nachdenken? 6 sind vielleicht zuviel, aber mMn ist das ein Frontend Thema. :)

Grüße
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 07 April 2015, 16:16:09
ja ja die lieben Einheiten , ich finde die "nackten" Readings immer so hässlich und habe für mich das schon bei einigen Modulen geändert :)

wo hast du sechs Nachkommstellen ? Ich bemühe mich eigentlich immer Werte so kurz wie möglich/sinnvoll zu formatieren.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: fhainz am 07 April 2015, 16:27:24
ja ja die lieben Einheiten , ich finde die "nackten" Readings immer so hässlich und habe für mich das schon bei einigen Modulen geändert :)
Ich sehe readings eher als "roh daten", die anschließend vom frontent aufbereitet werden (müssen).

wo hast du sechs Nachkommstellen ? Ich bemühe mich eigentlich immer Werte so kurz wie möglich/sinnvoll zu formatieren.
In den readings, nachdem ich die Formatierung bei mir rausgenommen hab :) In SmartVisu kannst du zB dem basic.float widget eine Einheit mitgeben. Die Einheit ist mit der entsprechenden formatierung verknüpft und am Ende hast du einen formatieren Wert mit Einheit.

Bei mir hängt zB an einer Dose die Sonos Bridge mit 0,03A Stromaufnahme. Hier sieht es mMn besser aus wenn im Frontend zB. 365mA steht.

Wenn du das anders siehst, kein Ding, ich mach mir ein diff das ich nach einem Update einspiele. Halb so wild :)

Grüße
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 07 April 2015, 16:53:55
In SmartVisu kannst du zB dem basic.float widget eine Einheit mitgeben.
sorry , da habe ich nun kein Wort von verstanden ... ich versuche es daher noch einmal  :
Welche Readings haben bei dir 6 Nachkommstellen ?

 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: fhainz am 07 April 2015, 16:57:13
Normalerweise keine. Ich hab mich schlecht ausgedrückt.
Ich hab bei mir die Formatierung rausgenommen damit das smartvisu erledigen kann.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 07 April 2015, 21:58:33
Update :
Readings ohne Einheiten
lock / unlock für Out1 - Outn ( nicht via InfratecOut )
force für on/off an Out1 - Outn (nicht via Web , Kommandozeile oder at , notify -> set <name> Out1 on force )
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 08 April 2015, 20:52:59
Update :
1.Neues Attribut ledconnect -> wenn != OFF legt fest wie die LED der Leiste beim fhem Zugriff aufleuchten soll
2.Wenn bei einem Port das lock gesetzt ist wird im Webfrontend die Status Glühbirne nur noch eine Anzeige und kein Link zum direkten schalten mehr.
   Betrifft auch Subdevices die mit  98_InfratecOut.pm angebunden sind (daher auch hier eine neue Version)
3. Überprüfung auf Firmware Version min. 2.1.8 ( Meldung bei Inernals und Log falls kleiner)
4. Reset der Messwerte für Out1 - Outn
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 09 April 2015, 23:04:48
Hallo Wzut.

Könntest du die Readings wie in den HM Zählern machen?
current in mA, und die Kommastellen wie in der Liste.
Thanks.


Internals:
   DEF        2A846802
   NAME       HM_2A8468_Pwr
   NR         292
   STATE      8294.6
   TYPE       CUL_HM
   chanNo     02
   device     CUL_HM_HM_ES_PMSw1_Pl_2A8468
   Readings:
     2015-03-30 13:29:50   R-averaging     1 s
     2015-03-30 13:29:50   R-sign          off
     2015-03-30 13:29:50   R-txMinDly      8 s
     2015-03-30 13:34:24   R-txThrCur      160 mA
     2015-03-30 13:29:50   R-txThrFrq      2 Hz
     2015-03-30 13:32:41   R-txThrPwr      35 W
     2015-03-30 13:29:50   R-txThrVlt      10 V
     2015-03-30 14:28:46   RegL_01:        08:00 7A:01 7B:08 7C:00 7D:0D 7E:AC  7F:00 80:A0 81:00 82:64 83:C8 00:00
     2015-04-09 22:57:06   boot            off
     2015-04-09 22:57:06   current         276
     2015-04-09 22:57:06   eState          E: 8294.6 P: 30.31 I: 276 U: 228.1 f: 50.01
     2015-04-09 22:57:06   energy          8294.6
     2015-03-30 13:35:20   energyOffset    2066.4
     2015-04-09 22:57:06   frequency       50.01
     2015-04-09 22:57:06   power           30.31
     2015-04-09 22:57:06   state           8294.6
     2015-04-09 22:57:06   voltage         228.1
   Helper:
     Role:
       chn        1
Attributes:
   alias      HM-Plug-Zaehler2
   model      HM-ES-PMSw1-Pl
   room       Schalter,Zähler
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 10 April 2015, 07:22:33
Könntest du
An meinem Arbeitsplatz beantworte ich Fragen die mit diesen Worten beginnen stets mit der gleichen Antwort :
Ich kann alles und immer :)

Spass beiseite , lies dir bitte mal auf der vorherigen Seite die Beiträge von fhainz durch zum Thema Einheiten in Readings und Kommastellen.
Vorschlag : Lass uns im Moment weniger über Optik statt Technik reden , d.h. zuerst sollten Möglichkeiten und deren Funktionen im Vordergrund stehen
oder wie ich auch immer sage : "gehe muss es , schee mache wir später" :)   
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 10 April 2015, 20:48:05
Hallo Wzut,
ich finde es genial, das die Leiten unterstützt werden. Danke für Eure Arbeit.
Ich habe die 1,3 und 6 Port Variante. Bei der 3 Port Version sind die SubDevices angelegt worden.
(BTW die kam mit einer 1.x FW) Bei den 1und6er Versionen leider noch nicht (Die kamen mit 2.08)
Alle Leisten sind vor der Integration af aktuelle FW gebracht worden und neu gestartet.

Was könnte der Grund für das Problem sein?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 10 April 2015, 21:10:26
hmm , ein möglicher Grund könnte sein das bei der 1er und 6er die Ausgabe etwas anders iausschaut als bei der 3er.
pipp37 und ich haben beide z.Z nur die 3er.
a. Bitte Poste doch mal den Abschnitt aus deiner fhem.cfg wie du die 1 und 6 angelegt hast
b. stell bitte zuerst bei der 1 er verbose auf 5 und dann mache ein get <name> info und ein get <name> status dann verbose wieder auf 3
c. das gleiche Spiel bitte mit der 6er wiederholen
d. den abschnit b & c aus dem fhem.log bitte hier posten
e. wenn möglich bitte noch von beiden einen Screenshot der Internals posten
oder und vllt. schneller, wenn du magst : die 1 und 6er auf deinem Router nach aussen freigeben und mir die Daten via PM schicken dann kann ich sofort bzw. morgen Abend die beiden testen.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 10 April 2015, 21:28:50
Hallo,

das wird bei mir Sonntag werden.
Die Leisten habe ich via autoconfig anlegen lassen, also alles automatisch bei allen Varianten.
define mpower6 UbiquitiMP IP
attr mpower6 password ubnt
attr mpower6 subDevices 1
attr mpower6 timeout 2
attr mpower6 user ubnt
Beide haben bis auf Namen und IP den gleichen Eintrag.

Nico
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 10 April 2015, 21:33:10
OK, kommen denn Readings an bzw. kannst du die Ports an und ausschalten ?
Wenn nein , dann setzte mal subDevices auf 0 , die readings werden dich dann bei der 6er zwar fast erschlagen aber für einen Test sollte das gehen.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 10 April 2015, 21:46:54
Ich bin heute endlich dahinter gekommen warum bei mir die Verbrauchswerte nicht richtig aufsummiert werden seit dem letzten PowerUp.
WICHTIG : bei jeden Port muss dazu das Reading enable den Wert 1 haben !

Update : neues Set Kommndo enable/disable um dieses Bit zu setzen bzw. ggf. wieder zu löschen.

Unklar ist mir z.Z nur noch wie ich den Wert aus /proc/power/energy_sum1 -x zu behandeln habe ? Auch mit 0,3125 multiplizieren oder nicht ?
Welche Einheit versteckt sich hinter diesem Wert ? -> liegt z.Z. mit x 0.3125 auf dem reading ernergy
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 10 April 2015, 21:51:50
Hallo,
es kommt wohl nur das state reading Initialized

Egal wie die SubDevices eingestellt sind.

Die Ausgänge kann ich im UbiquitiMP Device schalten

Entwarnung vergesst es ;) Ich habe bei dem 1er und 6er vergessen den NTP Client zu aktivieren.
Nun laufen beide und die Devices sind angelegt worden.

Vielleicht so als möglicher Bug ins Wiki?
Nico
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 10 April 2015, 22:29:44
sehr schön , wird pipp37 bestimmt DICK ins Wiki  übernehmen  :)
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 10 April 2015, 23:04:23
Ich bin heute endlich dahinter gekommen warum bei mir die Verbrauchswerte nicht richtig aufsummiert werden seit dem letzten PowerUp.
WICHTIG : bei jeden Port muss dazu das Reading enable den Wert 1 haben !

Update : neues Set Kommndo enable/disable um dieses Bit zu setzen bzw. ggf. wieder zu löschen.

Unklar ist mir z.Z nur noch wie ich den Wert aus /proc/power/energy_sum1 -x zu behandeln habe ? Auch mit 0,3125 multiplizieren oder nicht ?
Welche Einheit versteckt sich hinter diesem Wert ? -> liegt z.Z. mit x 0.3125 auf dem reading ernergy

Hallo Wzut.  Leider habe ich diese Woche sehr wenig Zeit für die Hardware aber die Threads lese ich schon ....

Ich habe festgestellt, dass die energie_sum Werte den tatsächlichen Verbrauch in Wh ist. Bei Stromuasfall fängt die Leiste wieder bei 0 an zu zählen. Darum sollten wir auch einen energyOffset einführen, so wie es die HM Powerplugs machen.

Ein echo 1 >resetX lässt die den Port wieder bei 0 anfangen zu zählen. Auch musste ich selbst die Ports extra mal aus und wieder einschalten, damit der energie_sum und cf_count Wert wieder zu Zählen anfing.


Ein mögliches Problem sehe ich aber in der gleichzeitigen Verwendung des UBI Kontrollers. Wenn der Kontroller läuft verhalten sich die Dinge etwas anders. Da kommt das enableX zum Tragen.   Auch werden die Verbrauchswerte vom Kontroller verarbeitet. Wie die Werte dann noch in der Leiste gespeichert werden, habe ich noch nicht herausgefunden.

Und noch etwas ist mir aufgefallen. Wenn die Leiste mit Kontrollerverwendung eingestellt ist und der Kontroller nicht erreichbar ist, fällt sie in einen sogenannten SELFRUN Modus.
Ein tail  -f /var/log/messages zeigt das.

Darum sollten wir unbedingt die gleichzeitige Verwendung des Kontrollers mit FHEM NICHT empfehlen. Da gibt es zuviele Dinge, die zu beachten sind.  Oder wir machen eine Abfrage, ob die Leiste Standalone oder mit Kontroller läuft. Dann geht halt nicht allles.

Meines Erachtens  wird der  Kontroller nicht benötigt wenn nur die mPower Leisten verwendet werden und birgt nur Fehlerquellen. Auch kann es sein, dass alles wieder ganz anders wird, wenn ein neues Kontrollerupdate anliegt.

Noch etwas zum energyOffset.
Funktion.
Das Perl Modul dupliziert intern den aktuellen energy_sum Wert. Wenn der  nächste energy_sum kleiner als der letzte gelesene ist, wurde die Leiste resetiert/stromlos gemacht und der letzte höchste Wert wird zum energyOffset.  Dieser energyOffset wird beim nächsten Reset/Stromaufall wieder  mit dem letzten energy_sum Wert addiert. Damit hat man immer die gesamte verbrauchte Energie.
Einen Reset dieses Wertes kann man dan z.B. mit einem get oder set Befehl machen. z.B. set UBINAME resetEnergyOffset.

PS: Ich habe alle 3 EU Modelle  - 1 Port / 3 Port(für dich online) und eine 6 Port (noch nicht ausgepackt).
Die 1 Port habe ich zum Testen mit der Kontrollersoftware und zum Firmwareflashen installiert.  Eine weitere 3 Port hängt schon ein halbes Jahr in meinem Serverschrank.



Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 10 April 2015, 23:12:36
Vielleicht so als möglicher Bug ins Wiki?
Nico

Ist im WIKI.
http://www.fhemwiki.de/wiki/Ubiquit_mFi/mPower#Zeitsynchronisation
Gruss
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: fhainz am 12 April 2015, 08:25:49
Darum sollten wir unbedingt die gleichzeitige Verwendung des Kontrollers mit FHEM NICHT empfehlen. Da gibt es zuviele Dinge, die zu beachten sind.  Oder wir machen eine Abfrage, ob die Leiste Standalone oder mit Kontroller läuft. Dann geht halt nicht allles.

Meines Erachtens  wird der  Kontroller nicht benötigt wenn nur die mPower Leisten verwendet werden und birgt nur Fehlerquellen. Auch kann es sein, dass alles wieder ganz anders wird, wenn ein neues Kontrollerupdate anliegt.

Das kann ich so gar nicht bestätigen. Bei mir läuft der Kontroller von beginn am auf einem OS X Server und ich hatte bisher weder Probleme mit dem Kontroller noch Steckdose oder FHEM Modul. Bei einem Server Neustart verliert die Leiste kurz die Verbindung zum Kontroller aber nach spätestens 2 Minuten hat sich die Verbindung neu aufgebaut und es passt wieder alles. Die Leiste steh dann im Kontroller auf active.

Edit: Auch nach einem Stromausfall (gerade getestet) bootet die Leiste und schaltet die Dosen wieder Ein die vorher auch Ein waren. Sie verbindet sich, nachdem der Server gebootet hat der auch an der Leiste steckt, wieder mit dem Kontroller.

Entwarnung vergesst es ;) Ich habe bei dem 1er und 6er vergessen den NTP Client zu aktivieren.
Nun laufen beide und die Devices sind angelegt worden.

Vielleicht so als möglicher Bug ins Wiki?
Hab bei meiner 6er Leiste auch keinen NTP Client eingetragen aber keine Probleme in FHEM. Vielleicht kommt die Zeit vom Kontroller?


Grüße

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 12 April 2015, 11:00:38
@fhainz:
Genau so läuft es auch bestens. Nur sind wir Edv Techniker und Programmierer schon in der Lage den Kontroller zu installieren und einzustellen, aber normale Anwender könnten da schon mal Probleme bekommen.

Ntp ist da genau so eine Sache. Der Client wird in der Leiste abgeschaltet wenn sie  im Kontrollermode läuft.

Natürlich ist die Kontrollersoftware echt cool.
Sie ist ja die zentrale Steuerungsapplikation für alle Ubi Produkte und sehr ausgereift.




Gesendet von iPhone mit Tapatalk
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 13 April 2015, 12:37:29
Hallo,
also ich bin auch Technisch in der Lage die Controller SW zu installieren.
Ich versuche aber zusätzliche Controller zu vermeiden. Dazu nutze ich ja schließlich FHEM.

Ich weiss nicht ob es bei mir am WLAN und der Position der Geräte liegt. Aber habt Ihr auch ab und an Connection Fehler?
Zudem meine ich nach einem Neustart der Leite setzt FHEM die Ausgänge nicht, sodass alle Aktiv bleiben.
Evtl wäre es möglich, den ntp Client zentral im FHEM als Parameter für Ubiquiti mpower zu hinterlegen und dann per FHEM auf den Leisten zu konfigurieren?

Nico
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: fhainz am 13 April 2015, 12:40:00
Zudem meine ich nach einem Neustart der Leite setzt FHEM die Ausgänge nicht, sodass alle Aktiv bleiben.
Das Problem hatte ich bevor ich Devices im Kontroller angelegt hatte auch. Jetzt klappts problemlos.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 15 April 2015, 13:28:00
Meine Leiste ist seit Sonntag nicht mehr im Spielmodus auf dem Schreibtisch sondern dort verbaut wo sie gebraucht wird. Nun hätte ich da gerne zwei Problemchen ...

a. kann es sein das die Ubis typisch amerikanisch den WLAN Kanal 13 nicht kennnen ? Ich bekomme zumindest keine Verbindung wenn der AP auf Kanal 13 läuft.

b. da meine Leiste ja leider mit der Uralt FW 1.x ausgeliefert wurden musste ich zwingend bei den ersten Inbetriebnahme Versuchen eine Adresse des mFi Controllers eingeben. Trotz nun zweimaligen Factory Reset ist die Erinnerung an den mFi Controller noch vorhanden ( ich sehe im Log die erfolglosen Verbindungsversuche)Ich kann auch im Webinterface nicht wie im Wiki beschrieben "Personal" einstellen. d.h. der Teil schaut bei mir etwas anders aus (Siehe Screenshot)   
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 15 April 2015, 19:16:10
Hallo,

das Problem habe ich auch!

Dafür nochmal zur Klarstellung:
Fehlender NTP Eintrag und die SubDevices werden nicht angelegt in FHEM
Fehlende Zeitzone und die Leistungsmessung läuft nicht
Anschliessend müssen die Ports wirklich einmal aus- und angeschaltet werden. Sonst beginnt die Zählung nicht.

Ansonsten sieht mein mpower 1er auch irgndwie anders aus. Da gibt es halt die Readings der Werte im UbiquitiMB Device nicht sondern nur im SubDevice.

Nico
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 15 April 2015, 19:40:35
Ansonsten sieht mein mpower 1er auch irgndwie anders aus. Da gibt es halt die Readings der Werte im UbiquitiMB Device nicht sondern nur im SubDevice.
Das ist auch so gewollt ! Denn bei nur einem Port ist die Summe aller Ports gleich dem ersten Port :)
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 16 April 2015, 10:17:49
Hallo,

dachte ich mir ;)

BTW zum Controller Problem:

Einfach mit vi /etc/persistent/cfg/mgmt die 2. Zeile mit dem Server Eintrag löschen.

Nico
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: fhainz am 16 April 2015, 19:17:36
a. kann es sein das die Ubis typisch amerikanisch den WLAN Kanal 13 nicht kennnen ? Ich bekomme zumindest keine Verbindung wenn der AP auf Kanal 13 läuft.
Genau das selbe Problem hatte ich auch. Bei mir hat es ewig gedauert bis ich überissen hatte das Port 13 Probleme macht. Ich wollte das noch erwähnen aber ich befürchte ich habs vergessen  ::)
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 17 April 2015, 08:43:12
Ich habe mal etwas gesucht zu diesem Thema Kanal 13, wie ich das z.Z. sehe liegt das eigentlich nur am verwendeten Country Code für den Atheros Treiber. 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 18 April 2015, 09:07:44
ja mehere Ports in einem Rutsch schalten ist im Modul noch nicht vorgesehen.. Deine Versuche schieitern z.Z. vermutlich daran das die Wartezeit von 1 Sekunde zu kurz ist. D.h. Die Rückmeldung des vorherigen Schaltbefehls liegt noch nicht vor und du versuchst schon den nächsten abzusetzen. Sollte eigentlich Meldungen im Log erzeugen, wenn nicht den verbose Level einfach mal auf 5 hochsetzen.

Toggle Funktion sowie alle anderen Set Extensions Befehle (on-for-timer etc ) können über das Subdevice des jeweiligen Ports mittels 98_InfratecOut benutzt werden.
   
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 18 April 2015, 15:09:48
ok, zum Thema Toggle kann ich bei mir heute Abend mal testen.
Für deine Mehrfachbefehle schwebt mir folgende Lösung vor :
ein neues Attribut , mit Namen groupPorts ->
attr <name> groupPorts Musik=1,4 TV=2,5,6
damit wäre die Gruppe Musik mit den Ports 1 und 4  und die Gruppe TV mit den Ports 2 , 5 und 6 schaltbar wie folgt :
set <name> Musik off oder set <name> TV on
D.h. die jeweilige definierte Gruppe würde sich verhalten wie ein Port , wäre das ein sinnvoller Weg ?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 19 April 2015, 13:23:21
den Toggle Fehler habe ich gefunden : Die Infratec Leisten kennen den Befehl Toggle direkt folglich wird toggle nicht über die Set Extensions abgewickelt sondern direkt zum Hauptmodul durchgereicht. 98_UbiquitiMP kennt nun auch das Kommando toggle.

Fix : bei der Verwendung von ignoreList wurden die Ports nicht vollständig ignoriert sondern nur teilweise.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 20 April 2015, 20:15:52
und die nächste Runde :
Update : neues Attribut groupPorts
Beispiel : attr <name> groupPorts TV=1,2 Media=2,3 Licht=4,5,6Definiertt die Schaltfgruppe TV mit den Ports 1 & 2 , die Gruppe Media mit den Ports 2 und 3 sowie die Gruppe Licht mit den Ports 4-6,
doppelt definierte Ports sind zulässig.
Syntax : GruppenName=PortNr<KOMMA>PortNr<BLANK> nächste Gruppe
Diese Gruppen können mit den normalen Befehlen (on,off,toggle,usw.) geschalten werden wie bisher einzelne Ports mit Outx
Die Gruppe ALL ist per default immer vorhanden (Ausnahme die 1 Port Ubi , dort sind keine Gruppen möglich bzw. sinnvoll)     
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 21 April 2015, 07:13:51
Kleine Nachfrage - wenn ich SONOS=2,3,4,5,6 on schalte, kommt Port 1 mit Verzögerung nach auf auf on.?

wie ?, der Port 1 schaltet obwohl er nicht in der Gruppe ist ? Wenn ja :
verbose auf 5 , Gruppe schalten , warten bis der Port 1 nach kommt , verbose auf 3 und diesen Log Abschnitt hier posten.
Ich habe z.Z nur eine 3er Leiste zur Verfügung, bitte definiere auch mal zusätzliche Gruppen und teste ob die alle richtig schalten.
 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 23 April 2015, 20:05:09
ich habe eben die erste Version ins svn hochgeladen und meine bisher hier geposteten Versionen gelöscht.

Update : das Modul für die SubDevices nennt sich nun passend 98_UbiquitiOut.pm (das 98_InfratecOut unter contrib werde ich demnächst löschen,
da dieses Modul nun die Aufgabe übernimmt)
Für die 1 Port Ubi habe ich die Readings etwas aufgeräumt, die Set Extensions direkt eingepflegt und die Port Angabe (Out1) bei jedem Befehl entfällt nun für dieses Modell. Das Attribut SubDevices hat bei diesem Modell den Default Wert 0, da bei nur einem Port eine Unterteilung in Untergeräte recht sinnlos ist
( genau so wie die ignoreList oder groupPorts)

Fix: beim durchsehen meiner Logs ist mir die eine oder andere Perl Warning Meldung aufgefallen, mit der aktuellen Version habe ich seit zwei Tagen nun keine solchen Meldungen mehr.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: carlos am 24 April 2015, 17:47:16
Also bei mir funktioniert der SVN Stand leider nicht mehr.
Folgender Fehler:
problem connecting to "192.168.178.54", port 23: connect timed-outGruß
Carlos
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 24 April 2015, 19:32:54
@det., dich erwartet genau das was ich in meinem letzten Posting geschrieben habe bzw kommt halt darauf an ob du die 1 Port mini oder eine 3er oder 6er mPower hast ... löschen/ändern  sollte man die angelegten Subdevices da sich ja jetzt der Modulname geändert hat.

@carlos, die Meldung besagt aber das sich deine Ubi auf Port 23 unter der IP nicht meldet. Ich sehe da keinen Fehler dem man dem Modul zuschreiben könnte.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: carlos am 24 April 2015, 20:56:01
Das ist mir schon klar, aber es ging vorher und ein telnet zu dieser IP funktioniert. Deswegen versteh ich es ja nicht.

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 24 April 2015, 21:16:46
@det. , wie hast du den timeout Wert gesetzt ? die Meldungen deuten darauf hin das du dem Modul etwas zuwenig Zeit gibst mit der Ubi fertig zu reden.
verbose auf 5 wird dir im log zeigen das ein Teil der Kommandos schon abgerabeitet wurde.
Ich empfehle den timeout auf min 4-6 zu stellen. Das Modul brauch etwas länger (ca.1 Sekunde) als seine Vorgänger bis es sich zurückmeldet. Hintergrund :
Ich hatte bei mir gesehen das ab und an die Telnet Kommandos zur Ubi etwas zu schnell hintereinander kamen, darum ist jetzt zwischen jedem Komando (das sind bei Get Status 3) eine Wartezeit von 0.5 Sekunden
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 24 April 2015, 21:53:27
Verbose steht bei mir generell auf 0, sorry.
Global oder für das Ubi Modul ? Ich würde gerade jetzt am Anfang den Level für das Ubi Modul auf 3 setzen, so bekommst wenigstens mit wenn ab und an mal was schief läuft und um grundsätzliche Fehler zu finden ist der verbose 5 (für das Modul) halt sehr hilfreich.
Aber guter Einwand mit der 2 in der commandref , werde ich gleich mal ändern.   
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: carlos am 25 April 2015, 00:33:22
Timeout auf 6 hat auch mein Problem gelöst.
Danke
Carlos
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 25 April 2015, 13:23:09
ja mit den timeout muss jeder selbst schauen was in seinem Umfeld nötig ist. Die meiste Zeit verbraucht das set ALL Kommando,
da hier z.B. bei einer 6er Leiste sechs mal die Wartezeit zuschlägt -> aktuell sind das schon 3 Sekunden !
Bei mir war die WLAN Verbindung die ganze Zeit im Grenzbereich (etliche Timeouts über 24 Stunden mit 300 Sekunden Interval)
nachdem ich das gestern etwas verbessern konnte kann ich auch wieder kleinere Timeout und Wartezeiten Werte verwenden ohne eine einzige Meldung im Log zu haben.   
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 27 April 2015, 18:55:42
kannst du bitte mal schauen ob die Zeile 429 bei dir so auschaut :
Log3 $name, 5, "$name, ret -> ".$ret[0];und wenn ja mal ändern in :
Log3 $name, 5, "$name, ret -> ".$ret[0] if($ret[0]);
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 01 Mai 2015, 17:13:00
Hallo Wzut.
Hatte endlich wieder Zeit für Fhem und dein SVN Modul per Update installiert und alles umgestellt.
Meine 3 Stk. Leisten wurden perfekt eingebunden und ich habe keinerlei Fehlermeldungen im Log (3).

Etwas ist mir aufgefallen:
Ich habe attr groupPorts  Licht=1,3 bei der noch immer für dich verfügbaren Leiste definiert.
Leider erscheint der Punkt dann nicht mehr nach einem Fhem Neustart. Siehe Grafik 1 groupPorts.jpg.

Wenn eine Gruppe definiert wird und Fhem nicht neu gestartet wird sieht es wie in groupPorts-noreboot.jpg  aus.

Und in Device specific help sollte es  statt groupList groupPorts lauten.


Ich bin begeistert, wie  weit du das Modul schon programmiert hast. Alle Achtung. Danke.

Denkst du noch, dass du die Offset Geschichte machen wirst?




Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 01 Mai 2015, 18:14:32
Nachtrag: Auf einmal funktioniert groupPorts  wenn 2 Gruppen definiert wurden nach fhem Neustart.
Dann passt alles.

Dann wurde die 2. Gruppe gelöscht und Fhem neu gestartet.
Auch dann ging es auf einmal???

Licht=1,3 Lüfter=1,2

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 01 Mai 2015, 18:31:55
Leider erscheint der Punkt dann nicht mehr nach einem Fhem Neustart. Siehe Grafik 1 groupPorts.jpg.
Wenn eine Gruppe definiert wird und Fhem nicht neu gestartet wird sieht es wie in groupPorts-noreboot.jpg  aus.

Und in Device specigic help sollte es  statt groupList groupPorts lauten.

Ich bin begeistert, wie  weit du das Modul schon programmiert hast. Alle Achtung. Danke.

Denkst du noch, dass du die Offset Geschichte machen wirst?
a  - da läuft was gewaltig schief bei dir  mt den Gruppen, den Fehler vom ersten Bild kann ich geistig ja noch nachvollziehen aber beim zweiten Bild ??? da wird irgendwie der String nicht richtig zerlegt , hmmm
b. commandref -> ok beim nächsten Update heute Abend ( @det :  ich hatte später  deinen Fehler auch im Log :) )
c. ja die Offsets, ich muss leider zugeben das ich es immer noch nicht kapiert habe  wozu die deiner Meinung nach benötigen werden :(

Ansonsten war die schnelle (und gute ha ha ha ) Arbeit reiner Eigennutz , dein Wunsch kam genau zur der Zeit als ich mir eigentlich gerade noch zwei EDIPLUG 1101 für ein neues Projekt kaufen wollte. Nun werkelt da statt der beiden EDIPLUGS eine 3er Ubi, Die Tage wird noch eine 1er dazu kommen  :)
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 02 Mai 2015, 19:22:15
@pipp37 , tut mir leid :( ich kann machen was ich will, es gelingt mir einfach nicht deinen Fehler mit dem verwürfelten Set Menü nachzustellen.
wie sieht denn dein attr groupPorts aus ?

Fix :
a. Es war bisher möglich Gruppen zu definieren mit nur einem Port in der Gruppe
b. Änderungen am attr groupPorts zur Laufzeit haben nicht die Internals group_x aktualisiert
bzw . beim kompletten löschen des Attributes blieben die Gruppen beim Set Kommando bestehen. 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 03 Mai 2015, 00:57:29
Hallo Wzut.
Ich habe nun mal meine UBI-CFG  in das Testsystem kopiert.
Vorher ein update und shutdown restart.

Dann habe ich eine neues Attribut groupPorts mit dem Button attr angelegt: Licht=1,3
Die beiden Bilder zeigen die seltsamen Sets.

Wenn ich dann shutdown restart eingebe und im Chrome dann auf einen anderen Punkt klicke (z.b. Everything) und dann wieder zurück auf den Raum UBI, dann passt es.

Weitere Info.
Ich habe die ganzen UBI CFGs mit include fhem-ubi-inc.cfg in die fhem.cfg eingebunden.

Nachtrag.
Wenn das Attribut groupPorts gelöscht wird,  kann ich trotzdem immer noch mit dem set Button die Gruppe auswählen und auch schalten.
-----
Dann mit dem Firefox das selbe Verhalten.

Weiters habe ich dann mit den Attr. Button groupPorts in LichtFF=1,2 Heizung=3  geändert. Das selbe Bild allerdings ist es nach dem Neustart immer noch falsch.
Auch wenn ich es in LichtFF=1,2 Heizung=3,2  ändere bleibt es so (auch nach dem Neustart shutdown restart).
Dann wurde es in LichtFF=1,2 Heizung=2,3 geändert. - Fehler noch immer da - dann shutdown restart in der UI. Auf einmal keine Gruppe mehr da.
Erst nach service fhem stop und service fhem start passte es dann perfekt.








Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 03 Mai 2015, 08:39:24
bedeutet a. das morgen nach dem Update die Gruppe Licht, die nur aus Port 6 besteht nicht mehr funktioniert?
Richtig , warum den Umweg über Gruppe statt Port 6 direkt zu schalten ? Aber wenn es denn unbedingt sein muss Licht=6,6 sollte es möglich machen :)

@pipp37, bitte teste nochmal mit der neuen Version von gestern Abend. Wichtig ist vor allem :
Wenn du eine Gruppe veränderst müssen sich immer zwei Dinge verändern : 
a. die Gruppe bei Sets und
b. ein Internal mit dem Namen group_<Gruppe> und den Ports der Gruppe.

Auch wenn ich mich wiederhole : das fehlerhafte  set dropdown Menü kann ich mir nicht erklären und schaffe es auch nicht das bei mir nachzubilden.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 03 Mai 2015, 09:27:23
Hallo Wzut.
Hilft es, wenn ich dir über einen Pptp Vpn Tunnel einen Zugang zu einem  Test-Dev-Fhem einrichte?
Dann hast du Ssh und http Zugriff.
Gruss
------------
Info: Es gibt eine neue Ubi-Firmware 2.1.11.
Das Update über das WebUi hat mit dem Firefox nicht geklappt. Musste den IE nehmen.




Gesendet von iPhone mit Tapatalk
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 04 Mai 2015, 09:26:05
@pipp37, ich denke das wird nicht viel nützen. Wie ich das sehe liegt dein Problem weniger bei der Ubi oder dem FHEM Modul sondern ehe bei deinen Webbrowsern. Ich würde daher an deiner Stelle mal vollständig auf den Browser verzichten und alle Tests direkt auf Konsolenebene durchführen. Interessant ist vor allem der Punkt wenn der Browser das falsche Set Menü anzeigt , was sagt dann die Konsole bei "set <name> ?"

Ich habe auf meiner Ubi nun auch die neue FW. Leider wurde mein bestehendes Problem das sie immer noch ständig nach einem mFi Server sucht damit nicht behoben. Laut Ubi Forum sollte der Fehler eigentlich schon seit der V2.1.4 gefixt sein. Dadurch das die Leiste permanent  mit dem mFi Server reden will stoppt und startet sie einige Prozesse im 100 Sekunden Takt ( = 10 Fehlversuche , ein Versuch alle 10 Sekunden) Das führt dann jedesmal dazu das sich die Leiste komplett vom WLAN abmeldet und nach einiger Zeit neu anmeldet. FHEM bekommt das auch mit, daher finde ich pro Tag auch etliche Timeout Meldungen im FHEM Log :(

OK, wenn die Leiste von Haus aus so gesprächig ist und sich das nicht abschalten lässt warum dann den Nachteil nicht in einen Vorteil Verwandeln ? D.h. ich werde mal schauen was ich über die Kommunikation zischen mPower und mFi in Erfahrung bringen kann und ob man die mFi Grundfunktionen nicht ins FHEM Modul packen kann, dann bräuchte man die Leiste auch nicht mehr alle X Minuten anpollen um immer den aktuellen Status zu haben.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 04 Mai 2015, 10:40:45
@wzut:
Dort ist das Protokoll beschrieben.
https://github.com/mcrute/ubntmfi/blob/master/inform_protocol.md
Ob du dir das antun möchtest?

Leider habe ich auch die permanenten Wlan Abbrüche und bin bei Recherchen fündig geworden.
Schuld ist der immer neu startende mcad Prozess der auch das Neustarten mit /usr/etc/syswrapper.sh restart-wpasupplicant auslöst.

Das hat allerdings nur Auswirkungen auf das WPA und WPA2 Wlan-Protokoll.  Ich habe darum bei meinem Mikrotik Accesspoint zusätzlich ein WLAN mit WEP64 eingerichtet und der mcad Prozess der Leiste startet zwar immer noch neu aber die Verbindungsabbrüche sind Geschichte.

Ich hatte auch sehr auf eine neue Firmware gehofft, die das Neustarten der wpa_supplicant ohne Controllerverbindung behebt.


May  4 10:00:48 mFi-mPowerMini-D25DFE user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-mcad
May  4 10:03:05 mFi-mPowerMini-D25DFE user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-mcad
May  4 10:05:22 mFi-mPowerMini-D25DFE user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-mcad
May  4 10:07:40 mFi-mPowerMini-D25DFE user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-mcad
May  4 10:09:57 mFi-mPowerMini-D25DFE user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-mcad
May  4 10:12:14 mFi-mPowerMini-D25DFE user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-mcad
May  4 10:14:32 mFi-mPowerMini-D25DFE user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-mcad
May  4 10:16:49 mFi-mPowerMini-D25DFE user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-mcad
May  4 10:19:06 mFi-mPowerMini-D25DFE user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-mcad
May  4 10:21:25 mFi-mPowerMini-D25DFE user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-mcad
MF.



Ein anderer Workaround ist die offizielle Verwendung der /etc/persistent/rc.poststart.
Diese Datei wird 180 Sekunden nach dem Neustart der Leiste ausgeführt.

http://community.ubnt.com/ubnt/attachments/ubnt/mFi/5298/1/2.0.7%20new%20feature%20detail.pdf


Z.B. Habe ich folgendes getestet. (Quick and dirty..)

Inhalt: /etc/persistent/rc.poststart   (chmod +x nicht vergessen)
#echo 0 > /proc/power/output1
/bin/cp /etc/persistent/inittab /etc/inittab
/sbin/init -q
/sbin/pkill -9 syslogd
/sbin/pkill -9 mcad
/sbin/pkill -9 mca-monitor
/sbin/pkill -9 ubnt-websockets
/sbin/pkill -9 upnpd

Datei /etc/persistent/inittab
null::respawn:/bin/dropbear -F -d /var/run/dropbear_dss_host_key -r /var/run/dropbear_rsa_host_key -p 22
null::respawn:/bin/infctld
null::respawn:/bin/syslogd -n -O /var/log/messages -l 8 -s 200 -b 0
null::respawn:/sbin/udhcpc -f -i ath0 -V ubnt -A 10 -s /etc/udhcpc/udhcpc -p /var/run/udhcpc.ath0.pid -h "mFi-mPowerMini-D25DFE"
null::respawn:/bin/lighttpd -D -f /etc/lighttpd.conf
null::respawn:/bin/ubnt-websockets
null::respawn:/bin/ubnt-websockets --ssl -p 7682
null::respawn:/bin/telnetd -F -p 23
null::respawn:/bin/wpa_supplicant -D atheros -i ath0 -c /etc/wpasupplicant_WPA-PSK.conf
null::respawn:/sbin/ntpclient -n -s -c 0 -l -h pool.ntp.org
null::respawn:/bin/crond -f -S
#null::respawn:/bin/mcad
#null::respawn:/bin/mca-monitor
null::respawn:/usr/bin/wevent

Nach dem Ändern/Erstellen ein
save
reboot
nicht vergessen.



Erklärung:
Es wir eine neue inittab installiert die die 2 Prozesse nicht mehr startet. Und damit ist Ruhe.
Was die mcad und mca.monitor machen ist mir noch nicht klar.
Ich für meinen Teil lasse die Leisten im eigenen WEP64 Wlan Netz.



Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 04 Mai 2015, 11:05:23
Zur Info.
Ein wichtiges Script in der Leiste:
/usr/etc/syswrapper.sh

#!/bin/sh

#linker...  comment out below debugging code for now(bottom page also).  /var/log/admin fills up
# and cause node to stop functioning.  Talk to Mike about how to recyle this file so we can
# also retain some debug info on released nodes.
#set -x
#exec 2>>/var/log/admin
##exec 2>>/dev/console
COMMAND_LINE="$0 $@"
#echo "BEGIN SYSWRAPPER CMD: ${COMMAND_LINE}" >&2

log() {
logger -s -t "syswrapper" "$*"
}

exit_if_fake() {
if [ "`uname -a | grep mips`" = "" -o -f "/tmp/FAKE" ] ; then
# fake, simply dump it to console and exit 0
logger -s -t "syswrapper" "[fake] skipping $*"
exit 0
fi
}

set_state() {
echo $1 > /var/run/system.state
}

set_led() {
status=$1
freq=$2
locating="false"
if [ -f /proc/ubnthal/status/IsLocated ]; then
locating=`cat /proc/ubnthal/status/IsLocated`
fi
if [ -f /var/etc/persistent/cfg/mgmt ] ; then
led_disabled=`grep mgmt.led_enabled=false /var/etc/persistent/cfg/mgmt`
fi
if [ -z "$led_disabled" ] || [ "$locating" == "true" ]; then
# use new policy of not indicating controller status, at least if in-wall devices
BOARD=$(cat /etc/board.info | sed -n -r -e "s/board.shortname=(.*)\$/\1/p")
if [ "$BOARD" == "IWD1U" ] || [ "$BOARD" == "IWO2U" ] ; then
#if [ $status -eq 1 -a $freq -eq 1 ] ; then
if [ $status -eq 1 -a $freq -eq 1 ] ; then
freq=0
fi
fi
echo $status > /proc/led/status
echo $freq > /proc/led/freq
else
echo 0 > /proc/led/status
echo 0 > /proc/led/freq
fi
}


lockfile() {
TEMPFILE="$1.$$"
LOCKFILE="$1.lock"
( ( echo $$ > $TEMPFILE ) > /dev/null 2>&1 ) || \
{
log "[permission denied] fail to lock $1"
return 1
}
ln $TEMPFILE $LOCKFILE > /dev/null 2>&1 && \
{
rm -f $TEMPFILE
return 0
}
kill -0 `cat $LOCKFILE` > /dev/null 2>&1 && \
{
rm -f $TEMPFILE
return 1
}
log "[stale lock] removing stale lock file"
rm -f $LOCKFILE
ln $TEMPFILE $LOCKFILE > /dev/null 2>&1 && \
{
rm -f $TEMPFILE
return 0
}
rm -f $TEMPFILE
return 1
}

state_lock() {
until lockfile /var/run/system.state; do
log "[state is locked] waiting for lock"
sleep 1
done
trap "state_unlock" EXIT
}

# baud doesn't matter here, since serial sets it directly
# setting 7DATABITS and EVEN | ODD parity will cause ser2net to set them in software
#  parity NONE with 7DATABITS isn't supported, since Hornet only supports 8 data bits
# ser2net.conf is supported here to allow config like 7DATABITS, EVEN|ODD parity, and RAW mode
start_ser2net() {
if [ -f /etc/persistent/ser2net.conf ] ; then
/usr/bin/ser2net -c /etc/persistent/ser2net.conf
else
/usr/bin/ser2net -C "2323:telnet:0:/dev/ttyS0:115200"
fi
if [ -f /usr/etc/mfi/ser2net.cgi ] ; then
cgi -q /usr/etc/mfi/ser2net.cgi
fi
}

state_unlock() {
trap "" EXIT
/bin/rm -f "/var/run/system.state.lock"
}

# obtain lock first
set_state_ready() {
set_state 'ready'
state_reload
}

exit_if_busy() {
if [ -f /var/run/system.state ] ; then
state=`cat /var/run/system.state`
if [ "$state" != "ready" ] ; then
logger -s -t "syswrapper" "[busy] skipping: $*"
exit 0
fi
fi
}

# this would lock system state
exit_if_state_lock_failed() {
lockfile /var/run/system.state || \
{
log "[state is locked] skipping $*"
exit 0
}
trap "state_unlock" EXIT
}

# obtain lock first
state_reload() {
state="init"
default="true"
locating="false"
mcad_state="unknown"
mode=$(expr "`iwconfig ath0 | grep 'Mode:'`" : '.*Mode:\(M[a-z]*\)')
if [ -f /etc/counterfeit ]; then
set_led 4 4
return
fi
if [ -f /proc/ubnthal/status/IsDefault ]; then
default=`cat /proc/ubnthal/status/IsDefault`
fi
if [ -f /proc/ubnthal/status/IsLocated ]; then
locating=`cat /proc/ubnthal/status/IsLocated`
fi
if [ -f /var/run/system.state ] ; then
state=`cat /var/run/system.state`
fi
if [ -f /var/run/mcad.state ] ; then
mcad_state=`cat /var/run/mcad.state`
fi
if [ "$state" == "upgrading" ]; then
# echo upgrading
set_led 4 1
return
fi
if [ "$locating" == "true" ]; then
if [ "$default" == "true" ]; then
# echo default-locating
set_led 2 4
else
# echo locating
set_led 1 4
fi
return
fi

if [ -f /var/run/system.selfrun ]; then
# echo eth-selfrun
set_selfrun
#set_led 1 0
#return
else
# echo eth-managed
unset_selfrun
#set_led 1 0
#return
fi
#if [ "$state" == "ready" ]; then
# echo ready
#set_led 1 0
#return
#fi


if [ "$mcad_state" == "managed" ]; then
set_led 1 0
return
else
# not connected to the server
if [ -f /var/run/wificonfigured.ath0 ]; then
if [ -f /var/run/wifiready.ath0 ]; then
# wifi connected
count=0
        if [ -f /var/etc/persistent/cfg/mgmt ] ; then
count=`grep -c mgmt.servers /var/etc/persistent/cfg/mgmt`
        fi
if [ $count -gt 0 ]; then
set_led 1 1
else
# if controller is not configured
set_led 1 0
fi
else
# wifi is hunting
set_led 2 1
fi
# blink wifi status over DEFAULT state
return
else
# no wifi is configured
set_led 1 2
fi
fi
if [ "$default" == "true" ]; then
# echo default-ready
set_led 2 0
return
fi

# echo $state
#set_led 2 1
}

set_selfrun() {
if [ -f /var/run/system.selfrun.lock ]; then
return
fi
touch /var/run/system.selfrun.lock
if [ -f /var/run/system.selfrun_guest_pass ]; then
# echo selfrun-guest
exit_if_no_guest_portal
# bypass the guest authorization
ebtables -t nat -F AUTHORIZED_GUESTS
ebtables -t nat -A AUTHORIZED_GUESTS -j ACCEPT
fi
}

unset_selfrun() {
if [ -f /var/run/system.selfrun.lock ]; then
rm -f /var/run/system.selfrun.lock
if [ -f /var/run/system.selfrun_guest_pass ]; then
# echo unset-selfrun-guest
# re-enforce the guest authorization
rm /var/run/guest.authorized
authorized_guests_updated /var/run/guest.authorized
fi
fi
}
analog_off() {
if [ -f /usr/www/mfi/disable_analog.cgi ] ; then
cgi -q /usr/www/mfi/disable_analog.cgi
fi
}
disable_proc_power() {
if [ -d /proc/power/ ] ; then
#disable all outlet reading in the driver
for enabled in `ls /proc/power/enabled*`; do
# -99 means fw upgrade
echo -99 > $enabled
done
sleep 2
fi
}

wlan_overwrite_save() {
echo "wlan_overwrite_save" > /dev/ttyS0
cfgmtd -w -p /etc/persistent
}
# obtain lock first
cfg_save() {
set_state 'cfgupdate'
cfgmtd -w -p /etc /tmp/system.cfg
set_state_ready
}

# add_mac <file> <mac>
add_mac() {
del_mac "$1" "$2"
echo "$2" >> $1
}

# del_mac <file> <mac>
del_mac() {
file=$1
mac=$2
tmp=/tmp/macs.`basename $file`

grep -v "$mac" $file > $tmp
cp $tmp $file
}

# mac2serial <mac>
mac2serial() {
echo $1 | sed -e 's/://g' -e 'y/ABCDEF/abcdef/'
}

exit_if_no_guest_portal() {
portal_status=`cat /tmp/system.cfg|grep redirector.status=enabled`
if [ -z "$portal_status" ]; then
exit 0;
fi
}

# authorized_guests_updated
authorized_guests_updated() {
exit_if_no_guest_portal
ebtables -t nat -F AUTHORIZED_GUESTS
if [ -f $1 ]; then
ebtables -t nat -A AUTHORIZED_GUESTS --among-src `tr '\n' ',' < /var/run/guest.authorized` -j ACCEPT
fi
}

led_default() {
# was --> led: BOTH
echo 0 > /proc/led/freq
echo 2 > /proc/led/status
}

cmd="$1"
shift

case $cmd in
set-tmp-ip)
exit_if_fake $cmd $*
    echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
    echo 1 > /proc/sys/net/ipv4/conf/$1/arp_filter
;;
set-adopt)
# set-adopt <url> <authkey>
mca-ctrl -t connect -s "$1" -k "$2"
;;
set-channel)
# set-channel <radio> <channel>
# FIXME: dual radio
for ath in `ls /proc/sys/net/*/%parent | cut -d '/' -f 5`; do
iwconfig $ath channel $1
done
;;
ip-changed)
# ip-changed <interface> <ip>
    echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
    echo 1 > /proc/sys/net/ipv4/conf/$1/arp_filter
echo "$2" > /var/run/ipready.$1
echo "TODO notify processes that needs to know"
;;
led-locate)
exit_if_busy $cmd $*
# led-locate <duration>
/usr/bin/pkill led_locate.sh
# background this one so we'll return immediately
/usr/etc/led_locate.sh $1 &
;;
set-locate)
exit_if_busy $cmd $*
exit_if_state_lock_failed $cmd $*
/usr/bin/pkill led_locate.sh
echo "true" > /proc/ubnthal/status/IsLocated
state_reload
state_unlock
;;
unset-locate)
exit_if_busy $cmd $*
exit_if_state_lock_failed $cmd $*
/usr/bin/pkill led_locate.sh
echo "false" > /proc/ubnthal/status/IsLocated
state_reload
state_unlock
;;
scan)
exit_if_busy $cmd $*
/usr/bin/iwlist scan
;;
apply-config-nosave)
# apply-config <file>
analog_off
disable_proc_power
exit_if_busy $cmd $*
state_lock
/usr/etc/rc.d/rc restart
state_reload
state_unlock
;;
apply-config-save-reboot)
analog_off
disable_proc_power
exit_if_busy $cmd $*
state_lock
cfg_save "$1"
state_unlock
reboot
;;
apply-config)
# apply-config <file>
analog_off
disable_proc_power
exit_if_busy $cmd $*
state_lock
cfg_save "$1"
    sleep 2
/usr/etc/rc.d/rc restart
state_reload
state_unlock
;;
apply-config-mcad-setparam)
# apply-config-mcad-setparam <file>
# analog_off
# disable_proc_power
exit_if_busy $cmd $*
state_lock
cfg_save "$1"
#       sleep 2
/usr/etc/rc.d/rc restart-mcad-setparam
state_reload
state_unlock
;;
save-wlan-overwrite)
state_lock
wlan_overwrite_save
state_unlock
;;
save-config)
    state_lock
cfg_save
state_unlock
;;
reload)
exit_if_busy $cmd $*
exit_if_state_lock_failed $cmd $*
state_reload
state_unlock
;;
set-ready)
# called by mcagent
set_state_ready
;;
set-selfrun)
guestmode=$1
touch /var/run/system.selfrun
if [ "$1" == "off" ] ; then
# disable guest wlans
for ath in `cat /var/run/guest_devnames` ; do
ifconfig $ath down
done
else
exit_if_no_guest_portal
# bypass the guest authorization
ebtables -t nat -F AUTHORIZED_GUESTS
ebtables -t nat -A AUTHORIZED_GUESTS -j ACCEPT
fi
;;
unset-selfrun)
guestmode=$1
rm -f /var/run/system.selfrun
if [ "$1" == "off" ] ; then
# re-enable guest wlans
for ath in `cat /var/run/guest_devnames` ; do
ifconfig $ath up
done
else
# re-enforce the guest authorization
rm /var/run/guest.authorized
authorized_guests_updated /var/run/guest.authorized
fi
;;
restart)
exit_if_fake $cmd $*
exit_if_busy $cmd $*
echo 2 > /proc/led/status
echo 2 > /proc/led/freq
sleep 2
disable_proc_power
reboot
;;
iwd-default)
if [ -e /proc/power/dimmer_mode1 ] ; then
echo switch > /proc/power/dimmer_mode1
fi
rm /var/etc/persistent/cfg/iwd-default
cfg_save
;;
restore-default)
exit_if_fake $cmd $*
exit_if_busy $cmd $*
set_led 4 2
sleep 3
if [ -e /proc/power/dimmer_mode1 ] ; then
echo switch > /proc/power/dimmer_mode1
fi
sleep 2
disable_proc_power
    state_lock
led_default
# Erase the config partition
CFGPART="$(cat /proc/mtd | sed -n -r -e '/\"cfg\"/ { s/:.*//;s/mtd//;p }')"
tr '\000' '\377' </dev/zero | dd of=/dev/mtdblock${CFGPART} bs=1 count=$((0x40000))
reboot
#NB: trying to keep it locked until reboot to avoid race conditions
state_unlock
reboot
;;
download-firmware)
$0 _download-firmware "$1" &
;;
_download-firmware)
# downlaod-firmware <url>
wget -O /tmp/fwupdate.bin "$1" --tries=3 -c --timeout=30
cat /proc/uptime > /var/run/download_firmware.finished
;;
upgrade)
exit_if_fake $cmd $*
# upgrade <url>
wget -O /tmp/fwupdate.bin "$1" --timeout=30
fwupdate.real -c
if [ "$?" == "0" ] ; then
state_lock
set_state 'upgrading'
analog_off
disable_proc_power
/usr/etc/rc.d/rc stop
echo 1 > /proc/led/freq
echo 4 > /proc/led/status
fwupdate.real -m
set_state_ready
state_unlock
fi
;;
upgrade2)
exit_if_fake $cmd $*
# upgrade2
fwupdate.real -c
if [ "$?" == "0" ] ; then
exec 2>>/dev/console
/usr/etc/rc.d/rc stop
    state_lock
set_state 'upgrading'
echo 1 > /proc/led/freq
echo 4 > /proc/led/status
disable_proc_power
fwupdate.real -m
set_state_ready
    state_unlock
fi
;;

kick-serial)
# just a copy of apply-ser2net-cfg for now
killall ser2net
start_ser2net
;;

kick-sta)
exit_if_fake $cmd $*
for ath in `ls /proc/sys/net | grep ath` ; do
iwpriv $ath kickmac "$1"
done
;;
block-sta)
exit_if_fake $cmd $*
for ath in `ls /proc/sys/net | grep ath` ; do
iwpriv $ath addmac "$1"
iwpriv $ath kickmac "$1"
done
add_mac /etc/persistent/cfg/blocked_sta "$1"
state_lock
cfg_save
state_unlock
;;
unblock-sta)
exit_if_fake $cmd $*
for ath in `ls /proc/sys/net | grep ath` ; do
iwpriv $ath delmac "$1"
done
del_mac /etc/persistent/cfg/blocked_sta "$1"
state_lock
cfg_save
state_unlock
;;
apply-blocked-sta)
for ath in `ls /proc/sys/net | grep ath` ; do
# clear the acl
iwpriv $ath maccmd 3
# add acl
for mac in `cat /etc/persistent/cfg/blocked_sta` ; do
iwpriv $ath addmac "$mac"
done
done
;;
authorize-guest)
exit_if_fake $cmd $*
add_mac /var/run/guest.authorized $1
authorized_guests_updated /var/run/guest.authorized
;;
unauthorize-guest)
exit_if_fake $cmd $*
del_mac /var/run/guest.authorized $1
authorized_guests_updated /var/run/guest.authorized
;;
apply-authorized-guests)
exit_if_fake $cmd $*
if [ "`cat /var/run/guest.authorized`" != "" ] ; then
authorized_guests_updated /var/run/guest.authorized
fi
;;
clear-authorized-guests)
exit_if_fake $cmd $*
rm -f /var/run/guest.authorized
authorized_guests_updated /var/run/guest.authorized
;;
kill-cgi)
log "kill-cgi. reason: $*"
killall -9 cgi
sleep 1
;;
kill-mcad)
log "kill-mcad. reason: $*"
killall -9 mcad
    rm -f /var/run/mcad.setparam
sleep 1
# rely on /etc/inittab to start it
;;
set-led)
set_led $1 $2
;;
set-rmsSum)
    echo $1 > $2
    ;;
apply-port-nooutput-cfg)
# linker...
# configure port direction/modes
if [ -f /usr/etc/mfi/port_config.cgi ] ; then
cgi -q /usr/etc/mfi/port_config.cgi
fi
# initialize/configure/writing shift register value for gpio power
if [ -f /usr/sbin/ubnt-sr-cfg ] ; then
sed -i "s/\(DO[.0-9]*volt\=[0-9]*\)//" /etc/persistent/cfg/digital_cfg
/usr/sbin/ubnt-sr-cfg -i
fi
;;
apply-port-cfg)
# linker...
# configure port direction/modes
if [ -f /usr/etc/mfi/port_config.cgi ] ; then
cgi -q /usr/etc/mfi/port_config.cgi
fi
# initialize/configure/writing shift register value for gpio power
if [ -f /usr/sbin/ubnt-sr-cfg ] ; then
/usr/sbin/ubnt-sr-cfg -i
fi
;;
apply-device-cfg)
if [ -f /usr/etc/mfi/device_config.cgi ] ; then
cgi -q /usr/etc/mfi/device_config.cgi
fi
;;
restart-mcad)
pkill -9 mcad
rm -f /var/run/mcad.setparam
;;
restart-wpasupplicant)
pkill -9 wpa_supplicant
;;
refresh-ap-bssid)
(expr "`iwconfig ath0 | grep 'Access Point:'`" : '.*Access Point: \([^ ]*\)') > /tmp/ap_mac
;;
kill-ath-dhcp)
# kill only the wifi dhcpc
ps | grep udhcpc | grep ath0 | awk '{print $1}' | xargs kill
;;
kill-eth-dhcp)
# kill only the Ethernet dhcpc
ps | grep udhcpc | grep eth0 | awk '{print $1}' | xargs kill
;;
disable-analog)
analog_off
;;
apply-analog-cfg)
# linker...
# configure analog ports
if [ -f /usr/etc/mfi/analog_config.cgi ] ; then
cgi -q /usr/etc/mfi/analog_config.cgi
fi
;;
apply-vpower-norelay-cfg)
# configure vpower ports
if [ -f /usr/etc/mfi/vpower_config.cgi ] ; then
sed -i "s/\([a-z.0-9]*relay\=[0-9]\)//" /etc/persistent/cfg/vpower_cfg
    cgi -q /usr/etc/mfi/vpower_config.cgi
fi
;;
apply-vpower-cfg)
# configure vpower ports
if [ -f /usr/etc/mfi/vpower_config.cgi ] ; then
    cgi -q /usr/etc/mfi/vpower_config.cgi
fi
;;
apply-power-on-defaults)
if [ -f /usr/etc/mfi/default_config.cgi ] ; then
    cgi -q /usr/etc/mfi/default_config.cgi
fi
;;
preserve-vpower-output)
sed -i 's/vpower.'${1}'.relay\=[0-9]*/vpower.'${1}'.relay\='${2}'/' /etc/persistent/cfg/config_file
sed -i 's/vpower.'${1}'.relay\=[0-9]*/vpower.'${1}'.relay\='${2}'/' /etc/persistent/cfg/vpower_cfg
;;
process-wlan-overwrite)
#echo "process-wlan-overwrite" > /dev/ttyS0
if [ -f /tmp/wlan_overwrite ] ; then
cp /tmp/wlan_overwrite /etc/persistent/cfg/wlan_overwrite.cfg
rm /tmp/wlan_overwrite
cfg_save
fi
;;
set-vpower-output)
echo $1 > /proc/power/relay$2
;;
apply-ser2net-cfg)
killall ser2net
# maybe we shouldn't restart ser2net here? 
start_ser2net
;;
apply-serial-cfg)
if [ -f /etc/persistent/cfg/serial_cfg ] ; then
speed=`cat /etc/persistent/cfg/serial_cfg | grep -m 1 speed | cut -d \= -f 2`
if [ "$speed" == "" ] || [ "$speed" == "default" ] ; then
speed="115200"
fi
destination=`cat /etc/persistent/cfg/serial_cfg | grep -m 1 destination | cut -d \= -f 2`
if [ "$destination" == "" ] || [ "$destination" == "default" ] ; then
destination="remote"
fi
else
speed="115200"
destination="remote"
fi
if [ "$speed" != "off" ] ; then
/usr/bin/stty $speed < /dev/ttyS0
if [ "$destination" == "flash" ] ; then
# kill ser2net if it is running
killall ser2net
# start flash/serial if it is not running
pid=`ps | grep "location.cgi" | grep -v grep | cut -d" " -f 3`
if [ "$pid" == "" ] ; then
/usr/bin/cgi -q /etc/persistent/bin/location.cgi &
fi
pid=`ps | grep "inform.cgi" | grep -v grep | cut -d" " -f 3`
if [ "$pid" == "" ] ; then
/usr/bin/cgi -q /etc/persistent/bin/inform.cgi &
fi
#elif [ "$destination" == "console" ] ; then
# need to dynamically add console, but inittab isn't friends to this
else
# kill flash/serial if it is running
pid=`ps | grep "serial.cgi" | grep -v grep | cut -d" " -f 3`
if [ "$pid" != "" ] ; then
kill $pid
fi
fi
else
killall ser2net
pid=`ps | grep "serial.cgi" | grep -v grep | cut -d" " -f 3`
if [ "$pid" != "" ] ; then
kill $pid
fi
fi
;;
gen-sup)
filename=$1
if [ -z "$filename" ]; then
filename=support_info.tgz
fi
file=/tmp/$filename
dirname=support_info
ddir=/tmp/$dirname
rm -rf $ddir
rm -rf $file
mkdir -m 0755 $ddir

cp /tmp/sysinit.txt $ddir
cp /etc/board.info $ddir
cp /tmp/system.cfg $ddir
cp /usr/lib/version $ddir
ifconfig -a > $ddir/ifconfig.txt
iwconfig > $ddir/iwconfig.txt
athstats > $ddir/athstats.txt
80211stats -a > $ddir/80211stats.txt
wlanconfig ath0 list > $ddir/wlist.txt
dmesg -s 16384 > $ddir/dmesg.txt
ps > $ddir/ps.txt
log_status=`cat /tmp/system.cfg|grep syslog.status=enabled`
if [ -n "$log_status" ]; then
log_file=`cat /tmp/system.cfg|grep syslog.file|cut -d= -f2`
if [ -z "$log_file" ]; then
log_file=/var/log/messages
fi
log_rotate=`cat /tmp/system.cfg|grep syslog.rotate|cut -d= -f2`
if [ -z "$log_rotate" ]; then
log_rotate=0
fi
while [ $log_rotate -gt 0 ]; do
log_rotate=`expr $log_rotate - 1`
cat $log_file.$log_rotate >> $ddir/syslog.txt
done
cat $log_file >> $ddir/syslog.txt
fi
cp /proc/meminfo /proc/slabinfo /proc/loadavg /proc/vmstat /proc/modules /proc/kallsyms /proc/net/arp $ddir
dd if=/dev/mtdblock`cat /proc/mtd |grep cfg|cut -d: -f1|cut -dd -f2` of=$ddir/part.cfg > /dev/null 2>&1
dd if=/dev/mtdblock`cat /proc/mtd |grep EEPROM|cut -d: -f1|cut -dd -f2` of=$ddir/part.cfg > /dev/null 2>&1
tar -C /tmp -zcf $file $dirname
;;
restore-ap)
state_lock
led_default
cp /etc/default.cfg /tmp/system.cfg
#cfg_save /tmp/system.cfg
state_unlock
/usr/etc/rc.d/rc restart_wifi
    ;;
restore-captiveportal)
# killall watch.sh
state_lock
led_default
cp /etc/default.cfg /tmp/system.cfg
#cfg_save /tmp/system.cfg
state_unlock
/usr/etc/rc.d/rc restart_captiveportal
    ;;
*)
exit 1
;;
esac


Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 04 Mai 2015, 11:11:26
Danke für die Protokoll Infos , werde mich mal einlesen.

Ich für meinen Teil lasse die Leisten im eigenen WEP64 Wlan Netz.

hmm hmm eigentlich dachte ich die Zeiten in denen man WEP benötigt seien endgültig vorbei :(
Ich habe seit gestern einen andern Weg am Start der auch gut auschaut :
Auf dem Raspi auf dem auch das FHEM für die Ubi läuft habe ich zuerst die mongo DB installiert und danach die die Unix Version der mFi Controller Software. Nun ist seit gestern Abend auch Ruhe mit den WLAN Abbrüchen.
(Vllt auch noch ein Abschnitt im Wiki wert ? Zumal die Einrichtung der mongo DB nicht ganz so einfach ist und auch einiges an Zeit zum compilieren  benötigt)   
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 05 Mai 2015, 08:21:10
Hallo wzut,

hattest du mal die Config Datei direkt Editiert und den Controller rausgenommen?
Hatte ich hier mal zwischendrin geschrieben.
Bei mir lief das anschliessend viel besser. Als ich dann noch auf einen freien WLAN Kanal gewechselt bin war alles ruhig.

Nico
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 05 Mai 2015, 10:06:49
Einfach mit vi /etc/persistent/cfg/mgmt die 2. Zeile mit dem Server Eintrag löschen.

habe ich allen Spielarten die im Ubnt Forum beschrieben sind durch und wie gesagt das Prob sollte eiegntlich seit V2.1.4 gefixt sein
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 14 Mai 2015, 13:09:02
Hallo Wzut.
Die Gewittersaison ist engelangt und gestern hatten wir den 1. Stromausfall.
Nach dem Neustart der 3-Port Version ( FW:2.1.8 ) hat die Leiste ihre kleinen Konfigurationen verloren. Die Leiste wird ohne Controller betrieben.

Ich hatte die Locks gesetzt und die alles auf enabled (damit die Energy-Werte gezählt werden - cf_countX).




Lösung:
Das Fhem Modul müsste die letzten Zustände vor dem Stromausfall speichern und danach einfach wieder setzen.


So kann man das testen.

echo 1 >/proc/power/enabled1
echo 1 >/proc/power/lock1
reboot 

Nach dem Neustart stehen beide Werte wieder auf 0.


Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 14 Mai 2015, 15:43:41
Das Fhem Modul müsste die letzten Zustände vor dem Stromausfall speichern und danach einfach wieder setzen.
Das ist kein Problem, der letzte bekannte Zustand steht ja im jeweiligen Reading und ob die Ubi einen Neustart hinter sich hat sieht man daran das die Uptime irgendwann kleiner ist als der letzte Wert im reading. Ich würde dafür dennoch ein neues Attribut spendieren -> restoreOnReboot oder so , bei irgend einem fhem Modul (Firmata, GPIO4 ??) kann ich mich dunkel an so ein Attribut erinnern, muß ich mal nachschauen.

Meine 3er mPower hat nun schon einige "Stromausfälle" hinter sich (Sicherungsautomat des betroffenen Raumes raus wegen Renovierungsarbeiten) und hat dabei noch nie ihre  enable und lock Bits "vergessen" allerdings meldet sie sich genau wie ihr kleiner Bruder , eine mPower mini am mFi Kontroller auf dem Raspberry an.
 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: guido_s am 23 Mai 2015, 13:54:55
Habe eben gerade ein UPDATE gefahren und dann versucht meinen mPort6 zu definieren.
Seitdem stürzt mein lieber PERL Interpreter einfach ab. Das passiert genau an dem Punkt, an dem das Device initialisiert ist.

Nehme ich das Device wieder raus, ist alles ok.

Zu sehen ist noch:
keys on reference is experimental at ./FHEM/98_UbiquitiMP.pm line 553.

Hat irgendwer ne Idee?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 23 Mai 2015, 18:22:25
in der "bösen" Zeile steht
my $sensors = scalar keys $json->{sensors};hier wird aus der ersten Antwort der Ubi versucht festzustellen wieviele Ports diese hat. Wenn du  nur 6er Ubis im Einsatz hast kannst
du diese Zeile abändern auf :
my $sensors = 6;dann sollte es zumindest wieder laufen bis ich eine Lösung habe die mit der aktuellen fhem Version nicht mehr kollidiert
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 30 Mai 2015, 10:08:11
Halo Wzut.
Nachdem ich den Haupt-Fhem auf meinen Solaris Server verlegt habe bekomme ich  den Fehler auch.

Unterhalb Perl 5.12 ist das wohl der Grund.
http://perldoc.perl.org/functions/keys.html

Am Solaris läuft Das Perl/csw 5.10.

Gruss


Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 30 Mai 2015, 20:13:36
versuch doch bitte mal
my $sensors = keys $json->{sensors};
d.h. einfach das scalar weglassen, wenn das dann ohne Fehler durchgeht werde ich es nach meinem Urlaub so einchecken.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 31 Mai 2015, 01:12:00
versuch doch bitte mal
my $sensors = keys $json->{sensors};
d.h. einfach das scalar weglassen, wenn das dann ohne Fehler durchgeht werde ich es nach meinem Urlaub so einchecken.

Geht leider auch nicht unter Perl 5.10.x.
Ich habe  am Solaris gerade zusätzlich Perl 5.20.2 installiert - dort läuft beides.

Gruss
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: DerBodo am 28 Juni 2015, 13:43:32
Hallo,

ich habe inzwischen 6 mPower Pro im Einsatz, soweit funktioniert auch alles ganz gut. Allerdings ist mir gestern etwas aufgefallen.
An Leiste 1 hatte ich bereits seit längerem eine Gruppe definiert. Hier funktionierte da schalten einwandfrei.
Gestern habe ich an Leiste 2 insgesamt 2 neue Gruppen mit aufgenommen.Nun lässt sich die Gruppe 1 nicht mehr schalten und ist auch nicht im Dropdown auswählbar.
Das Attribut ist weiterhin vorhanden.

List Leiste 1:
Internals:
   BNAME      mPower Pro
   Clients    :UbiquitiOut:
   DEF        YYY.YYY.YYY.YYY
   ERRORCOUNT 0
   INTERVAL   300
   MAC        24AXXXXXXXXXXXX
   NAME       mFi_Besta
   NR         453
   PORTS      6
   SNAME      P6E
   STATE      on off on on on on
   TYPE       UbiquitiMP
   VERSION    2.1.8
   force      0
   group_ALL  1,2,3,4,5,6
   group_TV 1,3,4


List Leiste 2:
BNAME      mPower Pro
   Clients    :UbiquitiOut:
   DEF        XXX.XXX.XXX.XXX
   ERRORCOUNT 0
   INTERVAL   30
   MAC        041XXXXXXX
   NAME       mFi_Studio
   NR         509
   PORTS      6
   SNAME      P6E
   STATE      off on on on on on
   TYPE       UbiquitiMP
   VERSION    2.1.8
   force      0
   group_ALL  1,2,3,4,5,6
   group_X 3,4
   group_Y 2,3,4

In den DropDowns zum set sehe ich in beiden Leiste jeweils die zuletzt angelegten Gruppen. Und nicht die für das jeweilige Device.

Gruß

Bodo
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 28 Juni 2015, 18:20:13
fhem shutdown - restart gemacht ?
Die Gruppenliste wird nur beim Start richtig aufgebaut 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: DerBodo am 28 Juni 2015, 21:30:31
Ja, soeben zum test erneut gemacht.

TV_SAT von Leiste 1 fehlt weiterhin, in Leiste 1 sehe ich nur die Gruppen von Leiste 2.
Schalten über den Gruppennamen geht auch nicht.


Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 02 Juli 2015, 09:09:22
Hallo. Ich wollte fragen ob das Modul noch weiter entwickelt wird und ob man es produktiv nutzen kann. Ich habe vor mir einige dieser Mehrfachsteckdosen zu holen. Hauptsächlich die 6er Wifi Versionen.


Grüße
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 02 Juli 2015, 13:41:14
Sicher wenn es am Modul noch etwas zu tun gibt dann mache ich das.
Und ja mann kann die Ubis aktiv nutzen - zumindest laufen meine beiden jetzt seit Monaten ohne Probleme.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: markoweb am 02 Juli 2015, 22:01:24
Hallo,

es haben ja einige die mpower's im Einsatz. Könnte mal jemand schauen ob die Daten der Energiemessungen/Summen Sinn machen? Dazu reicht es das Standard-UI zu benutzen, es muss nichts in FHEM gemacht werden...

Im Detail geht es um folgendes:

Einfach mal einen Verbraucher mit einem Powerfaktor != 1 (also keine Glübirne, sondern irgendein elektronisches Gerät) einen Tag laufen lassen.

Nehmen wir an das Gerät braucht 10 Watt. Dann sollte nach 24h in etwa 240 Wattstunden verbraucht worden sein. Richtig? Und das müsste dann auch ganz rechts in der Spalte ("Jul (kW·H)") als Delta zu erkennen sein, oder? Könnte das mal jemand beobachten?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 03 Juli 2015, 09:33:19
läuft bei mir zwar nicht 24 Stunden am Tag durch , aber wenn enable = 1 ist : ja
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: DerBodo am 04 Juli 2015, 14:18:08
@Wzut, hättest du noch eine Idee/einen Tipp für mich bzgl. des Gruppenproblems ?

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 05 Juli 2015, 14:46:32
 Leider nein da ich das Problem nicht nachstellen kann.
Poste doch bitte mal die Ausgabe wenn du in der Kommandozeile "set mFi_Besta ?"  und "set mFi_Studio ?" eingibst.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: DerBodo am 05 Juli 2015, 17:20:32
Hallo Wzut,

ein set mFi_Besta ergibt:
Unknown port ?, choose one of ALL Bodo Bodo_Steffi Out1 Out2 Out3 Out4 Out5 Out6

Für mFi_Studio:
Unknown port ?, choose one of ALL Bodo Bodo_Steffi Out1 Out2 Out3 Out4 Out5 Out6

Gruß

Bodo
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 05 Juli 2015, 19:33:21
D.h. beide Ubis kennen jeweils die Gruppe Bodo und Bodo_Steffi. Das passt so nun aber gar nicht zu dem was du zuerst gepostet hast !
Also bitte nun ohne wieder was zu ändern : wie schauen deine beiden Definitionen in der fhem.cfg aus ? bzw. das jeweilige attr groupPorts ?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: DerBodo am 05 Juli 2015, 20:17:37
Fhem.cfg Abschnitt zu mFi_Besta:

define mFi_Besta UbiquitiMP xxx.xxx.xxx.xxx
attr mFi_Besta groupPorts TV_Sat=1,3,4
attr mFi_Besta password xxxx
attr mFi_Besta room 07_Energie
attr mFi_Besta subDevices 1
attr mFi_Besta timeout 5
attr mFi_Besta user XXXX


zu mFi_Studio:

define mFi_Studio UbiquitiMP xxx.xxx.xxx.xxx
attr mFi_Studio groupPorts Bodo_Steffi=2,3,4 Bodo=3,4
attr mFi_Studio interval 30
attr mFi_Studio password xxx
attr mFi_Studio room 07_Energie
attr mFi_Studio subDevices 1
attr mFi_Studio timeout 5
attr mFi_Studio user xxx

Jedes Device hat seine Gruppen eingerichtet, gesehen werden aber aktuell nur Bodo_Steffi und Bodo. Diese hatte ich zuletzt definiert.
Wenn ich nun TV_Sat als Gruppe an der anderen Leiste einrichte, verschwinden die beiden anderen Gruppen.

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 06 Juli 2015, 07:41:58
OK, verstanden und nun ist mir auch klar was da passiert ... war ein Denkfehler von mir wie das im Modul umgesetzt ist.
Bis ich da eine neue Version nachschieben kann bleibt dir leider nur der Weg an allen Leisten alle Gruppen zu definieren, d.h in deinem Fall :
groupPorts TV_Sat=1,3,4  Bodo_Steffi=2,3,4 Bodo=3,4
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: DerBodo am 06 Juli 2015, 08:19:28
Alles klar vielen Dank !

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 08 Juli 2015, 20:23:13
So habe mir nun so ein 6er mPowerPro bei eBay geholt. Werde es mal testen   ;D
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 10 Juli 2015, 09:07:41
Das ist kein Problem, der letzte bekannte Zustand steht ja im jeweiligen Reading und ob die Ubi einen Neustart hinter sich hat sieht man daran das die Uptime irgendwann kleiner ist als der letzte Wert im reading. Ich würde dafür dennoch ein neues Attribut spendieren -> restoreOnReboot oder so , bei irgend einem fhem Modul (Firmata, GPIO4 ??) kann ich mich dunkel an so ein Attribut erinnern, muß ich mal nachschauen.

Meine 3er mPower hat nun schon einige "Stromausfälle" hinter sich (Sicherungsautomat des betroffenen Raumes raus wegen Renovierungsarbeiten) und hat dabei noch nie ihre  enable und lock Bits "vergessen" allerdings meldet sie sich genau wie ihr kleiner Bruder , eine mPower mini am mFi Kontroller auf dem Raspberry an.
 

Hallo Wzut.
Da ich die  Dosen ja ohne Controller betreibe wäre eine soches restoreOnReboot perfekt.
So vergessen die Dosen leider die enable, lock Bits und auch die Schaltzustände. Es werden alle Ports nach einem Ausfall eingeschalten.
Gruß
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 10 Juli 2015, 09:32:47
So nun bin ich mal zum testen gekommen. Habe ne 6er Wifi und ich muß sagen das ich recht zufrieden bin. Hin und wieder hängt mal was aber das ist eher selten und mehr meiner spielerei bestimmt geschuldet.
So ein Attribut für den letzten Zustand hätte ich auch gerne. Auch bei mir gehen alle Devices nach einem Stromausfall auf on.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 11 Juli 2015, 20:15:36
2015.07.11 15:35:16 1: Error: mFimPower01_OUT1 has no TYPE
2015.07.11 15:35:16 1: Error: mFimPower01_OUT3 has no TYPE
2015.07.11 15:35:16 1: Error: mFimPower01_OUT5 has no TYPE
2015.07.11 15:35:16 1: Error: mFimPower01_OUT1 has no TYPE
2015.07.11 15:35:16 1: Error: mFimPower01_OUT3 has no TYPE
2015.07.11 15:35:16 1: Error: mFimPower01_OUT5 has no TYPE
2015.07.11 15:35:16 1: Error: mFimPower01_OUT1 has no TYPE
2015.07.11 15:35:16 1: Error: mFimPower01_OUT3 has no TYPE
2015.07.11 15:35:16 1: Error: mFimPower01_OUT5 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT1 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT3 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT5 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT1 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT3 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT5 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT1 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT3 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT5 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT1 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT3 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT5 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT1 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT3 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT5 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT1 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT3 has no TYPE
2015.07.11 15:35:17 1: Error: mFimPower01_OUT5 has no TYPE

Jemand ne Idee wo ich da ansetzen kann? Also entweder hat das was damit zu tun das die Devices in einer Structure oder in einer LightScene sind. Oder weil ich die mal als Gruppe hatte und wieder gelöscht hab.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 12 Juli 2015, 09:27:05
Meldungen dieser Art hatte ich noch nie. Kannst du mal genau beschreiben was du gemacht hast und wann dann diese Meldungen aufgetaucht sind ?
Gruppen anlegen und löschen kann ich ausschliessen da ich das in den letzten Tagen mehrfach gemacht habe, aber  Structure und LightScene habe ich noch nie benutzt.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 14 Juli 2015, 09:48:27
Fix : bei Verwendung von attr groupPorts und mehreren Dosen beinflussen sich die definierten Gruppen nicht mehr gegenseitig.

Update : neues Reading rebooted
Es wird bei jeder Abfrage die Uptime der Dose ausgewertet. Ist diese kleiner als die des letzten Zyklus wird das Reading rebooted auf 1 gesetzt. Kann man dann in einem notify weiter verwenden um ggf. nach einem Reboot der Dose Ports abzuschalten oder die Verbrauchsmessung wieder ein.

Bitte die hier angehängte Version testen, wenn alles OK ist werde ich diese dann später einchecken.   
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: DerBodo am 17 Juli 2015, 19:32:30
Werde die neue Version mal testen und dann die Tage ein Feedback posten.

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: DerBodo am 21 Juli 2015, 07:31:26
Die Gruppen lassen sich nun Problemlos schalten.
Aus meiner Sicht passt nun alles.

DANKE !
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 21 Juli 2015, 08:29:37
Guten Morgen

Nach 3 Wochen produktiver Nutzung kann ich nun sagen das ich recht zufrieden bin mit dem Produkt und auch mit dem Modul. Vielen Dank dafür.
Eine Anmerkung habe ich dennoch. Mir ist aufgefallen das es wohl nicht möglich ist mehr wie einen Ausgang gleichzeitig an zu sprechen. Nach einander kein Problem aber gleichzeitig geht gar nichts.
Das ist in sofern schlecht da ich lightScene und Structure verwende. lightScene konnte ich in sofern abfangen das ich die Gruppen schalte die ich extra dafür erstellt habe, aber Structure geht gar nicht. Sobald mehr wie ein Ausgang in ein und der selben Structure stecken schaltet keiner der ausgewählten.
Jemand ne Idee?



Grüße
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 21 Juli 2015, 09:14:16
Ja ist klar. Jeder Schaltbefehl muss zur Ubi übertragen -> abgearbeitet -> rückgemeldet werden. Das dauert etwas, versucht man während dessen einen weiteren Port zu schalten geht das schief, da der erste Befehl noch nicht vollständig abgearbeitet ist. Lösungen :
a. Wartezeiten von einigen Sekunden zwischen den Schaltbefehlen , oder eleganter
b. Gruppen definieren. Bei den Gruppen baut das Modul eine Kette von Befehlen und überträgt diese in einem Rutsch.
Benutze daher in Structure nicht die Ports einzeln sondern die Gruppen.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 21 Juli 2015, 09:34:27
Ich danke Dir für die Bestättigung meiner Vermutung. Eine kurze Frage, weist Du wie ich die Set Syntax in Structutre einbinden kann? Structure schaltet ein on oder off auf state. Die Leiste kann ich aber Gruppenmäßig nur mit set NAME gruppe on|off schalten.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 21 Juli 2015, 11:34:54
Hallo,
ich habe die Leisten ja auch schon länger, jetzt ist mir aufgefallen, das seit einiger Zeit keine Verbrauchswerte mehr angezeigt werden.
Ich habe die 1,3,6 Variante und nutze Sie ohne mFi Controller.

Die 1er und 6er liefern noch Werte, aber die 3er nicht. Trotz reboot.
Irgendwer eine Idee?

Nico
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 21 Juli 2015, 12:46:04
sind denn die Ports der 3er alle auf enable 1 ? Läuft die Messung evntuell nicht mehr seit dem letzten Power Down ? ( siehe dazu auch Post #115 auf der vorherigen Seite bzw. für mich der Hauptgrund für die Einführung des neuen Readings)
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 21 Juli 2015, 14:44:47
enable ist bei mir bei allen mpower Geräten auf 0

An den 1er und 3er betreibe ich Geräte wo ich aktuell mehr Strommesse als Schalte weshalb mir das on nach powerlost recht gelegen kommt.

Komischerweise hab ich ab dem 19 bis zum reboot eine Lücke in der Power Statistik.
Stormausfall hätte ich mitbekommen, der war nicht.

power ist nun auf der 3er wieder da nur der Count daily, monthly und yearly nicht.
Auch das ein/ausschalten was ich ja mal als Lösung hatte hilft aktuell wohl nicht.

FW 2.1.11 auf 3er und 6er FW2.1.8 auf 1er

Nico
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 21 Juli 2015, 16:33:31
Structutre einbinden kann? Structure schaltet ein on oder off auf state.

lies doch bitte mal die commandref zu structure , da steht u.A.
Zitat
attr async_delay
Wenn dieses Attribut gesetzt ist, werden ungefilterte set Kommandos nicht sofort an die Clients weitergereicht. Stattdessen werden sie einer Warteschlange hinzugefügt, um später ausgeführt zu werden. Das set Kommando kehrt sofort zurück, die Clients werden danach timer-gesteuert einzeln abgearbeitet. Die Zeit zwischen den Timer-Aufrufen ist dabei durch den Wert von async_delay (in Sekunden) gegeben,
Das ist doch das was du willst, wähle async_delay so das ein Befehl nach dem anderen sauber durchläuft.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 21 Juli 2015, 17:19:09
Das habe ich in der Tat total übersehen. Vielen Dank für den Hinweis. Ich werde mir das mal anschauen. Scheint aber genau das zu sein was ich suche.
Die Commandref ist aber auch Ellen lang für structure  ;D

Grüße
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 22 Juli 2015, 10:08:38
enable ist bei mir bei allen mpower Geräten auf 0
und was spricht gegen enable = 1 ?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 22 Juli 2015, 10:57:08
Guten Morgen,

Das mit async_delay hat bestens geklappt. musste aber auf gute 6 Sekunden gehen. Habe die Einstellung auf dem Structuredevice  durchgeführt wo auch die einzelnen Geräte drin sind.


Grüße
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 22 Juli 2015, 16:51:24
WTF, auf einmal zählt mein 3er wieder. Nachdem ich gestern Abend nochmals die Anschlüsse geschaltet habe.

Nico
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 30 Juli 2015, 13:14:10
Hallo,

ein komischen Effekt habe ich schon mindestens 2* gehabt:
Die mpower pro (6er) hat nur die ersten 3 Ports verknüpft. In der Oberfläche werden auch nur die 3 Out Devices dem Hauptdevice zugeordnet.
Nach einem FHEM restart ist es wieder richtig.

Kann das jemand bestätigen?

Nico
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 03 August 2015, 14:16:23
Hallo,

Problem ist wieder da:
"Unknown port Out6, choose one of ALL:on,off,toggle,enable,disable,lock,unlock,reset Out1:on,off,toggle,enable,disable,lock,unlock,reset Out2:on,off,toggle,enable,disable,lock,unlock,reset Out3:on,off,toggle,enable,disable,lock,unlock,reset "

"PORTS 6
SNAME P6E
STATE off off off off on on"

Irgendwie verstehe ich es nicht.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 03 August 2015, 15:44:29
Irgendwie verstehe ich es nicht.

Ich auch nicht, denn deine Internals sowie state sind der Meinung es seien 6 Ports verfügbar.
Wenn die Meldung wieder kommt mach doch mal ein get <name> info statt einem kompletten fhem restart.
Welche Version des Moduls nutzt du ?
Die aus dem svn (upate) oder die ich hier Anfang Juli gepostet hatte und mir bis heute niemand ein Feedback dazu gegeben hat ?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 05 August 2015, 13:18:24
get info:

aktuell geht's leider

Version:
#  $Id: 98_UbiquitiMP.pm 8516 2015-05-02 17:14:24Z wzut $
Ich tippe mal das ist dann svn, das andere hatte ich nicht bewusst war genommen.

Ich spiele die mal ein und teste.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: det. am 05 August 2015, 19:36:48

"die ich hier Anfang Juli gepostet hatte und mir bis heute niemand ein Feedback dazu gegeben hat ?"

Sorry, hatte die neue Version sofort getestet und da alles wie gewünscht ging und bis heute geht, hatte ich vergessen was zu Posten. Kennst Du doch sicher von Arbeit - keine Kritik ist Lob genug -  .
also vielen Dank, meine 6 fach Steckdose funktioniert ohne Beanstandung mit Deinem Modul
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 06 August 2015, 15:26:15
Hallo,

get info liefert: STATE: off off off off off off

Wenn ich den mpower per eigener Oberfläche umschalte ändert sich auch der State. Schalten in FHEM geht aber nicht.

habe nochmal die Version eingespielt, da es nicht "update safe" war ;)

Mal warten ob es nun besser ist.

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 10 August 2015, 11:11:17
Hallo,

also das Problem ist noch da und mittlerweile habe ich das auch mit der 2ten 6er mpower.

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: pipp37 am 11 Oktober 2015, 12:04:58
Ich habe mal etwas gesucht zu diesem Thema Kanal 13, wie ich das z.Z. sehe liegt das eigentlich nur am verwendeten Country Code für den Atheros Treiber.

Hallo.

Ich habe diese Info mal in das WIKI eingearbeitet und auch die aktuelle Firmwareversion ergänzt.

Bei mir gab es sogar Probleme ab Kanal 8.  Dabei konnte sich eine 1-Port (FW 2.1.11) und eine 3-Port (FW 2.1.8)  nicht mehr verbinden.
Kann das noch  jemand  bestätigen?

http://www.fhemwiki.de/wiki/Ubiquit_mFi/mPower#Bekannte_Probleme

Gruss Armin
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: chunter1 am 29 Oktober 2015, 10:31:47
Erst mal vielen Dank an den Entwickler des Moduls!
War ganz erfreut zu lesen, dass meine "alte" mPort Steckdose in FHEM unterstützt wird.

Ich hätte noch eine Anmerkung zur eState Formatierung.
Momentan schaut sie ja so aus "eState: E:24002.54 P:0 I:0 U:235 i:0"
Würde es evtl. Sinn machen ein Leerzeichen nach jedem ":" einzufügen damit sich im SVG-Plot Editor die Spalte wieder korrekt trennen lässt?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 29 Oktober 2015, 13:21:57
Zum Thema Sinn oder Unsinn dieses Leerzeichens bin ich leider überfragt. Wie ich schon zu Anfang des Threads geschrieben habe verstehe ich den kompletten Sinn des eState Readings eh nicht. (musste wohl unbedingt sein weil andere Geräte das auch haben ... )
Bei mir landen alle Readings als Einzelwerte in einer DB und von da picke ich sie mir anschliessend auch wieder im SVG-Plot Editor.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Chris_Worms am 30 Oktober 2015, 00:23:05
Hi,

ich habe heute eine 3-Port Ubiquiti mFi bekommen und wie im Wiki beschrieben in Betrieb genommen.

Im FHEM-Log stehen regelmäßig folgende Meldungen:

2015.10.30 00:11:40 2: Wz.Ubiquiti.Schreibtisch, Error[1] cmd status -> problem connecting to "192.168.2.115", port 23: connect timed-out
2015.10.30 00:11:56 2: Wz.Ubiquiti.Schreibtisch, Error[2] cmd status -> problem connecting to "192.168.2.115", port 23: connect timed-out

Nach diesen Meldungen blockiert die Steckdose völlig und es werden minutenlang keine Befehle angenommen und keine readings in FHEM aktualisiert (power, energy usw).

Beim Versuch (dann) einen Port zu schalten bekomme ich folgende Meldung:

2015.10.30 00:16:33 1: Timeout for UbiquitiMP_BCStart reached, terminated process 23926
2015.10.30 00:16:33 3: Wz.Ubiquiti.Schreibtisch, BlockingCall for Wz.Ubiquiti.Schreibtisch cmd Wz.Ubiquiti.Schreibtisch#off#2 aborted EC : 1

Sind das Fehlermeldungen aufgrund des regelmäßigen WLAN-Disconnects? Wenn ja dann ist die Ubiquiti eigentlich so zuverlässig wie... (mir fällt gerade nichts für unzuverlässig ein :-D )

Ich habe auch folgende Meldung im Log gefunden:

2015.10.29 23:28:51 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UbiquitiMP.pm line 793.
2015.10.29 23:32:15 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UbiquitiMP.pm line 346.

Was ist das?

Gruß
Chris
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 30 Oktober 2015, 13:18:24
leider schreibst du nicht
a. welche Firmware Version deine ubi hat
b. wie du die Parameter interval und timeout gesetzt hast
für interval empfehle ich für die ersten Versuche 300 und bei timeout 10
wenn ich mir deinen log  so anschaue scheint dein interval z.Z bei ca 16 Sekunden zu liegen :
Zitat von: Chris_Worms link=topic=35722.msg352042#msg352042

2015.10.30 00:11:40
2015.10.30 00:11:56
Aber das ist nur ein Symptom , die Ursache liegt bei dir vermutlich etwas tiefer.
Lassse doch mal fhem ganz aussen vor und logge dich via Webinterface direkt auf der Ubi ein, dann wechsele zum Menüpunkt Stats. Wichtig sind die Infos in der oberern rechten Ecke ( siehe Anhang Screenshots von zweien meiner Ubis)
Was steht bei Controller :  Not Connected, Connected, oder ... ?
Wie schaut der Balken Signal Strength aus , grün/blau oder eher rot/gelb ?

dann auf gleichen Seite bitte etwas nach unten gehen und Log anklicken.
finden sich dort Blöcke von Meldungen die auf häufige interne Restarts schliessen lassen ?
Bsp :  Server startup complete. Host name is ....
Wenn ja : durch einen Restart ist die Ubi einige Sekunden nicht erreichbar, in dieser Zeit können auch keine fhem Anfragen bearbeitet werden.

2015.10.29 23:28:51 1: PERL WARNING: Use of uninitialized valueOk diese Warnungen gehen auf mein Konto, hängen mit deinen Fehlern zusammen sind aber als solche nicht tragisch. Wenn du dir es zutraust kannst du ja mal in der Datei 98_UbiquitiMP.pm die beiden Zeilen 346 und 793 suchen, jeweils kurz davor findet sich die Zeile:
if ($hash->{helper}{RUNNING_PID})
diese jeweils ersetzen durch :
if(defined($hash->{helper}{RUNNING_PID}))
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Chris_Worms am 31 Oktober 2015, 12:46:33
Hi,
sorry für die fehlenden Infos.

a.) Firmware 2.1.11
b.) interval = 10, timeout ist nicht gesetzt

Im Bereich Stats sehe ich folgendes:
Controller:Not Connected (ist aber auch klar da ich weder einen Software-Controler laufen habe sondern nur FHEM und ich bin nicht am ubiquiti-Netzwerk angemeldet)
Signal Strength: ist blau bei -38db
Transmit CCQ:99.1 % 
TX/RX Rate:54.0 Mbps  / 54.0 Mbps
Channel/Frequency:4 / 2427 MHz
ACK/Distance:64 / 0.1 miles (0.1 km)
TX/RX Chains:1X1

Logfile von gestern bzw vorgestern als die Fehler auftraten gibt es nicht mehr, es werden wohl nur die aktuellsten LOG Einträge gespeichert. Aber ich hatte mich natürlich auf der Ubiquiti-Konsole eingeloggt und konnte erkennen dass sich der WPA-Client regelmäßig neugestartet hat und die Disconnects zu diesen Zeiten auftraten.

Ich habe dann gestern mein Netzwerk umgebaut. Die Steckdose war im "Haupt-WLAN" an einem Linksys-Router eingebucht. Dieses WLAN ist mit WPA2 verschlüsselt. Aufgrund des WIKI Eintrages habe ich einen älteren D-LINK Router ausgekramt, ein zweites WLAN-Netzwerk mit WEP64bit Verschlüsselung aufgebaut und die Steckdose mit diesem verbunden. Seither habe ich in FHEM keine Disconnects mehr!

Ich fühle mich aber etwas unsicher mit der WEP64bit Verschlüsselung und hoffe dass dieses Problem bals gefixt wird.

Gruß
Chris
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 31 Oktober 2015, 18:15:01
Ich habe zwei Ubis eingebunden beide mit WPA2 , die eine hat eine Verbindung zu meinem mFi Controller die andere nicht.
Bei beiden ist interval auf 300 gesetzt, Verhalten :
bei der Ubi die sich am mFi Controller anmeldet habe ich im fhem gar keine Meldungen das sie nicht erreichbar war, bei der anderen sind es in 24 Stunden ca 4-6
Ich kann mit der Fehlerrate gut leben, allerdings bei einem so kurzen Abfrageintervall wie bei dir von nur 10 Sekunden ist die Wahrscheinlichkeit halt verdammt hoch regelmäßig genau den Bereich zu erwischen in dem der Restart erfolgt.
Daher : entweder einen mFi Controller aufsetzen (läuft ohne Probs auch auf dem Raspi) oder mit dem Intervall deutlich nach oben gehen.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: santalaus am 26 November 2015, 10:18:07
Hallo,
zur Info da ich auch unter den disconnects leide, habe ich nochmal den ubiquity Support kontaktiert.
Aktuell sieht es so aus als ob mein Kontakt nichts von dem Problem weiss.
Mal sehen was dabei rauskommt.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Afterburner am 16 Dezember 2015, 10:22:06
Ich habe die Leiste bei mir auch in Verwendung, es ist kein Controller installiert.
Bis eben hatte ich noch WLAN aktiviert allerdings hatte ich dabei Probleme beim Schalten da vermutlich der Reboot / Timeout jedes mal dann kam wenn die Leiste geschaltet wurde.

Gestern Abend, erster Liveberieb am Terrarium, es sollten 4 Dosen um 20:00:00 Uhr auf einmal aus gehen (4 AT verschiedenen Befehle), nur eine wurde ausgeschaltet.
Syslog der Steckdose war bereits zeitlich überschrieben, im FHEM-Log stand zu der Zeit nichts, erst etwas später kam

Zitat
2015.12.15 20:13:33 1: Timeout for UbiquitiMP_BCStart reached, terminated process 2890

Timeout hatte ich vorher keinen gesetzt, der stand bei 5 standardmäßig, habe ihn jetzt auf 10 geändert wie hier vorgeschlagen.
Intervall hatte ich auf 30 Sekunden, habe ich jetzt mal auf 60 Sekunden hoch gesetzt.

Evtl ne Verständnisfrage, kann man mehrere Dosen mit verschiedenen AT Befehlen mit FHEM zur selben Zeit schalten ?

----

OK nachdem ich mir gestern Abend gedacht habe das es evtl Probleme mit dem zeitgleichen Schalten gibt habe ich für heute morgen die 4 Dosen im Abstand von jeweils 5 Sekunden schalten lassen. 3 Dosen wurden eingeschaltet, eine blieb aus. Auch hier vermute ich mal das WLAN TimeoutProblem

FHEM Log
Zitat
2015.12.16 08:00:59 1: Timeout for UbiquitiMP_BCStart reached, terminated process 3552
2015.12.16 08:00:59 3: Wohnzimmer.Terrarium, BlockingCall for Wohnzimmer.Terrarium cmd GetStatus aborted EC : 1
2015.12.16 08:10:06 2: Wohnzimmer.Terrarium, Error[1] cmd on -> timed-out waiting for password prompt
2015.12.16 08:14:08 2: Wohnzimmer.Terrarium, Error[1] cmd status -> problem connecting to "192.168.178.60", port 23: connect timed-out

Syslog
Dec 16 07:59:26 mFibaebd3 user.debug syslog: ace_reporter.reporter_timedout(): Connect(http://mfi.ubnt.com:6080/inform) has timed out
Dec 16 07:59:26 mFibaebd3 user.err syslog: ace_reporter.reporter_fail(): server unreachable
Dec 16 07:59:26 mFibaebd3 user.err syslog: ace_reporter.reporter_fail(): initial contact failed #7, url=http://mfi.ubnt.com:6080/inform, rc=3
Dec 16 07:59:44 mFibaebd3 user.err syslog: ace_reporter.reporter_connected(): connect(http://mfi:6080/inform) failed with errors: 0 148 - No route to host
Dec 16 07:59:44 mFibaebd3 user.err syslog: ace_reporter.reporter_fail(): server unreachable
Dec 16 07:59:44 mFibaebd3 user.err syslog: ace_reporter.reporter_fail(): initial contact failed #8, url=http://mfi:6080/inform, rc=2
Dec 16 08:00:00 mFibaebd3 auth.info login[575]: root login on 'pts/0'
Dec 16 08:00:01 mFibaebd3 cron.err crond[947]: USER Admin pid 585 cmd /usr/etc/mfi/hourly_cf_count.sh
Dec 16 08:00:05 mFibaebd3 auth.info login[926]: root login on 'pts/0'
Dec 16 08:00:13 mFibaebd3 auth.info login[1704]: root login on 'pts/0'
Dec 16 08:00:15 mFibaebd3 user.debug syslog: ace_reporter.reporter_timedout(): Connect(http://mfi.ubnt.com:6080/inform) has timed out
Dec 16 08:00:15 mFibaebd3 user.err syslog: ace_reporter.reporter_fail(): server unreachable
Dec 16 08:00:15 mFibaebd3 user.err syslog: ace_reporter.reporter_fail(): initial contact failed #9, url=http://mfi.ubnt.com:6080/inform, rc=3
Dec 16 08:00:33 mFibaebd3 user.err syslog: ace_reporter.reporter_connected(): connect(http://mfi:6080/inform) failed with errors: 0 148 - No route to host
Dec 16 08:00:33 mFibaebd3 user.err syslog: ace_reporter.reporter_fail(): server unreachable
Dec 16 08:00:33 mFibaebd3 user.err syslog: ace_reporter.reporter_fail(): initial contact failed #10, url=http://mfi:6080/inform, rc=2
Dec 16 08:00:33 mFibaebd3 user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-wpasupplicant
Dec 16 08:00:33 mFibaebd3 daemon.info init: process '/bin/wpa_supplicant -D atheros -i ath0 -c /etc/wpasupplicant_WPA-PSK.conf' (pid 32557) exited. Scheduling for restar
Dec 16 08:00:33 mFibaebd3 daemon.info init: starting pid 4332, tty '/dev/null': '/bin/wpa_supplicant -D atheros -i ath0 -c /etc/wpasupplicant_WPA-PSK.conf'
Dec 16 08:00:33 mFibaebd3 user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-mcad
Dec 16 08:00:34 mFibaebd3 daemon.info init: process '/bin/mcad' (pid 32561) exited. Scheduling for restart.
Dec 16 08:00:34 mFibaebd3 daemon.info init: starting pid 4430, tty '/dev/null': '/bin/mcad'
Dec 16 08:00:35 mFibaebd3 user.info syslog: mca-monitor.do_monitor(): failed to contact mcad. last_checkin=2 (max=200)
Dec 16 08:00:35 mFibaebd3 user.debug syslog: mcad.mca_daemon_main(): Starting up agent at 24:a4:3c:ba:eb:d3 nid = 0
Dec 16 08:00:35 mFibaebd3 user.info syslog: ace_reporter.reporter_reload_config(): [STATE] in DEFAULT
Dec 16 08:00:35 mFibaebd3 user.debug syslog: ace_reporter.ace_reporter_create(): opening /dev/output1
Dec 16 08:00:35 mFibaebd3 user.debug syslog: ace_reporter.ace_reporter_create(): opening /dev/output2
Dec 16 08:00:35 mFibaebd3 user.debug syslog: ace_reporter.ace_reporter_create(): opening /dev/output3
Dec 16 08:00:35 mFibaebd3 user.debug syslog: ace_reporter.ace_reporter_create(): opening /dev/output4
Dec 16 08:00:35 mFibaebd3 user.debug syslog: ace_reporter.ace_reporter_create(): opening /dev/output5
Dec 16 08:00:35 mFibaebd3 user.debug syslog: ace_reporter.ace_reporter_create(): opening /dev/output6
Dec 16 08:00:35 mFibaebd3 user.debug syslog: ace_reporter.reset_event_listener_init(): init reset_event listener on /dev/gpio_reset
Dec 16 08:00:35 mFibaebd3 user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh set-ready
Dec 16 08:00:38 mFibaebd3 daemon.info wpa-supplicant: ssid->auth_alg = 0, ssid->key_mgmt = 2 
Dec 16 08:00:38 mFibaebd3 daemon.info wpa-supplicant: wpa_s->wpa = 4806048
Dec 16 08:00:38 mFibaebd3 daemon.info wpa-supplicant: Trying to associate with 34:31:c4:fc:65:cb (SSID='NissanNet 2,4GHz' freq=2462 MHz)
Dec 16 08:00:38 mFibaebd3 user.info syslog: wevent.recv_msg(): receive msg seq: 0x3D1, len=0x14
Dec 16 08:00:38 mFibaebd3 user.err syslog: wevent.recv_msg(): attr 0x7fd9b904 type: [0x02] value:0
Dec 16 08:00:38 mFibaebd3 user.err syslog: wevent.recv_msg(): attr 0x7fd9b90c type: [0x01] value:ath0
Dec 16 08:00:38 mFibaebd3 user.info syslog: wevent.recv_msg(): EVENT_STA_LEAVE ath0: 0
Dec 16 08:00:39 mFibaebd3 daemon.info avahi-daemon[389]: Joining mDNS multicast group on interface ath0.IPv6 with address fe80::26a4:3cff:febb:ebd3.
Dec 16 08:00:39 mFibaebd3 daemon.info avahi-daemon[389]: New relevant interface ath0.IPv6 for mDNS.
Dec 16 08:00:39 mFibaebd3 daemon.info avahi-daemon[389]: Registering new address record for fe80::26a4:3cff:febb:ebd3 on ath0.*.
Dec 16 08:00:39 mFibaebd3 daemon.info wpa-supplicant: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Dec 16 08:00:39 mFibaebd3 daemon.info wpa-supplicant: Associated with 34:31:c4:fc:65:cb
Dec 16 08:00:39 mFibaebd3 user.info syslog: wevent.recv_msg(): skip event ... error!
Dec 16 08:00:39 mFibaebd3 user.info syslog: wevent.recv_msg(): receive msg seq: 0x3D2, len=0x14
Dec 16 08:00:39 mFibaebd3 user.err syslog: wevent.recv_msg(): attr 0x7fd9b904 type: [0x02] value:0
Dec 16 08:00:39 mFibaebd3 user.err syslog: wevent.recv_msg(): attr 0x7fd9b90c type: [0x01] value:ath0
Dec 16 08:00:39 mFibaebd3 user.info syslog: wevent.recv_msg(): EVENT_STA_LEAVE ath0: 0
Dec 16 08:00:41 mFibaebd3 daemon.info wpa-supplicant: WPA: Key negotiation completed with 34:31:c4:fc:65:cb [PTK=CCMP GTK=CCMP]
Dec 16 08:00:41 mFibaebd3 daemon.info wpa-supplicant: CTRL-EVENT-CONNECTED - Connection to 34:31:c4:fc:65:cb completed (auth) [id=0 id_str=]
Dec 16 08:00:41 mFibaebd3 daemon.info init: process '/sbin/ntpclient -n -s -c 0 -l -h pool.ntp.org' (pid 354) exited. Scheduling for restart.
Dec 16 08:00:41 mFibaebd3 daemon.info init: starting pid 4778, tty '/dev/null': '/sbin/ntpclient -n -s -c 0 -l -h pool.ntp.org'
Dec 16 08:00:41 mFibaebd3 daemon.info wpa-supplicant: WPA: Key negotiation completed with 34:31:c4:fc:65:cb [PTK=CCMP GTK=CCMP]
Dec 16 08:00:42 mFibaebd3 daemon.info init: process '/sbin/udhcpc -f -i eth1 -V ubnt -A 10 -s /etc/udhcpc/udhcpc -p /var/run/udhcpc.eth1.pid -h "mFi"' (pid 32607) exited
Dec 16 08:00:42 mFibaebd3 daemon.info init: process '/sbin/udhcpc -f -i ath0 -V ubnt -A 10 -s /etc/udhcpc/udhcpc -p /var/run/udhcpc.ath0.pid -h "mFi"' (pid 32667) exited
Dec 16 08:00:42 mFibaebd3 daemon.info init: starting pid 4820, tty '/dev/null': '/sbin/udhcpc -f -i ath0 -V ubnt -A 10 -s /etc/udhcpc/udhcpc -p /var/run/udhcpc.ath0.pid
Dec 16 08:00:42 mFibaebd3 daemon.info init: starting pid 4821, tty '/dev/null': '/sbin/udhcpc -f -i eth1 -V ubnt -A 10 -s /etc/udhcpc/udhcpc -p /var/run/udhcpc.eth1.pid
Dec 16 08:00:42 mFibaebd3 user.info syslog: wevent.recv_msg(): skip event ... error!
Dec 16 08:00:42 mFibaebd3 user.info syslog: wevent.recv_msg(): receive msg seq: 0x3D3, len=0x20
Dec 16 08:00:42 mFibaebd3 user.err syslog: wevent.recv_msg(): attr 0x7fd9b904 type: [0x02] value:0
Dec 16 08:00:42 mFibaebd3 user.err syslog: wevent.recv_msg(): attr 0x7fd9b90c type: [0x01] value:ath0
Dec 16 08:00:42 mFibaebd3 user.err syslog: wevent.recv_msg(): attr 0x7fd9b918 type: [0x03] value:41��e�
Dec 16 08:00:42 mFibaebd3 user.info syslog: wevent.recv_msg(): EVENT_STA_JOIN ath0: 34:31:c4:fc:65:cb / 0
Dec 16 08:00:42 mFibaebd3 user.err syslog: wevent.sta_join(): DHCP PID: 4820
Dec 16 08:00:42 mFibaebd3 user.info syslog: wevent.sta_join(): uplink node join, restarting dhcp
Dec 16 08:00:42 mFibaebd3 daemon.info avahi-daemon[389]: Withdrawing address record for 192.168.178.60 on ath0.
Dec 16 08:00:42 mFibaebd3 daemon.info avahi-daemon[389]: Leaving mDNS multicast group on interface ath0.IPv4 with address 192.168.178.60.
Dec 16 08:00:42 mFibaebd3 daemon.info avahi-daemon[389]: Interface ath0.IPv4 no longer relevant for mDNS.
Dec 16 08:00:43 mFibaebd3 daemon.info init: process '/sbin/udhcpc -f -i ath0 -V ubnt -A 10 -s /etc/udhcpc/udhcpc -p /var/run/udhcpc.ath0.pid -h "mFi"' (pid 4820) exited.
Dec 16 08:00:43 mFibaebd3 daemon.info init: starting pid 4903, tty '/dev/null': '/sbin/udhcpc -f -i ath0 -V ubnt -A 10 -s /etc/udhcpc/udhcpc -p /var/run/udhcpc.ath0.pid
Dec 16 08:00:43 mFibaebd3 user.info syslog: wevent.recv_msg(): skip event ... error!
Dec 16 08:00:43 mFibaebd3 daemon.info avahi-daemon[389]: Got SIGTERM, quitting.
Dec 16 08:00:43 mFibaebd3 daemon.info avahi-daemon[389]: Leaving mDNS multicast group on interface ath0.IPv6 with address fe80::26a4:3cff:febb:ebd3.
Dec 16 08:00:44 mFibaebd3 user.debug syslog: ace_reporter.reporter_evdns_resolv_cb(): dns resolv failed, result=67, type=0, count=0, ttl=0
Dec 16 08:00:44 mFibaebd3 daemon.info init: process '/sbin/ntpclient -n -s -c 0 -l -h pool.ntp.org' (pid 4778) exited. Scheduling for restart.
Dec 16 08:00:44 mFibaebd3 daemon.info init: starting pid 4974, tty '/dev/null': '/sbin/ntpclient -n -s -c 0 -l -h pool.ntp.org'
Dec 16 08:00:44 mFibaebd3 daemon.info avahi-daemon[389]: avahi-daemon 0.6.31 exiting.
Dec 16 08:00:44 mFibaebd3 user.err syslog: ace_reporter.reporter_fail(): server unreachable
Dec 16 08:00:44 mFibaebd3 user.err syslog: ace_reporter.reporter_fail(): initial contact failed #1, url=http://mfi.ubnt.com:6080/inform, rc=1
Dec 16 08:00:47 mFibaebd3 daemon.info init: process '/sbin/ntpclient -n -s -c 0 -l -h pool.ntp.org' (pid 4974) exited. Scheduling for restart.
Dec 16 08:00:47 mFibaebd3 daemon.info init: starting pid 5052, tty '/dev/null': '/sbin/ntpclient -n -s -c 0 -l -h pool.ntp.org'
Dec 16 08:00:50 mFibaebd3 daemon.info avahi-daemon[5176]: Found user 'nobody' (UID 65534) and group 'nogroup' (GID 1).
Dec 16 08:00:50 mFibaebd3 daemon.info avahi-daemon[5176]: Successfully dropped root privileges.
Dec 16 08:00:50 mFibaebd3 daemon.info avahi-daemon[5176]: avahi-daemon 0.6.31 starting up.
Dec 16 08:00:50 mFibaebd3 daemon.warn avahi-daemon[5176]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Dec 16 08:00:51 mFibaebd3 daemon.info init: process '/sbin/ntpclient -n -s -c 0 -l -h pool.ntp.org' (pid 5052) exited. Scheduling for restart.
Dec 16 08:00:51 mFibaebd3 daemon.info init: starting pid 5269, tty '/dev/null': '/sbin/ntpclient -n -s -c 0 -l -h pool.ntp.org'
Dec 16 08:00:52 mFibaebd3 daemon.err avahi-daemon[5176]: dbus_bus_get_private(): Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network con
Dec 16 08:00:52 mFibaebd3 daemon.warn avahi-daemon[5176]: WARNING: Failed to contact D-Bus daemon.
Dec 16 08:00:52 mFibaebd3 daemon.err avahi-daemon[5176]: write() failed while writing return value to pipe: Broken pipe
Dec 16 08:00:52 mFibaebd3 daemon.info avahi-daemon[5176]: avahi-daemon 0.6.31 exiting.
Dec 16 08:00:53 mFibaebd3 auth.info login[5328]: root login on 'pts/0'
Dec 16 08:00:59 mFibaebd3 daemon.info avahi-daemon[5604]: Found user 'nobody' (UID 65534) and group 'nogroup' (GID 1).
Dec 16 08:00:59 mFibaebd3 daemon.info avahi-daemon[5604]: Successfully dropped root privileges.
Dec 16 08:00:59 mFibaebd3 daemon.info avahi-daemon[5604]: avahi-daemon 0.6.31 starting up.
Dec 16 08:00:59 mFibaebd3 daemon.warn avahi-daemon[5604]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Dec 16 08:00:59 mFibaebd3 daemon.warn avahi-daemon[5604]: Failed to initialize inotify: Function not implemented
Dec 16 08:01:00 mFibaebd3 daemon.info avahi-daemon[5604]: Loading service file /etc/avahi/services/ssh.service.
Dec 16 08:01:00 mFibaebd3 daemon.info avahi-daemon[5604]: Loading service file /etc/avahi/services/web.service.
Dec 16 08:01:00 mFibaebd3 daemon.info avahi-daemon[5604]: Joining mDNS multicast group on interface ath0.IPv4 with address 192.168.178.60.
Dec 16 08:01:00 mFibaebd3 daemon.info avahi-daemon[5604]: New relevant interface ath0.IPv4 for mDNS.
Dec 16 08:01:00 mFibaebd3 daemon.info avahi-daemon[5604]: Network interface enumeration completed.
Dec 16 08:01:00 mFibaebd3 daemon.info avahi-daemon[5604]: Registering new address record for 192.168.178.60 on ath0.IPv4.
Dec 16 08:01:00 mFibaebd3 daemon.info avahi-daemon[5604]: Registering HINFO record with values 'MIPS'/'LINUX'.
Dec 16 08:01:01 mFibaebd3 daemon.info avahi-daemon[5604]: Server startup complete. Host name is mFi.local. Local service cookie is 4187732992.
Dec 16 08:01:02 mFibaebd3 daemon.info avahi-daemon[5604]: Service "mFi" (/etc/avahi/services/web.service) successfully established.
Dec 16 08:01:02 mFibaebd3 daemon.info avahi-daemon[5604]: Service "mFi" (/etc/avahi/services/ssh.service) successfully established.

Jetzt habe ich ein LAN Kabel gelegt und in der Leiste WLAN ausgeschaltet, naja hoffentlich ^^
Es gibt ja keine Option zum ausschalten, habe die SSID raus gelöscht und gespeichert, im Router taucht die IP des WLAN Adapters auch nicht mehr auf, im Adminbereich der Leiste hat sie auch keine IP allerdings ändern sich immer noch bei ACK/Distance die Werte und der TX Plot in der Grafik bei WLAN wird auch gezeichnet.

Ist das WLAN jetzt soweit aus das die Probleme mit den Restarts nicht mehr auftreten ?
Treten ähnliche Probleme auch in LAN auf ?

Sollte ich dann sicherheitshalber den Controller auf den PI installieren ? Die Ubnt Cloud gibt es ja wohl nicht mehr wenn ich das richtig mitbekommen habe
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 16 Dezember 2015, 10:32:24
Evtl ne Verständnisfrage, kann man mehrere Dosen mit verschiedenen AT Befehlen mit FHEM zur selben Zeit schalten ?
ja kann man , darum habe mir ja die Mühe gemacht und in die commandref geschrieben :

Zitat
groupPorts -> Durch Kommatas getrennte Liste um Ports in Gruppen zusammen zu fassen.
Die Gruppen können danach wie ein einzelner Port behandelt werden.
Bsp. attr Ubi groupPorts TV=12 Media=4,5,6 (GruppenName=Port Nummer des Ports in der Gruppe)

ich würde daher auch nie 2 oder mehr Ports so kurz hintereinander schalten sondern sinnvolle Gruppen bilden und die Gruppen schalten.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Afterburner am 16 Dezember 2015, 11:13:41
Eine Gruppierung möchte ich nicht haben da die Lampen je nach Temperatur geschaltet werden sollen (momentan noch nicht umgesetzt) und dann ja immer alles an und aus geht oder geht das dann trotzdem ? Dann wäre das super da die Einschaltzeit 8-20 Uhr immer für alle Lampen gilt, nur dazwischen sollen dann welche ab oder zugeschaltet werden.

Nur wie man das jetzt konfiguriert habe ich nicht verstanden

Bsp. attr Ubi groupPorts TV=12 Media=4,5,6 (GruppenName=Port Nummer des Ports in der Gruppe)
Wo kommt die 12 her ? Oder sollte das TV=1,2 heißen ?


Also wenn ich jetzt Port 1-4 in eine Gruppe zusammen fasse und Port 5 und 6 dann würde das Attribut so lauten ?
attr Wohnzimmer.Terrarium groupPorts LAMPEN=1,2,3,4 PUMPEN=5,6

Zur Sicherheit nochmal die Frage, kann dann trotzdem noch die einzelnen Dosen ausschalten ohne die anderen zu schalten ?
Das wäre dann ja quasi eine Goldrandlösung :)

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 16 Dezember 2015, 12:43:47
ja die 12 ist ein Tippfehler und es sollte eigentlich 1,2 sein.
Selbstverständlich behalten die Ports ihre Eigenständigkeit auch wenn sie Mitglied einer oder meherer Gruppen sind ( Schau auf die Internals & Kommandos, schon heute gibt es immer die Gruppe ALL )

Fixe Schaltzeiten habe ich ich bei mir ganz aus fhem entfernt und komplett in den internen Scheduler der Ubi gepackt. Wenn man seine GPS Koordinaten einträgt sind auch sunrise/sunset abhänige Zeiten kein Problem. So steuere ich z.B. ein Nachtlicht mit den Ubi interen Zeiten und via fhem nur die Ereignis gesteuerten Ausnahmen. 
 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Afterburner am 16 Dezember 2015, 12:53:50
Und wieder was dazu gelernt, man kann also auch "intern" schalten lassen wenn man FHEM nutzt.

Was mir noch aufgefallen ist ist das nach einer Weile Inaktivität (also kein Verbraucher eingeschaltet oder besser gesagt eingesteckt) FHEM keine Werte (wie Spannung) mehr geloggt hat, wurde dann was geschaltet dann wurde wieder geloggt ... siehe Screenshot ... um 22 Uhr hört der Plot auf (Dose 1-4 ausgeschaltet, 5+6 eingeschaltet aber nichts angeschlossen) ... am nächsten tag fangen die Plots dann wieder um 8 Uhr an wo die Lampen eingeschaltet worden sind.

Hatte das vorher im Test auch schon mal beobachtet, wenn man in der Phase ist wo kein Plot angezeigt wird und einen Verbrauchen ansteckt dann wird der nicht geloggt, sobald man einen Schalter betätigt wird auch wieder geloggt.

Meinst Du ob das mit dem WLAN Problem zusammen hängt ?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 16 Dezember 2015, 13:01:03
das hat nix mit Wlan zu tun sondern eher ganz allgemein damit wie du deine Attribute gesetzt hast.
Tipp : Forum und Wiki Suche nach "Plot Abriss vermeiden" 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Afterburner am 16 Dezember 2015, 13:17:13
Über event-on-change hatte ich schon was gelesen, deswegen habe ich es bisher auch noch nicht eingesetzt
http://www.fhemwiki.de/wiki/Plot-Abriss_vermeiden
bezieht sich aber wenn ich das richtig verstanden habe genau auf das event-on-change welches ich aber wie gesagt nicht einsetze
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 16 Dezember 2015, 13:38:27
axo ja du hast keinen "klassischen" Abriss, bei dir sind power und voltage 0 und die grüne Linie liegt exakt über der roten. Das reading voltage = 0 ist bei nicht eingeschaltetem Port  eine interne Eigenschaft der Ubi, schau dir bitte mal das Webinterface an dort ist Voltage in diesem Fall auch 0.00
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Afterburner am 16 Dezember 2015, 13:54:48
Ja aber das tritt auch bei eingeschalteten Port aus wo kein Verbraucher dran hängt und wenn Du genau auf den Plott guckst siehst Du das ab 22 Uhr da auch nichts übereinander liegt, es ist einfach kein Plott da
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: DerBodo am 28 Januar 2016, 10:02:49
Ich habe bei einer meiner beiden mPower Pro das Problem, dass der energy counter nicht hochgezählt wird.
Das Reading wird aktualisiert, allerdings immer mit 0.

An 4 von 5 verwendeten Ports funktioniert alles einwandfrei, nur dieser eine Port mag nicht....

Das Problem liegt wohl schon bereits innerhalb der Software der mPower.... da hier die Statistiken für Dezember ebenfalls auf 0 kwh stehen.
FW Update habe ich gestern mal gemacht von der 2.1.8 -> 2.1.11 - brachte leider keinen Erfolg.

Hat jemand noch einen Tipp was ich probieren könnte ?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 28 Januar 2016, 16:29:14
Die Ubi zählt intern energy erst hoch wenn der Port auch enabled =  1 hat.
Wie hoch ist denn die Last die an dem Port hängt ?
Ich habe u.A. an einem Port ein Nachtlicht, das brauch aber wohl so wenig Strom das der counter auch immer bei 0 bleibt, obwohl das auf 30 Tage gerechnet nicht ganz der Wahrheit entspricht.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: DerBodo am 29 Januar 2016, 09:11:58
Schande auf mein Haupt ! Das wars !

Danke !
Allerdings macht mich etwas stutzig dass ein cat /proc/power/enabled[1-6] bei allen 0 ausgegeben hat, aber bei 4 Ports zumindest das energy reading schön hochgezählt wurde.

Das setzen auf enabled geht nur über die Console auf dem Device oder ?

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 29 Januar 2016, 13:28:10
Das setzen auf enabled geht nur über die Console auf dem Device oder ?
Du meinst Konsole auf der Ubi ? Nein, kannst auch im fhem Webfrontend am Hauptdevice ( Achtung : nicht Portdevice !)  zusammenklicken :
set <device> Outx enabled
oder gleich als Befehl im Eingabefeld, bzw. Telnet Kommando -> set myUbi Out1 enabled
 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: aramis am 19 Mai 2016, 12:03:18
Hallo Wzut und Pipp37

gibt es den neuigkeiten zu dem Modul 98_UbiquitiMP.pm ?
Hintergund ist der dass ich gerade ernsthaft damit spiele mir die mPower Pro zu holen.

Grüße
aramis
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 19 Mai 2016, 12:17:18
Was soll es da für Neuigkeiten geben? Es funktioniert mit der mPower Pro. Habe ich selber im Einsatz. 6 Port
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: aramis am 19 Mai 2016, 12:38:40
Das es funktioniert habe ich schon gelesen  ;D
Ich dachte her an die Punkte aus dem ersten Post. Gerade Punkt 19 im ersten Post interessiert mich ziemlich  :)
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 19 Mai 2016, 12:59:42
Gerade Punkt 19 im ersten Post interessiert mich ziemlich  :)

also :
Zitat
Letzten Zustand  der Ports nach einem Stromausfall wiederherstellen. Normalerweise werden die Ausgänge immer auf EIN geschaltet. Die Funktionsweise muß ich mir noch genauer ansehen. Wenn die UBI Kontrollersoftware verwendet wird, macht die Leiste genau das.

Ich habe keine Ahnung wo die Ubi die Information intern speichert wie sie sich nach dem Neustart verhalten soll. Das default EIN ist war für meine Bedürfnisse genau richtig,
bzw. fhem bügelt das nach kurzer Zeit aus wenn es für den Augenblick nicht passen sollte.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: helly21 am 08 Juni 2016, 14:10:41
Hallo zusammen,

folgendes Problem im Log:

2016.06.08 13:53:07 1: reload: Error:Modul 98_UbiquitiMP deactivated:
 Type of arg 1 to keys must be hash (not hash element) at /usr/local/FHEM/share/fhem/FHEM/98_UbiquitiMP.pm line 553, near "};"
2016.06.08 13:53:07 0: Type of arg 1 to keys must be hash (not hash element) at /usr/local/FHEM/share/fhem/FHEM/98_UbiquitiMP.pm line 553, near "};"

Kann die Mpower 3 (Firmware Version:    MF.v2.1.11 - Build Number:    1309) nicht anbinden, "update force" unzählige Restarts halfen nicht. Meine Perlversion ist derzeit 5.20 unter DSM 6.1.
Per Telnet kann ich einwandfrei vom PC aus connecten ..

Kann mir jemand helfen beim debuggen von Modul "Modul 98_UbiquitiMP" ?

LG Josef
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 09 Juni 2016, 13:49:10
Kann es sein das Dir noch ein Perlmodul fehlt. Hast Du Dir mal im Wiki die Voraussetzungen an geschaut?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: helly21 am 09 Juni 2016, 13:53:07
möglich, hier find ich nix: http://www.fhemwiki.de/wiki/Ubiquit_mFi/mPower
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: helly21 am 09 Juni 2016, 13:55:27
das wäre dann JSON!?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 09 Juni 2016, 13:59:59
Wenn Du JSON nicht hast dann ist es wohl das.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 09 Juni 2016, 14:01:06
Hier findest Du alle wichtigen Infos (http://fhem.de/commandref_DE.html#UbiquitiMP)

Zitat
Perl Net::Telnet und das Perl JSON Modul werden benötigt. Bei einem Raspberry Pi können diese leicht mit den folgenden beiden Befehlen installiert werden:
apt-get install libjson-perl
apt-get install libnet-telnet-perl
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 10 Juni 2016, 09:55:36
2016.06.08 13:53:07 1: reload: Error:Modul 98_UbiquitiMP deactivated:
 Type of arg 1 to keys must be hash (not hash element) at /usr/local/FHEM/share/fhem/FHEM/98_UbiquitiMP.pm line 553, near "};"
2016.06.08 13:53:07 0: Type of arg 1 to keys must be hash (not hash element) at /usr/local/FHEM/share/fhem/FHEM/98_UbiquitiMP.pm line 553, near "};"

Welche Perl Version ist auf deinem System ?
( Edit : sorry wer lesen kann  ->
Zitat
Meine Perlversion ist derzeit 5.20


Teste doch bitte mal die angehängte Version, vllt. mag die deine V5.20 lieber :)
Ich habe noch 5.14.2 am Start  und die gibt sich mit einer Warnung zufrieden :
PERL WARNING: Using a hash as a reference is deprecated at ./FHEM/98_UbiquitiMP.pm line 553.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 10 Juni 2016, 09:58:41
Meine Perlversion ist derzeit 5.20 unter DSM 6.1.

Kann es am JSON liegen. Eventuell ist das auf einer DSM etwas anders zu handhaben.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: helly21 am 10 Juni 2016, 10:26:38
habs gerade probiert, leider das gleiche problem. Wenn ich Zeit habe werde ich das DSM mal wieder Bootstrapen und ggf. funktionierts dann auch..
Danke für eure Hilfe, falls jemandem noch was einfallen sollte bitte gerne her damit!

Grüße
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: bene_dicere am 17 Februar 2017, 11:56:21
Hier ist zwar schon länger keiner mehr aktiv gewesen...  ???

Habe nichts dazu gefunden, den Controller einzubinden ähnlich dem Modul für den Ubiquiti Networks (UBNT) - Controller.
Macht das keinen Sinn oder ist es schlichtweg zu aufwändig/nicht möglich?`

Danke!  :)
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: willib am 01 März 2017, 09:44:03
Achtung Anfängerfrage!
Ich möchte gerne eine Gruppe in eine Structure oder ein Notify einbinden um noch andere Dinge parallel zu schalten. Dabei macht mir das Leerzeichen Probleme. Wie muss ich die Gruppe innerhalb von structure verwenden?
<name> Musik oder <name>_Musik funktionieren nicht.
Danke.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 01 März 2017, 11:49:21
Das wird so nicht gehen. Dann mach das lieber über Szenen.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: willib am 01 März 2017, 12:44:14
Danke für die schnelle Antwort.
Wäre es nicht besser die Syntax der Gruppen wäre
<name>_Musikanalog zu den Ports
<name>_Out1damit würden Sie sich wie ein normales Device ansprechen lassen.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 01 März 2017, 14:16:43
set DEVICE COMMAND OPTIONS

Das ist die Syntax laut FHEM API. Da würde dann bei Deinem Wunsch nicht mehr unterschieden werden können zwischen DEVICE und COMMAND.
Das was Du meinst ist der Name des Device. Wenn man es so lassen will setzt er sich zusammen aus dem Namen des physikalischen Devices und dem Port welcher erkannt wurde. Ich kann den Namen aber auch ändern wie es mir gefällt.
rename <name>_Out1 SteckdoseWelcheImWohnzimmerDenFernsehrAnMacht

Das eine hat mit dem anderen nichts zu tun. Das eine ist der Devicename das andere ein set COMMAND der einr Gruppe ein Command übergibt
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 01 März 2017, 15:26:23
Ich lese hier seit heute Morgen mit kann dem eigentlichen Problem aber geistig noch nicht so ganz folgen.
 
Zitat
Ich möchte gerne eine Gruppe in eine Structure oder ein Notify einbinden
Gruppe = die Gruppe die man im Ubi Modul für Ports mit dem attr group_ports definieren kann ?
Structure = habe ich noch nie benutzt, daher keine Ahnung ob man Ubi Gruppen dort einbinden kann (müsste ich zu Hause erst testen). Die Ports als einzelne Geräte des Ubi Out Moduls bestimmt, allerdings bekommt man dann mit Sicherheit ein Timing Problem bei der Abarbeitung.
Notify = natürlich kann man innerhalb eines notifys Befehle an die Ubi Port Gruppe schicken
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 01 März 2017, 15:28:51
Man kann bei Structure nur Devices an geben. Einzelne Ports gehen und Timing ist kein Problem, da man ein delay als Attribut mit angeben kann welches zwischen dem schalten aller angegebenen Devices eingehalten wird.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: wichtel11 am 18 Mai 2017, 23:19:58
Hallo
Ich wollte das modul UbiquitiMP einbinden mit folgenden Befehl:

define UbiIPLeiste1 UbiquitiMP 192.168.0.116

einbinden. Leider bekomme ich die Meldung "Cannot load module UbiquitiMP "

Das Log sagt mir flogendes:
2017.05.18 10:45:15 1: PERL WARNING: Subroutine UbiquitiMP_Initialize redefined at ./FHEM/98_UbiquitiMP.pm line 50.
2017.05.18 10:45:15 1: PERL WARNING: Subroutine UbiquitiMP_updateConfig redefined at ./FHEM/98_UbiquitiMP.pm line 62.
2017.05.18 10:45:15 1: PERL WARNING: Subroutine UbiquitiMP_Define redefined at ./FHEM/98_UbiquitiMP.pm line 100.
2017.05.18 10:45:15 1: PERL WARNING: Subroutine UbiquitiMP_Undef redefined at ./FHEM/98_UbiquitiMP.pm line 141.
2017.05.18 10:45:15 1: PERL WARNING: Subroutine UbiquitiMP_force redefined at ./FHEM/98_UbiquitiMP.pm line 154.
2017.05.18 10:45:15 1: PERL WARNING: Subroutine UbiquitiMP_Attr redefined at ./FHEM/98_UbiquitiMP.pm line 181.
2017.05.18 10:45:15 1: PERL WARNING: Subroutine UbiquitiMP_Get redefined at ./FHEM/98_UbiquitiMP.pm line 245.
2017.05.18 10:45:15 1: PERL WARNING: Subroutine UbiquitiMP_Set redefined at ./FHEM/98_UbiquitiMP.pm line 280.
2017.05.18 10:45:15 1: PERL WARNING: Subroutine UbiquitiMP_BCStart redefined at ./FHEM/98_UbiquitiMP.pm line 361.
2017.05.18 10:45:15 1: PERL WARNING: Subroutine UbiquitiMP_BCDone redefined at ./FHEM/98_UbiquitiMP.pm line 455.
2017.05.18 10:45:15 1: PERL WARNING: Subroutine UbiquitiMP_BCAborted redefined at ./FHEM/98_UbiquitiMP.pm line 512.
2017.05.18 10:45:15 1: reload: Error:Modul 98_UbiquitiMP deactivated:
 Experimental keys on scalar is now forbidden at ./FHEM/98_UbiquitiMP.pm line 553.

2017.05.18 10:45:15 0: Experimental keys on scalar is now forbidden at ./FHEM/98_UbiquitiMP.pm line 553.
kann mir jemand helfen ?

perl -v

This is perl 5, version 24, subversion 1 (v5.24.1) built for armv7l-linux-thread-multi
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 19 Mai 2017, 16:23:18
versuche es doch bitte mal mit der Version die ich eine Seite davor « Antwort #156 am: 10 Juni 2016, 09:55:36 »
angehängt hatte

Edit : oder versuche es mit morgen mit update, ich habe eben eine neue Version hochgeladen
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: wichtel11 am 20 Mai 2017, 08:15:56
Mit der neuen Version die ich per Update bezogen habe funktioniert es jetzt. Danke für die schnelle Reaktion.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: markoweb am 09 September 2017, 09:26:44
Hallo zusammen,

bezüglich dieses Problems:

https://wiki.fhem.de/wiki/Ubiquit_mFi/mPower#WiFi_Reconnects_alle_2_Minuten

Wer möchte mich beim Testen unterstützen:

https://github.com/magcode/mpower-tools

Achtung: Testen auf eigene Gefahr!
Nur MF.v2.1.11.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 09 September 2017, 13:34:35
Da sag ich doch glatt vielen Dank !
 Habe es nun auf meinen beiden Ubis und werde das FHEM log im Auge behalten.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 10 September 2017, 19:11:59
Gestern nach ca. 8 Stunden sah das Log der Ubis verdammt gut aus, in der Zeit wurde auch nicht ein Timeout von FHEM Seite gelogt.
Heute ist das Log der Dosen wieder auf dem vollgemüllten Stand :( Kann es sein das nach einer Änderung der Settings im Webinterface die Dinger es wieder vergessen ?
Ich habe jetzt eine der beiden Dosen neu gestartet und das Log ist wieder ruhig, ich beobachte das Log die nächsten Tage weiter.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: markoweb am 11 September 2017, 10:52:42
Ja. In der Tat. Eine Änderung im Webinterface startet viele Prozesse im mPower neu. Ich habe mal schnell versucht das Problem zu beheben, ist mir aber nicht gelungen.

Ein manuelles /etc/persistent/rc.poststart behebt das Problem wieder.

Was genau machst Du für Änderungen im Betrieb via Webinterface? (Ich jedenfalls nutze das Webinterface gar nicht)
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 11 September 2017, 12:50:02
Was genau machst Du für Änderungen im Betrieb via Webinterface?
Normalerweise nach der Grundinstallation gar keine, aber da ich an den Dingern sowieso dran war habe ich halt auch mal wieder im Webinterface bei den internen Schaltzeiten aufgeräumt ... :)
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Dersch am 05 Oktober 2017, 20:40:14
Hi, seit heute spricht FHEM überhaupt nicht mehr mit der Ubnt Steckdosenleiste. Es war schon immer recht unzuverlässig aber nun geht nichts mehr. Ich hatte die Tage ca 3x FHEM geupdated. Ich kann daher nicht genau sagen seit welchem Update oder ob es überhaupt was damit zu tun hat. Über das Webif der Steckdose klappt das Schalten wunderbar.

Das Log mit Verbose 3 sagt folgendes worin ich ein Problem mit dem Modul sehe:

2017.10.05 20:11:42 3: WzMMSteckdose, BlockingCall for WzMMSteckdose cmd GetStatus aborted EC : 1
2017.10.05 20:11:42 2: WzMMSteckdose - sensors  : 3
2017.10.05 20:16:42 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UbiquitiMP.pm line 807.
2017.10.05 20:20:27 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UbiquitiMP.pm line 348.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_Initialize redefined at ./FHEM/98_UbiquitiMP.pm line 52.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_updateConfig redefined at ./FHEM/98_UbiquitiMP.pm line 64.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_Define redefined at ./FHEM/98_UbiquitiMP.pm line 102.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_Undef redefined at ./FHEM/98_UbiquitiMP.pm line 143.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_force redefined at ./FHEM/98_UbiquitiMP.pm line 156.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_Attr redefined at ./FHEM/98_UbiquitiMP.pm line 183.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_Get redefined at ./FHEM/98_UbiquitiMP.pm line 247.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_Set redefined at ./FHEM/98_UbiquitiMP.pm line 282.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_BCStart redefined at ./FHEM/98_UbiquitiMP.pm line 363.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_BCDone redefined at ./FHEM/98_UbiquitiMP.pm line 457.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_BCAborted redefined at ./FHEM/98_UbiquitiMP.pm line 514.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_Status redefined at ./FHEM/98_UbiquitiMP.pm line 537.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_Info redefined at ./FHEM/98_UbiquitiMP.pm line 724.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_GetStatus redefined at ./FHEM/98_UbiquitiMP.pm line 785.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_summaryFn redefined at ./FHEM/98_UbiquitiMP.pm line 821.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_createSets redefined at ./FHEM/98_UbiquitiMP.pm line 874.

Wäre toll wenn da jemand bzw der Entwickler helfen könnte.

Grüße
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: markoweb am 05 Oktober 2017, 20:46:26
Da kann ich nicht helfen, aber Info am Rande: Ich implementiere gerade ein "natives" MQTT auf der Leiste. Damit gibts dann eine weitere Alternative zur Integration der mPower in Hausautomatisierungssysteme.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Dersch am 05 Oktober 2017, 20:49:07
DAS ist sehr geil! Bitte sobald wie möglich! :D :D MQTT ist das einfachste und zuverlässigste was ich für die Heimautomation kenne. Wollte schon lange die Ubnt Leiste gegen MQTT fähige Steckdosen austauschen aber finde halt auch die Leistungsmessung toll.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 06 Oktober 2017, 07:37:58
2017.10.05 20:11:42 3: WzMMSteckdose, BlockingCall for WzMMSteckdose cmd GetStatus aborted EC : 1

2017.10.05 20:16:42 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UbiquitiMP.pm line 807.
2017.10.05 20:20:27 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UbiquitiMP.pm line 348.

2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_Initialize redefined at ./FHEM/98_UbiquitiMP.pm line 52.
2017.10.05 20:28:42 1: PERL WARNING: Subroutine UbiquitiMP_updateConfig redefined at ./FHEM/98_UbiquitiMP.pm line 64.
a. könnte in Zusammenhang stehen mit https://forum.fhem.de/index.php/topic,77556.0.html , bitte heute wieder ein Update machen
b. die Zeilen 807 und 348 schaue ich mir an
c. das sind keine Fehler, du hast das Modul neu geladen :)
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Dersch am 06 Oktober 2017, 08:33:04
Ja das Modul habe ich neu geladen um zu schauen ob es dann evtl funktioniert :)

Pearl Warning habe ich als Fehler angesehen. Ich mache heute wieder ein Update und dann mal schauen :)
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 06 Oktober 2017, 09:41:33
Ich habe eben mein Testsystem auf den aktuellsten FHEM Stand gebracht und die Ubi läuft ohne Probleme.
Die Fehlermeldungen der beiden Zeilen 807 und 348 sind reine Schönheitsfehler die nur das Logging im Fehlerfall betreffen.
 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Laffer72 am 21 Februar 2018, 17:52:27
@markoweb, vielen Dank für Deine Mühen mit den reconnects. Habe Deine Software auf meinen beiden Steckdosenleisen (3er und 6er) installiert und seitdem keine reconnects mehr.

Klasse Arbeit vielen Dank.

Viele Grüße

Reinhard
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: markoweb am 22 Februar 2018, 10:37:51
Top! Danke fürs Feedback. Auf meinen 5 mpower's ist es ebenfalls stabil.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: sf.fhem am 06 Juli 2018, 22:25:14
Hallo,

ich habe eine Lösung für die WiFi/Wireless Abbrüche mit WPA2 PSK gefunden.
Das Problem trifft auf, wenn man keinen mFi Controller verwendet.

Der Process "mcad" triggert den Neustart vom WiFi Client "/usr/etc/syswrapper.sh restart-wpasupplicant".

/var/log/messages:
Jan  1 00:10:32 mFi-mPower-XXXXXX user.debug syslog: ace_reporter.reporter_evdns_resolv_cb(): dns resolv failed, result=2, type=0, count=0, ttl=0
Jan  1 00:10:32 mFi-mPower-XXXXXX user.err syslog: ace_reporter.reporter_fail(): server unreachable
Jan  1 00:10:32 mFi-mPower-XXXXXX user.err syslog: ace_reporter.reporter_fail(): initial contact failed #10, url=http://mfi:6080/inform, rc=1
Jan  1 00:10:32 mFi-mPower-XXXXXX user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-wpasupplicant
Jan  1 00:10:33 mFi-mPower-XXXXXX daemon.info init: process '/bin/wpa_supplicant -D atheros -i ath0 -c /etc/wpasupplicant_WPA-PSK.conf' (pid 1994) exited. Scheduling for restart
Jan  1 00:10:33 mFi-mPower-XXXXXX daemon.info init: starting pid 12646, tty '/dev/null': '/bin/wpa_supplicant -D atheros -i ath0 -c /etc/wpasupplicant_WPA-PSK.conf'
Jan  1 00:10:33 mFi-mPower-XXXXXX user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-mcad
Jan  1 00:10:34 mFi-mPower-XXXXXX daemon.info init: process '/bin/mcad' (pid 1993) exited. Scheduling for restart.
Jan  1 00:10:34 mFi-mPower-XXXXXX daemon.info init: starting pid 12650, tty '/dev/null': '/bin/mcad'

Für den Workaround muss man sich mit einen SSH Client (putty etc.) mit dem User "ubnt" und dem Password "ubnt" (factory default) auf der mPower CLI einloggen.

Die Lösung ist es die Prozesse "/bin/mcad" u. "/bin/mca-monitor" zu beenden.
Diese Prozesse werden aber vom 'init' Prozess überwacht und ggf. neugestartet.

Daher in der "/etc/inittab" die folgenden Zeilen kommentieren.

/etc/inittab:
#null::respawn:/bin/mcad
#null::respawn:/bin/mca-monitor

Danach den 'init' Prozess reloaden und somit die config erneut einlesen.

# kill -SIGHUP 1

Abschließen die Prozesse 'mcad' und 'mca-monitoren beenden.

# pkill mcad
# pkill mca-monitor

Damit das Ganze nach einen Reboot funktioniert, legt man folgendes Script an.

/var/etc/persistent/rc.poststart
#!/bin/sh

#   
# error: wifi wpa2 connection resets every two minutes. cause no mFI controller is available.
#
# /var/log/messages:
# (..)
# Jan  1 00:10:32 mFi-mPower-XXXXXX user.debug syslog: ace_reporter.reporter_evdns_resolv_cb(): dns resolv failed, result=2, type=0, count=0, ttl=0
# Jan  1 00:10:32 mFi-mPower-XXXXXX user.err syslog: ace_reporter.reporter_fail(): server unreachable
# Jan  1 00:10:32 mFi-mPower-XXXXXX user.err syslog: ace_reporter.reporter_fail(): initial contact failed #10, url=http://mfi:6080/inform, rc=1
# Jan  1 00:10:32 mFi-mPower-XXXXXX user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-wpasupplicant
# Jan  1 00:10:33 mFi-mPower-XXXXXX daemon.info init: process '/bin/wpa_supplicant -D atheros -i ath0 -c /etc/wpasupplicant_WPA-PSK.conf' (pid 1994) exited. Scheduling for restart
# Jan  1 00:10:33 mFi-mPower-XXXXXX daemon.info init: starting pid 12646, tty '/dev/null': '/bin/wpa_supplicant -D atheros -i ath0 -c /etc/wpasupplicant_WPA-PSK.conf'
# Jan  1 00:10:33 mFi-mPower-XXXXXX user.debug syslog: libubnt_exec.syswrapper_impl(): [EXEC] /usr/etc/syswrapper.sh restart-mcad
# Jan  1 00:10:34 mFi-mPower-XXXXXX daemon.info init: process '/bin/mcad' (pid 1993) exited. Scheduling for restart.
# Jan  1 00:10:34 mFi-mPower-XXXXXX daemon.info init: starting pid 12650, tty '/dev/null': '/bin/mcad'
# (..)
#
# fix: disable "mcad" and "mca-monitor" daemon
#
# 1.) comment both daemons
#
# /etc/inittab:
# (..)
# #null::respawn:/bin/mcad
# #null::respawn:/bin/mca-monitor
# (..)
#
# 2.) reload "init"
#
# # kill -SIGHUP 1
#

#
# $1=> string: log message
#
log()
{
logger -p user.debug -t rc.poststart "${1}"
}

if [ -f "/etc/inittab" ]
then
sed -i -e 's/null::respawn:\/bin\/mcad/#null::respawn:\/bin\/mcad/g' -e 's/null::respawn:\/bin\/mca-monitor/#null::respawn:\/bin\/mca-monitor/g' /etc/inittab || \
log "sed failed. \"/etc/inittab\""
kill -SIGHUP 1 || log "command failed. \"kill -SIGHUP 1\""
pkill mcad && log "killed process \"mcad\"." || log "command failed. \"pkill mcad"\"
pkill mca-monitor && log "killed process \"mca-monitor\"." || log "command failed. \"pkill mca-monitor"\"
else
log "file not found. \"/etc/inittab\""
fi

Das Script ausführbar setzen und das Verzeichnis "/var/etc/persistent/" dauerhaft speichern.

# chmod 0755 /var/etc/persistent/rc.poststart
# save
Found  Active on[1] ...
Found Backup1 on[2] ...
Storing Active[2] ... [%100]
Active->Backup[1] ... [%100]
#

Nach einen Reboot dauert es ca. drei Minuten bis das Script ausgeführt wird.

Viel Spaß
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: markoweb am 06 Juli 2018, 22:42:04
yap. oder einfach hier lesen https://forum.fhem.de/index.php/topic,35722.msg683055.html#msg683055
und https://github.com/magcode/mpower-tools/tree/master/nocontroller benutzen
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: sf.fhem am 06 Juli 2018, 22:59:47
Hallo markoweb,

dass mit dem "nocontroller" hatte ich gesehen, fand ich etwas zu kompliziert.

Bin gerade in ein Problem vom "98_UbiquitiMP.pm" gelaufen.
Sobald ich den Ports einen Name gebe, kann der JSON Response nicht verarbeitet werden.

Auf dem mPower..

/var/etc/persistent/cfg/config_file:
port.0.model=Outlet
port.0.label=aqua-licht
port.1.model=Outlet
port.1.label=aqua-pumpe
port.2.model=Outlet
port.2.label=led-lampe


/opt/fhem/log/fhem-2018-07.log:
2018.07.06 22:45:40 1: ERROR evaluating {UbiquitiMP_BCDone('mpower01|1|status|{"sensors":[{"port":1,"output":1,"power":5.32742083,"enabled":0,"current":0.027494847,"voltage":237.317085266,"powerfactor":0.816463321,"relay":1,"lock":0,"thismonth":0},{"port":2,"output":1,"power":0.0,"enabled":0,"current":0.0,"voltage":236.611645698,"powerfactor":0.0,"relay":1,"lock":0,"thismonth":0},{"port":3,"output":1,"power":17.029695034,"enabled":0,"current":0.128298997,"voltage":236.92356944,"powerfactor":0.560241581,"relay":1,"lock":0,"thismonth":0}],"status":"success"}ubnt@mpower01:/var/etc/persistent |u=154.81ubnt@mpower01:/var/etc/persistent |0.0 0.0 0.0 ubnt@mpower01:/var/etc/persistent ')}: garbage after JSON object, at character offset 484 (before "ubnt@mpower01:/var/e...") at ./FHEM/98_UbiquitiMP.pm line 551.

So wie es aussieht, hängt die mit den Port Name zusammen und der geänderten Prompt. "$PS1"

/var/etc/persistent/.profile:

PS1="\u@\h:\w # "


Sobald ich die "/var/etc/persistent/cfg/config_file" deaktivierte, klappen die Readings.
Die Prompt nach wie vor abgeändert.


Die Ursache liegt in der geänderten Prompt "$PS1".  :(
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wuppi68 am 05 Dezember 2018, 23:00:53
habe auch ein Problem :-(

meine 6er Steckdose:

Internals:
   BNAME      mPower Pro
   Clients    :UbiquitiOut:
   DEF        172.17.2.121
   ERRORCOUNT 0
   INTERVAL   300
   MAC        0418d6265c20
   NAME       mfi.6.1
   NR         475
   PORTS      6
   SNAME      P6E
   STATE      on on on on on on
   TYPE       UbiquitiMP
   VERSION    2.1.11
   force      0
   group_ALL  1,2,3,4,5,6
   lastcmd    GetStatus
   load       0.49 0.48 0.50
   powerd_on  2018-07-31 23:47:47
   Helper:
     DBLOG:
       all_current:
         myDbLog:
           TIME       1544046274.72009492
           VALUE      0.22
       all_energy:
         myDbLog:
           TIME       1544046274.72009492
           VALUE      3107.81
       all_month:
         myDbLog:
           TIME       1544040205.12195897
           VALUE      4.25
       all_power:
         myDbLog:
           TIME       1544046577.82967997
           VALUE      28.71
       state:
         myDbLog:
           TIME       1543955311.45292401
           VALUE      on on on on on on
       uptime:
         myDbLog:
           TIME       1544046577.82967997
           VALUE      127 days, 00:01:50
   READINGS:
     2018-12-05 22:49:37   all_current     0.22
     2018-12-05 22:49:37   all_energy      3107.81
     2018-12-05 22:49:37   all_month       4.25
     2018-12-05 22:49:37   all_power       28.71
     2018-12-05 22:49:37   all_prevmonth   0.97
     2018-12-05 22:49:37   state           on on on on on on
     2018-12-05 22:49:37   uptime          127 days, 00:01:50
   helper:
     Out1:
       lock       0
       name       Out1
       state      1
     Out2:
       lock       0
       name       Out2
       state      1
     Out3:
       lock       0
       name       Out3
       state      1
     Out4:
       lock       0
       name       Out4
       state      1
     Out5:
       lock       0
       name       Out5
       state      1
     Out6:
       lock       0
       name       Out6
       state      1
     bm:
       UbiquitiMP_Get:
         cnt        1
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        05.12. 22:46:08
         max        7.152557373046875e-06
         tot        7.152557373046875e-06
         mAr:
           HASH(0x9900a68)
           mfi.6.1
           ?
       UbiquitiMP_Set:
         cnt        720
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        05.12. 01:25:59
         max        4.98294830322265625e-05
         tot        0.0127508640289306641
         mAr:
           HASH(0x9900a68)
           mfi.6.1
           ?
Attributes:
   event-on-change-reading .*
   password   84nq3tcigiu3nq7vjtegluw
   subDevices 1
   timeout    5
   user       keinubntdefaultuser

liefert im FHEM Log folgendes:

2018.12.05 22:54:41 1: PERL WARNING: Use of uninitialized value $b in concatenation (.) or string at ./FHEM/98_UbiquitiMP.pm line 844.
2018.12.05 22:54:41 3: eval: {UbiquitiMP_BCDone('mfi.6.1|1|status|{"sensors":[{"port":1,"output":1,"power":0.0,"enabled":0,"current":0.0,"voltage":236.68238306,"powerfactor":0.0,"relay":1,"lock":0,"prevmonth":3102,"thismonth":13599},{"port":2,"output":1,"power":1.139312744,"enabled":0,"current":0.02014327,"voltage":237.392728328,"powerfactor":0.238256939,"relay":1,"lock":0,"prevmonth":0,"thismonth":0},{"port":3,"output":1,"power":0.0,"enabled":0,"current":0.0,"voltage":236.589660644,"powerfactor":0.0,"relay":1,"lock":0,"prevmonth":0,"thismonth":0},{"port":4,"output":1,"power":17.165691375,"enabled":0,"current":0.150175809,"voltage":237.046366691,"powerfactor":0.482200897,"relay":1,"lock":0,"prevmonth":0,"thismonth":0},{"port":5,"output":1,"power":3.128793239,"enabled":0,"current":0.029585957,"voltage":236.844130754,"powerfactor":0.446507345,"relay":1,"lock":0,"prevmonth":0,"thismonth":0},{"port":6,"output":1,"power":0.0,"enabled":0,"current":0.0,"voltage":237.050891876,"powerfactor":0.0,"relay":1,"lock":0,"prevmonth":0,"thismonth":0}],"status":"success"}|u=10973213.90|l=0.40 0.45 0.48|4092.1875 0.0 0.0 0.0 0.0 5853.125 MF.v2.1.11')}
2018.12.05 22:54:41 1: stacktrace:
2018.12.05 22:54:41 1:     main::__ANON__                      called by ./FHEM/98_UbiquitiMP.pm (844)
2018.12.05 22:54:41 1:     main::UbiquitiMP_summaryFn          called by ./FHEM/01_FHEMWEB.pm (3166)
2018.12.05 22:54:41 1:     main::FW_devState                   called by ./FHEM/01_FHEMWEB.pm (2969)
2018.12.05 22:54:41 1:     main::FW_Notify                     called by ./FHEM/98_apptime.pm (205)
2018.12.05 22:54:41 1:     main::apptime_getTiming             called by ./FHEM/98_apptime.pm (165)
2018.12.05 22:54:41 1:     main::CallFn                        called by fhem.pl (3523)
2018.12.05 22:54:41 1:     main::DoTrigger                     called by fhem.pl (4574)
2018.12.05 22:54:41 1:     main::readingsEndUpdate             called by ./FHEM/98_UbiquitiMP.pm (715)
2018.12.05 22:54:41 1:     main::UbiquitiMP_Status             called by ./FHEM/98_UbiquitiMP.pm (495)
2018.12.05 22:54:41 1:     main::UbiquitiMP_BCDone             called by (eval 250717)[fhem.pl:1116] (1)
2018.12.05 22:54:41 1:     (eval)                              called by fhem.pl (1116)
2018.12.05 22:54:41 1:     main::AnalyzePerlCommand            called by fhem.pl (1141)
2018.12.05 22:54:41 1:     main::AnalyzeCommand                called by fhem.pl (1063)
2018.12.05 22:54:41 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2018.12.05 22:54:41 1:     main::telnet_Read                   called by ./FHEM/98_apptime.pm (205)
2018.12.05 22:54:41 1:     main::apptime_getTiming             called by ./FHEM/98_apptime.pm (165)
2018.12.05 22:54:41 1:     main::CallFn                        called by fhem.pl (726)

macht auch meiner 3er Dose :-(

Hat da jemand einen Rat?



PS.: Die spricht jetzt auch MQTT und der WiFi Daemon ist auch deaktiviert ...

hier --> https://github.com/magcode/mpower-tools
 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 06 Dezember 2018, 06:54:33
2018.12.05 22:54:41 1: PERL WARNING: Use of uninitialized value $b in concatenation (.) or string at ./FHEM/98_UbiquitiMP.pm line 844.
schau mal im Modul ob die Zeile 844 bei dir so ausschaut :
$txt = $a."title=\"".$title."\"".$b;wenn ja ändere sie einfach in
$txt = $a."title=\"".$title."\">";und acht Zeilen tiefer noch einmal.

Edit : Verrate mir bitte noch ob du mit deiner MQTT Änderung auch state verbogen hast auf 0/1 statt on/off oder ob du den f18 benutzt ? 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wuppi68 am 06 Dezember 2018, 09:45:16
danke :-)

klappt mit Deiner Änderung
hatte vorher schon jeweils

if (! defined $b) { $b = '' };
jeweils in die Zeile davor getackert

Bei dem "neuen" F18 Style bekomme ich auch so nen "doofen" State angezeigt - ist aber nur Makulatur ...
mfi3.1
               
title="Out1 on">   
               
title="Out2 off">   
               
title="Out3 off"> 

und dazwischen die Leuchtensymbole...

Durch die MQTT anpassung habe ich nicht sonstiges daran geändert. Es geht halt nur auch via MQTT.

Danke

Ralf
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 06 Dezember 2018, 10:48:45
if (! defined $b) { $b = '' };
ne das ist nicht so gut da dann die HTML Syntax nicht mehr stimmt, also besser ">" statt "" nehmen.
Ich muss mal meine 3er Ubi ausgraben und mit dem f18 zusammen testen.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wuppi68 am 06 Dezember 2018, 10:52:21
ne das ist nicht so gut da dann die HTML Syntax nicht mehr stimmt, also besser ">" statt "" nehmen.
Ich muss mal meine 3er Ubi ausgraben und mit dem f18 zusammen testen.

war ja auch nur ein erster Hack ... und habe es jetzt wieder rausgenommen
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 06 Dezember 2018, 11:46:04
würdest du bitte nochmal testen diesmal mit diesem Block :
($a,$b) = split('title=\"on\"' , FW_makeImage($icon, "on"));
$txt  = $a;
$txt .= "title=\"".$title."\"".$b if($b);

das sollte dein erstes Problem auch lösen und F18 gleich mit erschlagen
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wuppi68 am 06 Dezember 2018, 12:20:27
würdest du bitte nochmal testen diesmal mit diesem Block :
($a,$b) = split('title=\"on\"' , FW_makeImage($icon, "on"));
$txt  = $a;
$txt .= "title=\"".$title."\"".$b if($b);

das sollte dein erstes Problem auch lösen und F18 gleich mit erschlagen

geändert --> getestet --> für gut gefunden

Danke :top:

btw. was macht die Zeile genau mit $b? ($a,$b) = split('title=\"on\"' , FW_makeImage($icon, "on"));

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 06 Dezember 2018, 12:28:17
das war damals so ne Spielerei von mir das obwohl z.B. das Icon als Hilfstext "on" hat diese in "off" geändert wird beim darüberfahren mit dem Mauszeiger.
Ich glaube ich werde mir die beiden Ubi Module doch nochmal vornehmen, da ist so einiges was ich heute anders (besser ?) machen würde.   
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: aramis am 14 April 2019, 15:07:38
Hallo zusammen,

ich habe ein etwas komisches Problem bei dem ich nicht mehr weiter weiß.

Die Ausgangsituation ist wie folgt:
Ich habe 2 Ubiquiti mPower Pro bei mir im Einsatz.

Was funktioniert:
Das Ansprechen der einzelnen Ports funktioniert ohne Problem.
Sobald ich die groupPorts anlege funktioniert es auch über ein notify mehre Ports auf einmal zu schalten.

Was funktioniert irgendwie nicht so ganz:
1) Bei einem Neustart des Raspberry Pis auf dem FHEM läuft wird in der Anzeige weiterhin die groupPorts angezeigt, jedoch sind keine Aktionen auf die Grupp ausführbar. Erst ein Löschen und neuanlegen der GroupPorts bringt hier die Lösung dass die Gruppe wieder schaltbar ist. Wie kann ich dieses Problem lösen? Was ich nur ungerne machen würde ist über die Linux CLI auf die cfg zugriefen und dort den GroupPort Eintrag beispielsweise zuändern. Ich habe es einmal testhalber versucht und den Eintrag gelöscht (was funktioniert) und dann neu angelegt und abgespeichert. Die GroupPorts werden zwar wieder angezeigt aber das Schalten der Gruppe funktioniert trotzdem nicht mehr. Erst das manuelle Löschen und neualegen über das WebFrontend bringt wieder abhilfe. Daher habe ich den Cron Job wieder entfernt.
2) Das Schalten mehrere Ports über ein Notify. Sprich ich möchte von Ubi1 den Out1, Out2 und Out3 schalten. Das funktioniert nicht. Ich kann jeweils nur einen Port schalten. Das Notify ansich tut. Den ich kann beispielsweise Ubi Out1, mehrere dummy schalten und auch gleichzeitig den Ubi2 Out3 schalten. Jedoch nicht mehrere Ports der gleichen Ubiquiti mPower Pro.

Kann mir hier jemand einen Tip geben?
Benötigt ihr noch weitere Infos?

Danke euch - schönes Wochenende

Viele Grüße
aramis

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 14 April 2019, 18:00:33
Ich habe zwar ewig nicht mehr mit den Ubis gemacht, aber ich fang mal hinten an :
Mehrer Befehle kurz hintereinander gab Timingprobleme, daher ist es sinnvoll diese in Gruppen zu definieren da dies nur einen Schreib & Lesevorgang bedeutet.
Dein erstes Problem mit den Gruppen kann ich im Moment nicht so ganz nachvollziehen, k.A. da ich selbst nie Gruppen benutzt habe.
Ich kann aber die 3er Ubi mal aus der Bastelkiste holen und wieder unter Dampf setzen, denke mal nach Ostern sollte ich da etwas schlauer sein.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: aramis am 15 April 2019, 14:02:08
Hallo Wzut,

danke dir erstmal dass du dich dem Thema annimmst.
Benötigst du irgendwelche Angaben von mir?

Viele Grüße
aramis
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 15 April 2019, 14:24:19
äh nein. Ich gehe davon aus mit pro meinst du die 6er ?
Ich habe nur eine 3er , sollte aber zum Thema des Gruppentest erst einmal ausreichen.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 15 April 2019, 17:58:05
Ich habe jetzt meiner 3er in Betrieb und Gruppen angelegt. Auch nach einem FHEM Restart kann ich diese ohne Probleme schalten.
Um deinem Problem auf die Spur zu kommen benötige ich :
a. ein List des UbiquittiMP Device nach einem reboot/restart nachdem der Status abgefragt wurde
b. ein verbose 5 Log mit dem Versuch eine Gruppe zu schalten 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 16 April 2019, 10:22:40
Update : Ich denke ich habe den Fehler gefunden, er tritt nur dann auf wenn man mehr als ein Device anlegt und dieses jeweils auch mehr als ein Port hat.
Legt man nun Gruppen an überschreibt die Gruppenliste von Device Nr. 2 die von Nr. 1 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: aramis am 22 April 2019, 10:25:43
Hallo Wzut,

das von dir beschriebene Verhalten kann ich nachvollziehen.
Ich habe nun mal meine GroupPorts neu geordnet und siehe da, wenn der Eintrag zu letzt steht ist er auswählbar.

Kann ich irgendwas tun um dieses Verhalten abzustellen?

Danke dir
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 22 April 2019, 14:32:03
Ich habe das inzwischen umgeschrieben und noch ein paar Kleinigkeiten geändert, wenn die 1 Port Ubi jetzt auch noch fehlerfrei läuft werde ich die neuen Versionen entweder heute oder morgen Abend einchecken.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: aramis am 22 April 2019, 21:15:07
Herzlichen Dank dir Wzut.
Vielen Dank für deinen Einsatz! _thumbsup_
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 24 April 2019, 07:08:57
@aramis, kannst du bitte mal die angehängten Versionen bei dir testen bevor ich sie einchecke ?
Der Code ist IMHO soweit fertig, allerdings fehlt jetzt noch die entsprechende Doku in der command.ref
ACHTUNG : nach einem reload gibt es das Attribut password nicht mehr !
Das Password muß jetzt (wie bei anderen Modulen auch) einmalig mit set <name> password dein_password dauerhaft eingetragen werden. 
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: aramis am 24 April 2019, 09:00:42
Hallo wzut,

mache ich gerne heute Abend sobald ich zuhause bin.
Benötigst du dann irgendwelche Logs von mir?

Grüße
aramis
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 24 April 2019, 09:08:53
nein, mir geht es um deine Gruppen bei mehr als einem Multiport Gerät.
Ich konnte das mit meiner 3er und mini nur simulieren.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: aramis am 03 Mai 2019, 08:50:02
Hallo Wzut,

funktioniert.  ;D
Ich habe es nun zwei Wochen immer wieder getestet - und was soll ich sagen:
PERFEKT!

Danke dir *thumbs up*
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 03 Mai 2019, 09:05:10
Wo Du doch gerade so schön dabei bist

2019.04.02 06:09:13 1: PERL WARNING: Use of uninitialized value $b in concatenation (.) or string at ./FHEM/98_UbiquitiMP.pm line 852.
2019.04.02 06:09:13 3: eval: {UbiquitiMP_BCDone('mFimPower01|1|status|{"sensors":[{"port":1,"output":0,"power":0.0,"enabled":0,"current":0.0,"voltage":0.0,"powerfactor":0.0,"relay":0,"lock":0,"prevmonth":1398,"thismonth":0},{"port":2,"output":0,"power":0.0,"enabled":0,"current":0.0,"voltage":0.0,"powerfactor":0.0,"relay":0,"lock":0,"prevmonth":0,"thismonth":0},{"port":3,"output":0,"power":0.0,"enabled":0,"current":0.0,"voltage":0.0,"powerfactor":0.0,"relay":0,"lock":0,"prevmonth":77007,"thismonth":3197},{"port":4,"output":0,"power":0.0,"enabled":0,"current":0.0,"voltage":0.0,"powerfactor":0.0,"relay":0,"lock":0,"prevmonth":58,"thismonth":0},{"port":5,"output":1,"power":0.0,"enabled":0,"current":0.0,"voltage":232.260444641,"powerfactor":0.0,"relay":1,"lock":0,"prevmonth":7579,"thismonth":159},{"port":6,"output":0,"power":0.0,"enabled":0,"current":0.0,"voltage":0.0,"powerfactor":0.0,"relay":0,"lock":0,"prevmonth":494,"thismonth":0}],"status":"success"}|u=6896104.83|l=0.69 0.56 0.55|876.5625 0.0 66396.5625 18.4375 2490.3125 651.5625 MF.v2.1.11')}
2019.04.02 06:09:13 1: PERL WARNING: Use of uninitialized value $b in concatenation (.) or string at ./FHEM/98_UbiquitiMP.pm line 844.
2019.04.02 06:09:13 3: eval: {UbiquitiMP_BCDone('mFimPower01|1|status|{"sensors":[{"port":1,"output":0,"power":0.0,"enabled":0,"current":0.0,"voltage":0.0,"powerfactor":0.0,"relay":0,"lock":0,"prevmonth":1398,"thismonth":0},{"port":2,"output":0,"power":0.0,"enabled":0,"current":0.0,"voltage":0.0,"powerfactor":0.0,"relay":0,"lock":0,"prevmonth":0,"thismonth":0},{"port":3,"output":0,"power":0.0,"enabled":0,"current":0.0,"voltage":0.0,"powerfactor":0.0,"relay":0,"lock":0,"prevmonth":77007,"thismonth":3197},{"port":4,"output":0,"power":0.0,"enabled":0,"current":0.0,"voltage":0.0,"powerfactor":0.0,"relay":0,"lock":0,"prevmonth":58,"thismonth":0},{"port":5,"output":1,"power":0.0,"enabled":0,"current":0.0,"voltage":232.260444641,"powerfactor":0.0,"relay":1,"lock":0,"prevmonth":7579,"thismonth":159},{"port":6,"output":0,"power":0.0,"enabled":0,"current":0.0,"voltage":0.0,"powerfactor":0.0,"relay":0,"lock":0,"prevmonth":494,"thismonth":0}],"status":"success"}|u=6896104.83|l=0.69 0.56 0.55|876.5625 0.0 66396.5625 18.4375 2490.3125 651.5625 MF.v2.1.11')}

Bekomme ich, auch aktuell, nach jedem FHEM start.  :)
Hast Du da eine Idee?
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 03 Mai 2019, 15:55:20
@CoolTux , teste doch bitte mal die Version aus Antwort #202 , die wollte ich am WE so einchecken und sie dürfte den Fehler eigentlich nicht mehr haben.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 03 Mai 2019, 16:12:56
Kann ich leider nicht testen. Habe keine Testumgebung mit so einem Teil. Check einfach ein und mache dann bei Gelegenheit das Update.
Vielen Dank für die Antwort.


Grüße
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: netdom am 03 Juni 2019, 15:21:54
Hallo,

ich habe ein kleine Frage zum Logging. Ich habe schon seit ewigkeiten eine 6er Steckdose ohne größere Schwierigkeiten aktiv. Das einzige das mich nervt, im fhem.log schreibt er mir immer folgendes ins Log:

2019.06.03 15:18:32 2: az.verteilerdose - sensors  : 6

Soweit ich das verstanden habe, prüft er damit wohl wieviele Ausgänge die angesprochene Steckdose hat. (Wie) kann ich das Logging dieses konkreten Eintrags ins fhem.log unterbinden ? Ich habe schon mit event-change-reading und dem ändern des verbose Levels des konkreten Device probiert, aber ohne Erfolg. Zumal dieser Wert "sensors: 6" ja scheinbar kein Reading ist.

Hat jemand noch eine Idee ?

Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 05 Juni 2019, 15:02:46
teste doch bitte mal die Version aus Antwort #202 bzw. da es eine Level 2 Meldung ist sollte auch verbose 1 für Ruhe sorgen
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: netdom am 05 Juni 2019, 19:23:58
Hatte ich schon mal versucht, war aber wohl zu ungeduldig. Hat um die 10 Minuten gedauert bis er die Änderung übernommen hatte. Ist also erledigt mit verbose 1, danke.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 14 Januar 2020, 08:07:12
Ich habe die in 202 angehängte Version getestet.

2020.01.14 08:06:27 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UbiquitiMP.pm line 867.

Diese Meldung kam nach dem ersten start nach der Installation der Module, beim zweiten Start kam sie etwas verzögert dann noch mal.

2020.01.14 08:09:11 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UbiquitiMP.pm line 867.



Grüße
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 14 Januar 2020, 08:59:30
hmm , ist das bei dir die Zeile 867 ?
my $csrf         = ($FW_CSRF ? "&fwcsrf=$defs{$FW_wname}{CSRFTOKEN}" : '');
wenn ja, müssen wir leider etwas tiefer graben da ich die Meldung bei mir noch nicht hatte :(
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 14 Januar 2020, 09:21:02
hmm , ist das bei dir die Zeile 867 ?
my $csrf         = ($FW_CSRF ? "&fwcsrf=$defs{$FW_wname}{CSRFTOKEN}" : '');
wenn ja, müssen wir leider etwas tiefer graben da ich die Meldung bei mir noch nicht hatte :(

Ja da ist sie. Interessanter Weise habe ich die Meldung in meinem Testsystem nicht, aber da habe ich auch leider keine wirkliche Verbindung sondern lediglich eine error Meldung im Reading da kein physikalisches Device vorhanden ist. Also keine Steckdosenleiste.

Die Frage die sich stellt. Welche Variable ist gemeint? Ich tippe spontan auf $FW_CSRF. Ich werde das mal debuggen.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 14 Januar 2020, 09:26:56
2020.01.14 09:24:21 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_UbiquitiMP.pm line 868.
!!!DEBUG!!! - CSRFS ist:  und was anderes ist:
....
!!!DEBUG!!! - CSRFS ist:  und was anderes ist:
....
!!!DEBUG!!! - CSRFS ist:  und was anderes ist:

Das passiert beim Systemstart

Code
$hash            = $defs{$hash};
        my $state        = $hash->{STATE};
        my $name         = $hash->{NAME};
       
        print('!!!DEBUG!!! - CSRFS ist: ' . $FW_CSRF . ' und was anderes ist: ' . $defs{$FW_wname}{CSRFTOKEN} . "\n");
       
        my $csrf         = ($FW_CSRF ? "&fwcsrf=$defs{$FW_wname}{CSRFTOKEN}" : '');

        return if (defined(AttrVal($name, "stateFormat", undef)));
          #|| (int($hash->{PORTS}) < 2));

        my ($icon,$html,$cmd,$i,$title,$ostate,$link);
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: justme1968 am 14 Januar 2020, 09:30:27
kein use vars für $FW_CSRF und/oder modul geladen/benutzt bevor FHEMWEB geladen ist
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 14 Januar 2020, 09:33:38
Ja das ist auch meine Vermutung

Fix
my $csrf         = ( (defined($FW_CSRF) and $FW_CSRF) ? "&fwcsrf=$defs{$FW_wname}{CSRFTOKEN}" : '' );
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: Wzut am 14 Januar 2020, 09:35:00
THX Andre, also wenn es an FHEMWEB liegen sollte dann müsste ja ein return undef if(!$init_done);  Abhilfe schaffen.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: CoolTux am 14 Januar 2020, 09:41:03
THX Andre, also wenn es an FHEMWEB liegen sollte dann müsste ja ein return undef if(!$init_done);  Abhilfe schaffen.

Das sollte auch gehen denke ich.
Titel: Antw:Ubiquiti mFi/mPower Steckdosenleisten Wlan/Lan - neues Modul: 98_UbiquitiMP.pm
Beitrag von: justme1968 am 14 Januar 2020, 09:59:58
müsste gehen. rein theoretisch kann es aber auch fhem installationen ohne fhemweb device geben. da funktioniert das dann nicht.