Neu: 77_SMAEM - Modul für SMA Energie Meter. Alternative zum Sunny Home Manager.

[Volker Kettenbach]

Ja

[privat58]

Ich beantworte mal selber. Mit zwei userReadings habe ich es jetzt gelöst und werte über ein readingsGroup aus.
Damit habe ich zwar den Stromausfall nicht erkannt, aber ein nicht aktualisieren des EnergyMeters. Da dieser bisher ohne Probleme durchlief, ist es das geringere Übel.
Eventuell braucht es mal jemand.
mvH

Code Auswählen Erweitern

attr EnergyMeter userReadings lastTrigger { TimeNow() } , lasttime {ReadingsAge('EnergyMeter','lastTrigger',0)}

defmod RG_EnergyMeter_Icon readingsGroup EnergyMeter:lasttime
attr RG_EnergyMeter_Icon fp_Allgemein 288,495,1,Netz,
attr RG_EnergyMeter_Icon group z_Anzeige
attr RG_EnergyMeter_Icon noheading 1
attr RG_EnergyMeter_Icon nolinks 1
attr RG_EnergyMeter_Icon nonames 1
attr RG_EnergyMeter_Icon notime 1
attr RG_EnergyMeter_Icon valueFormat {($VALUE < '1')?"measure_power_meter\@green":"measure_power_meter\@red"}
attr RG_EnergyMeter_Icon valueIcon %VALUE

Hallo,
ich nutze das Modul seit einer ganzen Zeit und es läuft ohne Probleme.
Weiß jemand eine Möglichkeit, wie man einen Stromausfall erkennen kann? Die Readings bleiben auf dem alten Wert stehen und es kommt kein "timeout".
Zum Hintergrund. Ich habe eine PV-Anlage mit SMA SunnyBoy und einen Sunny-Island mit Batterie.
wenn Stromausfall ist, schaltet das ganze "Haus" um und es wird als Insel weiterversorgt. Der EnergyMeter ist noch vor der Umschaltbox eingebaut. Leider kann ich das reading "phase_1_uac" des SunnyBoy nicht nutzen, da derSunnyIsland ein Netz bereitstellt.
Selber merkt man oft erst nach einer ganzen Weile das Stromausfall ist, da alles normal weiter geht.
Steffen

[klausg]

Hallo,
ich habe meine SMA Geräte in ein VLAN gesteckt. Der FHEM Server hängt im allgemeinen LAN und hat eine 2. Verbindung in das VLAN für SMA. Leider bekommt das 77_SMAEM Modul in dieser Konfiguration die Multicasts nicht mehr mit. Wenn ich mit tcpdump die Multicast Adresse trace sehe ich, dass die Multicasts ankommen. Ich habe versucht die die Multicasts mit dem Tool smaem_test.pl zu lesen. Aber auch das Tool sieht nichts von den ankommenden mCast Paketen. Nach der Man-Page von IO-Socket-Multicast kann man bei mcast_add() neben der mCast Adresse auch das Interface angeben. Mit dem Aufruf  mcast_add('239.12.255.254','eth0.50') funktioniert die Auswertung der SMA mCasts mit dem Tool smaem_test.pl wie beschrieben.

In der Man-Page von IO-Socket-Multicast steht: "If no interface is specified, then the multicast group is joined on INADDR_ANY, meaning that multicast transmissions received on any of the host's network interfaces will be forwarded to the socket." Das ist wohl nicht korrekt: In https://rt.cpan.org/Public/Bug/Display.html?id=129212 wird aufgezeigt, dass mit 'INADDR_ANY' unter Linux immer nur die mCasts des ersten Interface abonniert werden, in meinem Setup wird das immer 'eth0' sein.

Kennt das Problem jemand und gibt es eine Umgehung? Könnte man dem Modul einen optionalen Parameter Interface geben um das Problem zu umgehen?

Viele Grüße
klausg

[DS_Starter]

Hallo klausg,

ich kenne zwar das Problem nicht, aber das Modul um die optionale Angabe eines Interfaces zu erweitern sollte kein Problem sein.
Unklar ist mir die Angabe von "eth0.50" wenn dein Interface "eth0" heißt. Kannst du mich aufklären ?

LG,
Heiko

[Volker Kettenbach]

50 ist die vlan id.
https://wiki.archlinux.org/index.php/VLAN

Achtung: es gibt verschiedene Möglichkeiten wie das Interface heißen kann. Z.b. Kann es auch vlan50 heißen. Es reicht daher nicht, die vlan id in fhem anzugeben. Es muss das ganze interface sein.

[Volker Kettenbach]

Es wäre besser, wenn klausg mal versuchen würde, im Linux die Multicast Route auf das andere Interface zu legen, bevor fhem startet.
Denn laut dem Bug Report für IO-Socket-Multicast wird das Interface anhand der Routing Tabelle gewählt.

ip route add 239.12.255.254 dev eth0.50

[DS_Starter]

Danke für die Info Volker. Wenn das außerhalb von FHEM stringend gelöst werden könnte wäre es sicherlich besser, sehe ich auch so.
Schauen wir mal was klausg hinbekommt.

[klausg]

Vielen Dank für Eure Antworten.

Ja, '.50' ist die VLAN Id des VLANs in dem der SMA Wechselrichter und das Energy Meter verbunden sind. Mit dem VLAN erreiche ich, dass die Multicasts nicht überall im Netz verbreitet werden und insbesondere keine WLAN-Bandbreite verbrauchen. So haben die Geräte Zugriff aus das Internet, nicht aber auf mein LAN. Ich weiss nicht wie gut SMA im programmieren von Security-fixes ist.

Der FHEM Server hängt am normalen LAN. Über das zusätzlich VLAN kann er die Multicasts der SMA Geräte empfangen und mitloggen. Der zitierte Bug Report zu IO-Socket-Multicast bezieht sich nur auf die Dokumentation. Eine Änderung in der Funktion von IO-Socket-Multicast erwarte ich dabei nicht.

Ich habe bei mir das Interface in den mcast_add() Call eingebaut und es funktioniert. Aber meine Änderung wieder beim nächsten Updates des Moduls wieder überschrieben werden. Falls gewünscht, kann ich einen Vorschlag zur Implementierung beitragen.

Den Hinweis auf die Routing-Table hatte ich gesehen. Leider ist Reihenfolge in der Routing-Table nicht zu kontrollieren. Oben steht immer die Default Route. Die Reihenfolge der Netzwerkinterfaces kann man nicht beeinflussen. Zuerst wird die Adresse für das Standard-Interface (ohne VLAN) konfiguriert und dann das/die VLANs. Das gleiche Problem hat man wenn der FHEM Server mehrere Netzwerkkarten hat. Auch dann wird SMAEM nur wenn man per Zufall die Netzwerkkarte mit den die Multicasts vorne hat, diese empfangen. Deshalb plädiere ich dazu den optionalen Parameter Interface für das Modul zu implementieren.

Übrigends hatte stixif am 08 April 2018 das gleiche Problem gehabt. Sucht nach VLAN im Beitrag.

Viele Grüße
Klaus

[DS_Starter]

Ich habe die Option mal eingebaut. Das define wäre jetzt

  define <Name> SMAEM [<Interface>]

Allerdings bekomme ich bei mir einen Perl Fehler zurück, obwohl die Syntax und das Interface richtig ist. Ich habe extra eine Abfabgroutine eingebaut, damit FHEM nicht abschmiert.

Code Auswählen Erweitern


Socket error in define ('239.12.255.254','ens192'): unknown or unconfigured interface 'ens192' at ./FHEM/77_SMAEM.pm line 194.


Interface sieht bei mir so aus:

Code Auswählen Erweitern


ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.45  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::20c:29ff:fe6c:59a0  prefixlen 64  scopeid 0x20<link>
        inet6 2003:f3:ff11:d29d:20c:29ff:fe6c:59a0  prefixlen 64  scopeid 0x0<global>
        ether 00:0c:29:6c:59:a0  txqueuelen 1000  (Ethernet)
        RX packets 39320539  bytes 93272712048 (86.8 GiB)
        RX errors 0  dropped 3050  overruns 0  frame 0
        TX packets 28457144  bytes 77041236525 (71.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Sollte also korrekt sein. Und in der der CPAN Bibliothek ist es auch so beschrieben. Kann es mir momentan nicht erklären.
Ohne Angabe Interface ist es natürlich rückwärts kompatibel und läuft.

Probierts mal bitte aus. Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:

Code Auswählen Erweitern


"wget -qO ./FHEM/77_SMAEM.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/77_SMAEM.pm"


Danach restarten.

Grüße,
Heiko

[DS_Starter]

Jetzt klappts. Hatte doch noch einen Fehler drin. 

[klausg]

Hallo Heiko,

vielen Dank für die superschnelle Erweiterung des Moduls.

Die Quotes um den Interface name sind nicht notwendig. Ich hatte direkt in das Modul den Interface Namen reingeschrieben. Dazu musste ich den String quoten. Mit der Variable $if brauchst Du das nicht.

Funktioniert super.

Viele Grüße
Klaus

[DS_Starter]

Die Quotes um den Interface name sind nicht notwendig.

Ja, mehr noch. Das war auch der Grund für das fehlerhafte Verhalten. Geht mir allerdings nicht ein.

Habe es gerade auch noch auf meiner Produktion getestet. Läuft astrein.

Ich denke das ist ein sehr hilfreiches Feature und stört auch nicht weil absolut rückwärtskompatibel. Ich würde noch die Commandref ergänzen und dann ins Repo stellen.

@Volker ?

Grüße,
Heiko

[klausg]

Wahrscheinlich prüft IO-Socket-Multicast ob das Netzwerkinterface im System existiert. Bei Dir im System gibt es ens192 aber nicht 'ens192'. Warum der Error bei dem Call FHEM mit abstürzen lässt ist mir schleierhaft.

Viele Grüße
Klaus

[DS_Starter]

Bei Dir im System gibt es ens192 aber nicht 'ens192'.

Da hast du sicherlich recht.

Nur CPAN beschreibt die Syntax auch so:

Code Auswählen Erweitern


# Add a multicast group to eth0 device
$s->mcast_add('225.0.0.2','eth0');

Naja, seis drum. Wir haben es ja erkannt. 

[Volker Kettenbach]

@Volker ?

Ja