Neues Modul: Easymeter (ersetzt durch 47_OBIS)

[willybauss]

"Hero" himself hatte grade praktisch dieselbe Idee:

Alternativ fuegt man im Modul was zu event-min-interval Vergleichbares ein.

Jetzt hoffe ich nur, dass Linux friedlich reagiert, wenn an einem ungeöffneten USB-Port permanent Daten ankommen. Ich habe da so eine dunkle Erinnerung:
In der Zeit, als ich den Lesekopf schon hatte, aber noch nicht in FHEM integriert, da musste ich immer den USB-Stecker abziehen, weil fhem sonst nicht hoch kam. Aber evtl. hilft da auch löschen von

Code Auswählen Erweitern

global autoload_undefined_devices


[Icinger]

Bin schon dran an dem Thema........

[Icinger]

Anbei mal eine Version, die bei gesetztem "Interval"-Attribut nur genau zu diesen Zeiten auf Daten lauscht und ansonsten alles, was reinkommt, verwirft.

Sollte bei ständig sendenden Zählern einiges an performance bringen.

Weiters habe ich die Namen der Readings nochmal geändert.
Für alle, die jetzt schon auf gewisse Readings loggen, und das nicht mehr umstellen wollen:
Ein

Code Auswählen Erweitern

attr <name> channels {"21"=>"energy_L1","41"=>"energy_L2","61"=>"energy_L3","31"=>"power_L1","51"=>"power_L2","71"=>"power_L3","1"=>"energy_current","8.1"=>"energy_total","8.2"=>"feed_total"}
stellt den bisherigen Zustand wieder her.

Drittens wurde als MeterType noch "Hager" hinzugefügt.
Bei diesem Zähler werden nur die Verbräuche der einzelnen Phasen per Datagram gesendet, nicht die Summe.
Wird Hager als MeterType angegeben, werden die 3 Phasen aufaddiert und in ein Reading gesetzt.

Modul kommt morgen per Update, oder ihr könnt es euch hier schonmal runterladen.

Vorschau: Mir kam vorhin noch der Gedanke, ein "set <name> alignTime xx:xx" einzubauen, um das Intervall einmalig gegen eine bestimmte Uhrzeit (zB 00:00) auszurichten.

Sonstige Wünsche, Anregungen, Beschwerden wie immer hier bitte.

lg, Stefan

[willybauss]

Ich kanns mir erst morgen anschauen. Das habe ich hier gefunden - könnte helfen:

Hallo, mit dem Modul SMLUSB hatte ich ein ähnliches Problem: mein über den Volkszähler-Sensor angeschlossene Stromzähler treibt die Last stark nach oben. Ich konnte das Problem bei mir durch einen sehr kleinen Eingriff entschärfen: die USB-Anbindung der FHEM Module kennt 2 Mechanismen. Unter Linux wird mit Interrupts gearbeitet während unter Windows gepollt wird. Ich hab das Modul bei mir nun auf den Polling-Mechanismus umgestellt, obwohl mein System unter Linux läuft.Seitdem ist die CPU-Last wieder viel niedriger. Vielleicht hilft das bei dir ja auch... Gruß Leo

[KölnSolar]

Also der Hager funktioniert recht gut mit dem neuen OBIS. Ich hab mein eigengestricktes Modul nun abgelöst  Dank der Channel-Übersetzung konnte ich sogar meine "alten" Readings und damit die alten Logs und Plots verwenden.

Performance scheint OK.

Aber ein Problem habe ich: wenn ich attr zaehler interval xx im config-file verwende, startet fhem nicht mehr bzw. hängt. Im Log kommt nach zaehler device opened nichts mehr, was das Problem erklären könnte  Das setzen des Attributs im laufenden Betrieb funktioniert problemlos.

Wenn die Sonne aufgeht, kann ich auch meine neuen userReadings für die echten Verbräuche(=Zählerleistung+Erzeugung) testen...

Gute Nacht
Markus

[willybauss]

Habs jetzt doch gleich installiert.

OK, ich habs jetzt: man muss das interval Attribut setzen, sonst kommen keine Daten durch.
edit: gestrichen - ich habe ein anderes Problem, sh. unten

Die CPU-Last von perl (top) liegt jetzt bei 6 ... 10%. Das ist zwar weniger als vorher aber immer noch zehn mal so viel wie ohne OBIS-Modul  .

Weiters habe ich die Namen der Readings nochmal geändert.Für alle, die jetzt schon auf gewisse Readings loggen, und das nicht mehr umstellen wollen:Ein

Code Auswählen Erweitern

attr <name> channels {"21"=>"energy_L1","41"=>"energy_L2","61"=>"energy_L3","31"=>"power_L1","51"=>"power_L2","71"=>"power_L3","1"=>"energy_current","8.1"=>"energy_total","8.2"=>"feed_total"}stellt den bisherigen Zustand wieder her.

Verstehe ich das richtig: das bisherige energy_total wird durch 8.1 ersetzt, das bisherige feed_total durch 8.2? Dann stimmt bei mir was nicht: diese Readings bekomme ich gar nicht rein.

[willybauss]

bei mir gibts ein Problem. ich habe das neue Modul installiert, alle alten Readings gelöscht und dann erst mal eine Minimalkonfiguration genommen (auskommentierte Zeilen in der Config unten). Dann "shutdown-restart". Eigentlich hätte ich erwartet, dass im Minutentakt Readings "8.1" und "8.2" einlaufen, aber da kommt nichts.

Oder habe ich einen Denkfehler? Könnte auch sein, da ich mit 39° Fieber zuhause liege  -

Code Auswählen Erweitern


define Hausstrom_Zaehler OBIS /dev/serial/by-id/usb-Silicon_Labs_USB-IR-Kopf_001DDF17-if00-port0@9600,7,E,1
attr Hausstrom_Zaehler event-min-interval .*:50
attr Hausstrom_Zaehler interval 60
attr Hausstrom_Zaehler room Stromzaehler
# attr Hausstrom_Zaehler userReadings P_Bezug_temp:8.1 differential { ReadingsVal("Hausstrom_Zaehler","8.1",0)*3600000 }, P_Einsp_temp:8.2 differential { ReadingsVal("Hausstrom_Zaehler","8.2",0)*3600000 }, P_Bezug_Watt { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Bezug_temp",0)) }, P_Einsp_Watt { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Einsp_temp",0)) }
# attr Hausstrom_Zaehler verbose 3

define FileLog_Hausstrom_Zaehler FileLog /mnt/fhem/log/Hausstrom_Zaehler-%Y-%m.log Hausstrom_Zaehler:P.*Watt.*|Hausstrom_Zaehler:Zaehlerstand.*|Hausstrom_Zaehler:stat.*Last.*

define SVG_FileLog_Hausstrom_Zaehler_1 SVG FileLog_Hausstrom_Zaehler:SVG_FileLog_Hausstrom_Zaehler_1:CURRENT
attr SVG_FileLog_Hausstrom_Zaehler_1 label "Bezug $data{currval1} Watt, Einspeisung $data{currval2} Watt, at $data{currdate1}"
attr SVG_FileLog_Hausstrom_Zaehler_1 plotsize 840,300
attr SVG_FileLog_Hausstrom_Zaehler_1 room Stromzaehler

# define Hausstrom_Zaehlerstand statistics Hausstrom_Zaehler
# attr Hausstrom_Zaehlerstand ignoreDefaultAssignments 1
# attr Hausstrom_Zaehlerstand minAvgMaxReadings energy_total,feed_total
# attr Hausstrom_Zaehlerstand singularReadings Hausstrom_Zaehler:energy_total:Max:(Day|Month|Year)|Hausstrom_Zaehler:feed_total:Max:(Day|Month|Year)

# define GetZaehlerstand_Verbrauch_Month at *00:00:01 IF ($mday == 1) ( setreading Hausstrom_Zaehler Zaehlerstand_Verbrauch [Hausstrom_Zaehler:energy_total] )
# define GetZaehlerstand_Einspeis_Month at *00:00:01 IF ($mday == 1) ( setreading Hausstrom_Zaehler Zaehlerstand_Einspeis [Hausstrom_Zaehler:energy_feed] )


Noch was zu den neuen Namen:
Einrichtungszähler => 1.8.1
Zweirichtungszähler => 1.8.2
Einrichtungs-Zweitarifzähler => 1.8.1, 2.8.1  ==> die "8.1" ist nicht eindeutig

[KölnSolar]

das liegt wohl am Fieber 

Wenn Du das Channel-Attribut für 8.1 bzw. 8.2 nicht setzt(Deine Config.), müßtest Du die Zählerstande als Readings total_feed und total_consumption bekommen.

ABER: 1.8.1 ist NICHT ein Einrichtungszähler, sondern die Bezeichnung des Haupttarifs für Bezug eines Zählers bei Mehrtarifzählern und 1.8.2 NICHT ein Zweirichtungszähler, sondern dann Nebentarif für Bezug des Zählers. Bei einem 2-Richtungsmehrtarifzähler gibt es dann entsprechend 2.8.x für die beiden Tarife und Erzeugung. Lass doch mal kurz mit verbose5 laufen und Du siehst im Log, welche OBIS-Zeilen Dein Zähler auswirft.

@Stefan: Evtl. werden Mehrtarifzähler noch nicht unterstützt ?

Grüße
Markus

[Icinger]

Wenn Du das Channel-Attribut für 8.1 bzw. 8.2 nicht setzt(Deine Config.), müßtest Du die Zählerstande als Readings total_feed und total_consumption bekommen.

Richtig!

Nicht verwirren lassen, das "8.1" und "8.2" habe ich intern für 1.8.x und 2.8.x!
Theoretisch sollte Zweirichtungszähler schon gehn.

Wenn irgendwelche Readings nicht aufscheinen, bitte ein Verbos 5 machen und mir das Log davon schicken.
Kann ich mir heute abend dann ansehen, bin arbeiten.

Die CPU-Last von perl (top) liegt jetzt bei 6 ... 10%. Das ist zwar weniger als vorher aber immer noch zehn mal so viel wie ohne OBIS-Modul

Mehr Einsparungspotential hab ich leider nicht mehr, ausser ich würde wirklich die Schnittstelle ständig schließen und öffnen.
Dann wird aber leider das Log von der DevIo bei jedem öffnen mit 3 Zeilen gefüllt. Da müsste man mit Rudi reden, ob er das ändert.

Morgen gibts nochmal ein kleines Update:
-) Fehler in der Commandref (Der deutsche Text wird beim Englischen angezeigt)
-) Bei nicht gesetzten Interval wurde wirklich (sofern KEIN meterType angegeben) nur einmalig ein Nachrichtenframe ausgewertet.

lg, Stefan

[KölnSolar]

zwar ist die Sonne kaum zu sehen, aber Dank meines selbstgestrickten Moduls, welches die Erzeugungsleistung meiner Wechselrichter pollen kann, habe ich mir mit einem notify auf die Zählerdatenaktualisierung und einem defmod at mit 58 sec. Zeitverzögerung zur Ermittlung der Erzeugungsleistung einen Synchronisationsmechanismus gebastelt, der gut zu funktionieren scheint.

@Stefan: damit ist ein set aligntime für mich nicht notwendig. Ich glaube sogar, dass eine einmalige Synchronisation nicht ausrecht, weil die Intervalle ja nicht zu 100% genau ausgeführt werden und durch Performancebremsen sich unterschiedlich wieder verschieben.
Sicher, dass Du Mehrtarifzähler unterstützt ? Bei 2-Richtungsmehrtarifzählern gäbe es ja 4 Zählerstände !

Grüße
Markus

Edit: Das Modul 70_SMLUSB wird scheinbar immer noch gewartet.
http://forum.fhem.de/index.php/topic,14117.270.html
Macht es nicht Sinn die beiden Module "zusammenzuführen ?

[willybauss]

Wegen Performance:
Ich habe mal den Kollegen, der aus demselben Grund das SMLUSB-Modul umgebaut hat (sh. Beitrag Nr.63) gebeten, mir das modifizierte Modul zu schicken. Ggf. baue ich mir das in eine custom-Version des OBIS-Moduls ein.

Wegen Daten:
Es gibt ziemlich eigenartige Effekte:

   
• Nach einem Shutdown-Restart kommen keine Daten. Erst wenn ich das (bereits gesetzte) "intervals" Attribut nochmal setze funktioniert es ==> So ist das Modul nicht Reset-fest.
• Nach ein paar Minuten reißt der Datenstrom ab. Ich konnte ihn mit einer erneuten Redefinition von "intervals" wieder aufwecken. (nicht immer reproduzierbar)
• Wenn man im laufenden Betrieb das "channels" Attribut setzt oder löscht, hat das keine Auswirkung. Die Daten weden nach wie vor in die "alten" Readings geschrieben. Erst ein Shutdown-Restart behebt den Fehler. Ein reload 47_OBIS hilft nicht.
• Ich bekomme bei jedem Reading ca. 14 Zeilen ins Logfile: 7 mal P_Einsp_Watt, 7 mal P_Bezug_Watt. Alle mit demselben Timestamp. Das ist eigenartig. Wenn es daran läge, dass der "Zeitschlitz" fürs lesen der Daten für meinen Zähler zu lang wäre, dann würden es ja verschiedene Timestamps sein.  Deshalb habe ich "event-min-interval -+:15 eingefügt => geht. Aber die Frage, warum überhaupt die Werte so oft kommen, bleibt offen.
• Meine UserReadings ermitteln ja zunächst per "differential" die Leistung (_temp Werte), die dann im nächsten userReading gerundet werden. Fhem tauscht offenbar die Reihenfolge, in der die userReadings abgearbeitet werden, aus: ich sehe in den gerundeten Werten immer den vorherigen Wert. Eigentlich sollte der aktuelle Wert gerundet werden. So landen die Werte immer um 1 Minute versetzt im Log. Kann man das beeinflussen?

Nachtrag: hier noch die config:

Code Auswählen Erweitern



define Hausstrom_Zaehler OBIS /dev/serial/by-id/usb-Silicon_Labs_USB-IR-Kopf_001DDF17-if00-port0@9600,7,E,1
attr Hausstrom_Zaehler event-min-interval .*:15
attr Hausstrom_Zaehler interval 60
attr Hausstrom_Zaehler room Stromzaehler
attr Hausstrom_Zaehler userReadings P_Bezug_temp:total_consumption differential { ReadingsVal("Hausstrom_Zaehler","total_consumption",0)*3600000 }, P_Einsp_temp:total_feed differential { ReadingsVal("Hausstrom_Zaehler","total_feed",0)*3600000 }, P_Bezug_Watt { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Bezug_temp",0)) }, P_Einsp_Watt { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Einsp_temp",0)) }
attr Hausstrom_Zaehler verbose 5


define FileLog_Hausstrom_Zaehler FileLog /mnt/fhem/log/Hausstrom_Zaehler-%Y-%m.log Hausstrom_Zaehler:P.*Watt.*|Hausstrom_Zaehler:Zaehlerstand.*|Hausstrom_Zaehler:stat.*Last.*


define SVG_FileLog_Hausstrom_Zaehler_1 SVG FileLog_Hausstrom_Zaehler:SVG_FileLog_Hausstrom_Zaehler_1:CURRENT
attr SVG_FileLog_Hausstrom_Zaehler_1 label "Bezug $data{currval1} Watt, Einspeisung $data{currval2} Watt, at $data{currdate1}"
attr SVG_FileLog_Hausstrom_Zaehler_1 plotsize 840,300
attr SVG_FileLog_Hausstrom_Zaehler_1 room Stromzaehler


[Icinger]

Es gibt ziemlich eigenartige Effekte:

    Nach einem Shutdown-Restart kommen keine Daten. Erst wenn ich das (bereits gesetzte) "intervals" Attribut nochmal setze funktioniert es ==> So ist das Modul nicht Reset-fest.
    Nach ein paar Minuten reißt der Datenstrom ab. Ich konnte ihn mit einer erneuten Redefinition von "intervals" wieder aufwecken. (nicht immer reproduzierbar)
    Wenn man im laufenden Betrieb das "channels" Attribut setzt oder löscht, hat das keine Auswirkung. Die Daten weden nach wie vor in die "alten" Readings geschrieben. Erst ein Shutdown-Restart behebt den Fehler. Ein reload 47_OBIS hilft nicht.
    Ich bekomme bei jedem Reading ca. 14 Zeilen ins Logfile: 7 mal P_Einsp_Watt, 7 mal P_Bezug_Watt. Alle mit demselben Timestamp. Das ist eigenartig. Wenn es daran läge, dass der "Zeitschlitz" fürs lesen der Daten für meinen Zähler zu lang wäre, dann würden es ja verschiedene Timestamps sein.  Deshalb habe ich "event-min-interval -+:15 eingefügt => geht. Aber die Frage, warum überhaupt die Werte so oft kommen, bleibt offen.
    Meine UserReadings ermitteln ja zunächst per "differential" die Leistung (_temp Werte), die dann im nächsten userReading gerundet werden. Fhem tauscht offenbar die Reihenfolge, in der die userReadings abgearbeitet werden, aus: ich sehe in den gerundeten Werten immer den vorherigen Wert. Eigentlich sollte der aktuelle Wert gerundet werden. So landen die Werte immer um 1 Minute versetzt im Log. Kann man das beeinflussen?

Ich bin eigentliuch  nur beim ersten Punkt schuld ^^
Den fix dazu checke ich in ca. einer Stunde ein....oder so.....zumindest noch heute gg
Das mit den Channels im laufenden Betrieb kann ich nicht nachstellen. Wenn ich das Attribut ändere, wirds sofort beim nächsten Durchlauf berücksichtigt.
Die 14 Zeilen resultieren daher, dass du in deinem Userreading bei P_Bezug_Watt und P_Einsp_Watt keinen Trigger hast. Damit reagieren diese beiden Userreadings auf jedes einzelne Reading, das getzt wird.
Das FHEM die Reihenfolge tauscht, wäre mir auch noch nie aufgefallen.

damit ist ein set aligntime für mich nicht notwendig. Ich glaube sogar, dass eine einmalige Synchronisation nicht ausrecht, weil die Intervalle ja nicht zu 100% genau ausgeführt werden und durch Performancebremsen sich unterschiedlich wieder verschieben.

Das wird sowieso bei jedem neuen Interval-Aufruf neu gerechnet. Ähnlich wie bei einem "at"

Sicher, dass Du Mehrtarifzähler unterstützt ? Bei 2-Richtungsmehrtarifzählern gäbe es ja 4 Zählerstände !

Habe bisher noch von niemanden Daten von einem Zweirichtungszähler bekommen, kanns daher nur theoretisch sagen ^^

Das 70_SMLUSB werd ich mir mal anschaun.

lg, Stefan (der jetzt erstmal ein Geburtstagsbierchen trinkt gg)

[willybauss]

Das mit den 14 Zeilen habe ich nun mit einem Trigger gefixt. Danach ging zuerst gar nichts mehr (jetzt weiß ich auch wieder, warum ich den Trigger raus genommen hatte). Ich habe dann event-min-interval nochmal neu gesetzt (auf den alten Wert), dann ging wieder alles. Kommt mir bekannt vor.

Mit dem Rest warte ich erst mal die neue Version ab.


Ach ja:
Herzlichen Glühstrumpf, falls es Dein Geburtstag ist.


Gruß
Willy

[Icinger]

Herzlichen Glühstrumpf, falls es Dein Geburtstag ist.

Ja, hab ich. Danke!!!

Hab grad eine gefixte Version hochgeladen.
Wenn ihr nur ein reload macht und ein interval hinterlegt habt, bitte einmal dieses neu setzen. Ansonsten zieht das Standard-Interval, welches ich fix hinterlegt habe.

lg, Stefan

[KölnSolar]

Hi Stefan,

mittlerweile habe ich auch meine userReadings fast im Griff. Die Kumulation der Phasenleistungen zu einem Gesamtwert könnte ich ja eigentlich auch per userReading machen. Macht das mehr Sinn, als es im Modul zu kumulieren ? Im "Langzeittest" ist mir aufgefallen, dass es öfter 2-3 Logeinträge zur selben Zeit gibt:

Code Auswählen Erweitern

2016-02-22_09:11:00 zaehler Momentanleistung: 0
2016-02-22_09:11:00 zaehler Momentanleistung: 61
2016-02-22_09:11:00 zaehler Momentanleistung: 61


Meistens hat der erste Logeintrag einen Wert=0, was sich etwas unschön in den Grafiken auswirkt.

Performance: schaut man auf apptime, sieht es super aus; mit top leider hoher CPU-Verbrauch

Grüße
Markus