Neues Modul: Easymeter (ersetzt durch 47_OBIS)

Begonnen von Crawler, 25 Januar 2016, 16:19:10

Vorheriges Thema - Nächstes Thema

willybauss

Auch für die rote LED gibt es was vernünftiges: Youless LS110, auszuwerten mit dem JSONMETER-Modul. Funktioniert an meinem PV-Erzeugungszähler bestens. Aber am Einspeisezähler halt nicht, weil er wie gesagt an den Lichtimpulsen die Stromrichtung nicht erkennen kann.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

Crawler

#46
Mit kleinen Änderungen müsste auch die Schaltung von der ersten Seite(diode tausche durch sfh309)+ raspi + eigenem Programm die gleiche Aufgabe erfüllen können
Die blinksignale sind auch gut mit den Arduino Lichtsensoren zu empfangen 
FHEM auf Raspi + HMLan + 14 Aktoren + OBIS(Strom) über GPIO

KölnSolar

Hab dann auch mal schnell das neue Modul mit meinem HAGER ehz getestet. Funktionierte auf Anhieb. Die Bezeichnung der Readings sollte man noch ändern: 31,51,71 sind die Stromstärke, also current und 21,41,61 sind Arbeit,  also power und nicht Energy(=Leistung).

Beim Hager ist es so, dass bei Einspeisung lediglich das Vorzeichen gewechselt wird. Deshalb hatte ich für mich das 70_SMLUSB.pm angepasst(aber nicht allgemein einsetzbar). Um mit meiner Einspeisung auf tatsächliche Verbrauchswerte zu kommen, hatte ich zusätzlich noch die Leistung meiner beiden einphasigen Wechselrichter eingelesen und Differenzreadings erstellt. Außerdem gibt es im Hager nur Phasenwerte, für die Gesamtwerte muss also noch über alle 3 Phasen addiert werden.

Ist so etwas(Gesamtarbeit,tatsächliche Arbeit) noch angedacht einzubauen oder ist es eben tatsächlich zu kompliziert, das Einlesen von readings aus einem anderen Device um Differenzwerte zu berechnen individuell zu programmieren ?

Grüße
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Icinger

Bezeichnung der readings: Kann ich gerne ändern, wird aber für die Leute blöd, die schon Log darauf haben.
Alternative dazu: Mit dem Attribut "Channels" anpassen.

Das Aufsummieren von L1-L3 kann ich gerne einfügen, würde ich dann als MeterType=Hager implementieren.
Betrifft das alle Geräte von Hager oder nur n bestimmtes Model?

Vorzeichenwechsel bei Einspeisung ist beim EasyMeter ebenfalls so.
Differenzreading wären sinnvoller mittels userReading zu lösen, glaube ich.
Das wird wohl zu speziell sein.
Sollte seitens anderer User auch Bedarf bestehen, kann man das aber gerne andenken.

lg, Stefan
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

KölnSolar

Hallo Stefan,

dass mit einem rename existierende Logs problematisch werden ist klar, aber die richtigen Bezeichnungen sollten die Readings doch schon haben. Meine Aussage war aber auch nicht ganz korrekt. Es muss heißen: 21,41,61 sind die Leistungen(=power) je Phase und nicht Energie(=Arbeit).

Eine Gesamtleistung für die Hager-Zähler über die Phasen aufzusummieren fände ich gut.

Bei der weiteren Überlegung zur tatsächlichen Verbrauchsleistung und Deinem Vorschlag das über CustomReadings zu lösen, ist mir noch in den Sinn gekommen, dass die Hagerzähler die Daten pushen, also ständig senden. Das führt zu recht vollen Logs (und performance-Einbußen ?). Gelöst ist das bei mir, indem das Attribut intervals dazu genutzt wird, nur in intervals-Zeitabständen die Daten zu verarbeiten. In 47_OBIS umsetzbar ? Aber Achtung, muss dann für jedes Reading gelten, was nämlich das eigentliche Problem bei dem permanenten Datenstrom ist !

Jetzt mache ich mir mal weiter Gedanken über die "echte" Verbrauchsleistung unter Berücksichtigung der Erzeugungsleistung mit CustomReadings. Hauptproblematik ist die Synchronität der Readings der beiden Devices. Aber vielleicht muss ich nur mein Wechselrichtermodul dafür von Intervall-Polling auf echtes Polling umstellen.....

Grüße
Markus

PS: Wäre der Thread nicht besser in sonstige Systeme aufgehoben ?

Grüße
Markus



RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Icinger

Achtung!

CustomReadings != userReading :)

ZitatAttribut intervals
Meinst du
event-min-interval
event-on-change-reading
event-on-update-reading
??

Du kannst am einfachsten ein attr event-min-interval .*:600 setzen, dann hast du nur alle 10 Minuten einen Eintrag im Logfile.

Das mit der Performance ist ein anderes Problem, da weiss ich nicht, wie ich das umgehen könnte.
Auch wenn ich nur jedes x-te Telegramm auswerten würde, kommen die Daten ja trotzdem im Sekundentakt in FHEM an und müssen teilweise ausgewertet werden. (Zumindest schon mal auf "Anfang/Ende Telegram").

lg, Stefan
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

eldrik

Hi,

ich hänge mal den Link, des Perl Skriptes an, welches ich bisher für das Abrufen der Daten benutzt habe vl. findest du ja nützlichen Code, für das setzen eines Intervals?

https://github.com/jschanz/easymeter/blob/master/bin/easymeter.pl

Greetz
Eldrik

willybauss

#52
Eigenverbrauch werde ich auch als userReading durch Summen-/Differenzbildung zwischen Hausstromzähler und PV-Zähler lösen. Das wäre sicher zu speziell, um es ins OBIS-Modul einzubauen - zumal es ja in der fhem.cfg ein Einzeiler ist.


event-min-interval ist die richtige Methode, um die Anzahl Datensätze im Log zu begrenzen, auch bei OBIS.


Die Geschichte mit der erhöhten Systemlast, wenn der Zähler pausenlos die Daten pusht, ist mir auch schon aufgefallen. Ich habe mal im Terminal einen "top" aufgerufen. Dann sah ich, dass perl ca. 0,7% CPU-Last erzeugt. Sobald ich den Lesekopf an den Zähler hänge steigt es auf 7 ... 12%. Stefan weiß schon darüber Bescheid, aber eine Lösung ist uns noch nicht eingefallen. Unten habe ich ein Bild aus SYSMON angehängt, das CPU-Frequenz und Prozessortemperatur zeigt. Immer wenn der Lesekopf Daten liefert wirds dem Raspi ziemlich warm. (Nachtrag: um 4:00 startete das Backup => andere Ursache für die erhöhte Last zu diesem Zeitpunkt)


Schlimmstenfalls müsste ich eine Hardwarelösung bauen, die den Durchfluss am USB-Kabel taktet. Aber bevor ich so eine Bastlerlösung baue frage ich nochmal im Forum, ob es nicht für fhem eine generelle Softwarebasierte Lösung gibt, also außerhalb des OBIS-Moduls. Das werde ich jetzt gleich machen.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

Icinger

Hmm, da wird auch JEDES Telegram ausgewertet, soweit ich das sehe.
Diese werden dann aber über jeweils 5 Minuten in ein File geschrieben, gemittelt und dann erst in Readings übertragen.

Ändert leider nicht wirklich was an der Performance.
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

willybauss

Zitat von: Icinger am 18 Februar 2016, 09:43:18
Hmm, da wird auch JEDES Telegram ausgewertet, soweit ich das sehe.
Diese werden dann aber über jeweils 5 Minuten in ein File geschrieben, gemittelt und dann erst in Readings übertragen.
OK, wenn man die Durchschnittsleistung der letzten 5 Minuten will (anstatt dem Einzelwert am Ende dieser 5 Minuten), dann kann man auch die Zählerstände dafür missbrauchen:



(Zählerstand_Ende - Zählerstand_Anfang) / Zeitdifferenz



In fhem-Code sieht das dann so aus (wobei Du die Hälfte weglassen kannst, wenn Du keinen Zweirichtungszähler hast):





attr Hausstrom_Zaehler userReadings P_Bezug_temp:energy_total differential { ReadingsVal("Hausstrom_Zaehler","energy_total",0)*3600000 }, P_Einsp_temp:feed_total differential { ReadingsVal("Hausstrom_Zaehler","feed_total",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)) }
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

Icinger

Was aber nichts an der Performace ändert, weil trotzdem jedes Telegram im Sekundentakt ausgewertet wird.
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

willybauss

Zitat von: Icinger am 18 Februar 2016, 09:51:28
Was aber nichts an der Performace ändert, weil trotzdem jedes Telegram im Sekundentakt ausgewertet wird.
schon klar. Ich wollte lediglich den Hinweis geben, dass es für die Durchschnittsleistung der letzten n Minuten keinen Spezialcode braucht.
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

FunkOdyssey

Danke für die Anpassung des ersten Threads und die Bilder.

eldrik

#58
Zitat von: Icinger am 18 Februar 2016, 09:43:18
Hmm, da wird auch JEDES Telegram ausgewertet, soweit ich das sehe.
Diese werden dann aber über jeweils 5 Minuten in ein File geschrieben, gemittelt und dann erst in Readings übertragen.

Ändert leider nicht wirklich was an der Performance.

Hi,

ich bin mir jetzt nicht 100%ig sicher, ob ich das Problem verstehe.

Fhem lauscht doch erst auf den Port wenn das Modul diesen aktiv öffnet oder? Ab diesem Zeitpunkt ist der Server mit der Verarbeitung der Daten beschäftigt.

Kann man nicht einen Parameter für einen Intervall hinterlegen, so dass der Port nur alle x Sekunden geöffnet wird und nach der Paketübermittlung und Anzeige in FHEM dieser wieder geschlossen wird?

Sollte jemand kein Intervall benötigen Intervall = 0 dann wird der Port nicht geschlossen und die Abarbeitung erfolgt kontinuierlich.

Greetz
Eldrik

Icinger

Danke für den Denkanstoß, Eldrik,

auf die Idee bin ich noch nicht gekommen :)

Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho