Photovoltaik mit Eigenverbrauch Steuerung (Kostal plenticore; EM410)

Begonnen von ch.eick, 16 Juli 2019, 19:18:12

Vorheriges Thema - Nächstes Thema

ch.eick

Zitat von: Prof. Dr. Peter Henning am 28 Mai 2020, 17:58:48
Ich betreibe meine PV-Anlage jetzt seit 13 Jahren (ohne Speicher, weil schön hohe Einspeisevergütung). Klare Aussage aus der Auswertung wirklich vieler Daten: Eine Vorhersage ist NICHT möglich. Unter anderem ist aus der Windsituation in 7m Höhe keineswegs ableitbar, wie die in 200m Höhe aussieht.

Edit: Ich habe mir den EEBUS-Kram heruntergeladen und genau angesehen. Auf Grund der hohen Asynchronität und der ziemlich engen Timing-Vorgaben sehe ich wenig Chancen, das direkt in FHEM zu integrieren.  Auch solche Dinge wie Key Management etc. würden FHEM eher ausbremsen. Eine größere Chance sehe ich, dass es einen Konnektor EEBUS <-> MQTT gibt, der als eigenständiges Programm ohne die (vergleichsweise langsame) Main Loop von FHEM existiert
Vielen Dank fuer die kompetente Rueckmeldung. Die Aussage zur Vorhersage deckt sich absolut mit meinen Erfahrungen und Beobachtungen.
Beim EEBUS sind halt schon noch einige Layer mehr, da sollte man wirklich mal abwarten, was und wie die "Profis" das umsetzen. Die verschiedenen Implementierungen im Forum sind fuer meine Faelle vollkommen ausreichend.
Wie bereits geschrieben koennte man das in ein generisches Modul umsetzen, wenn man es wirklich brauchen sollte.

Viele Gruesse
     Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

gvzdus

Auch meinerseits Danke für die Einschätzung.

ZitatIch betreibe meine PV-Anlage jetzt seit 13 Jahren (ohne Speicher, weil schön hohe Einspeisevergütung). Klare Aussage aus der Auswertung wirklich vieler Daten: Eine Vorhersage ist NICHT möglich. Unter anderem ist aus der Windsituation in 7m Höhe keineswegs ableitbar, wie die in 200m Höhe aussieht.

Für mich die Solaranlage jetzt seit Monaten Lieblingsspielzeug, und ich starre auf das Radarbild von "WetterOnline", um zu rätseln, ob da noch Hoffnung auf klaren Himmel besteht oder ich die Waschmaschine jetzt schon anwerfe.
Vom Bodenwind lässt sich keine Prognose ableiten, der ist sowohl chaotisch und auch typischerweise um 30 Grad nach links verdreht. Aber auch bei den Wolken können es verschiedene Layer sein, die in unterschiedliche Richtungen ziehen.
Meine Überlegung ging eher dahin, Wind-Vektoren aus Bildern wie eben bei WetterOnline zu errechnen und danach zu prognostizieren, was Solaranlagen "30 Minuten gegen den Wind vor mir" produziert haben. Auch das geht hinter einem Bergrücken natürlich ggf. nicht auf.

Außerdem weiß ich aus der Luftfahrt, wie extrem schwer und fehleranfällig auch heute noch eine Nebelprognose ist.

Also ja: Kniffelig ist es, aber mit den Daten, die Solarportalbetreiber wie z.B. die Inverterhersteller haben, sehe ich es als nicht chancenlos an.

ch.eick

Hi.
Okay für Forecast hatte ich noch eiinen anderen Thread ;-) , das sollten wir dann mal dahin auslagern.

Gruß Christian

Gesendet von meinem SM-G930F mit Tapatalk

RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

speedAmaster

Hallo Christian ch.eick,
ich habe nun auch meinen Plenticore mit EM410 (KSEM), die BYD Batterie läßt noch auf sich warten.

Danke an deine kompetenten Code-Teile die mir zu einem jump-start geholfen haben! Danke, dass du deine Arbeit teilst!

Leider ist der status meines EM410 in FHEM (über ModbusAttr) immer noch disconnected (liegt vermutlich am Paßwort). Wie kann ich dies denn einstellen?

Viele Grüße
Bernd

Mumpitz

Hallo zusammen

Das Installationsdatum meiner PV Anlage, Plenticore mit BYD Speicher, rückt ebenfalls näher. Nun lese ich von ch.eick wie auch bei speedAmaster, dass je ein EM410 verbaut worden ist. Mein Installateur hat mir jedoch den Plenticore sowie den BYD verkauft und dabei angegeben, dass der Plenticore / BYD bereits einen Energiemesser integriert habe, um zu erkennen, wann der Speicher liefern und wann aufladen kann.

Aus welchem Grund ist so ein Energiemesser nötig. Sollte ich so einen ebenfalls noch einbauen?

Prof. Dr. Peter Henning

Der EM410 ist kein Energie"messer", sondern ein Energiemanager. Damit sollen Verbraucher "intelligent" zu- oder abgeschaltet werden, mit dem Ziel eines 100%igen Eigenverbrauchs der erzeugten Leistung.

Allerdings sind die Algorithmen dabei nicht transparent, und der Preis eines Komplettsystems übersteigt das Einsparpotenzial m.E. bei Weitem. Auch das Ziel ziehe ich hiermit stark in Zweifel: Für mich ist nicht maximale Einsparung das Ziel, sondern maximaler Komfort für die Bewohner.

Die bessere Lösung, ein Energiemanagement a.)transparent und b.)zu überschaubaren Kosten zu realisieren, ist ein FHEM-basiertes Empfehlungssystem.

LG

pah

gvzdus

> Die bessere Lösung, ein Energiemanagement a.)transparent und b.)zu überschaubaren Kosten zu realisieren, ist ein FHEM-basiertes Empfehlungssystem.

Nichts ist doch schwerer erträglich, als einer Lösung zuzusehen, die Geld gekostet hat und es schlechter macht, als man es selbst könnte (oder zu können meint). Und den Schabernack, den ich mit dem Takten der HK-Pumpe oder des Tiefkühlschranks mache, würde ich keinem Hersteller erlauben: Ich weiß, wie alt die Tiefkühltruhe ist und dass die Heizung absehbar rausfliegt, deswegen frage ich mich nicht, ob das Takten auf die Lebenserwartung geht.

Gruß vom geöffneten Bier, dessen Kühlschrank nur läuft, wenn gerade Überschuss da ist - als Statement zu "Sparen versus Komfort" :-)

ch.eick

Hallo zusammen,
ich zitiere jetzt mal nicht jede Anmerkung und versuche mal aus meiner Erfahrung zusammen zu fassen.

Der Plenticore misst natuerlich alle Werte, die er direkt erfassen kann selber und steuert auch den Speicher selber.
Der KSEM wird benoetigt, um die 70% Regelung entsprechend den Vorgaben des EVU einzuhalten, da der Plenticore nicht direkt hinter dem Zaehler messen kann. Weiterhin wird der KSEM z.B. fuer die Ansteuerung einer Wall Box verwendet, wenn das in den naechsten Jahren planen wuerde.

Die Regelung des Plenticore ist schon recht gut. Bei der Speicher Steuerung gaebe es natuerlich noch Luft nach oben, wenn man schnelle Wetterwechsel mit einbeziehen koennte. In einer bestimmten Wetterkonstellation wuerde ich mir wuenschen, dass das Laden schon frueher beginnt, aber da denke ich schon laenger drueber nach. Momentan bin ich bereits seit ueber zwei Monaten vollstaendig Autark. Der Zweirichtungszaehler kam ca vor 7-8 Wochen, seit dem habe ich 1310 KWh zusaetzlich eingespeist und nur 5 KWh bezogen, was an einem kleinen Fehler meinerseits gelegen hat und mich 3 KWh gekostet hat.

Der KSEM muss momentan noch per RS485 angeschlossen werden, da Kostal noch an der Modbus/TCP Kommunikation arbeitet, um die Steuerung ueber das Netzwerk machen zu koennen.

Die Nutzung von Modbus/TCP muss muss zuerst auf dem KSEM aktiviert werden, da Kostal diese ja noch nicht ueber LAN nutzt. Bei Bedarf koennte ich das bei mir nochmal nachschauen.

Zitat
> Die bessere Lösung, ein Energiemanagement a.)transparent und b.)zu überschaubaren Kosten zu realisieren, ist ein FHEM-basiertes Empfehlungssystem.
Genau das habe ich implementiert und es laeuft bereits sehr gut. Ohne diesen Eingriff laeuft der Plenticore auch schon sehr gut und steuert den Speicher auch sehr gut.
Ueber FHEM greife ich nur bei den Hausgeraeten ein, bei denen ich grossen Energiebedarf gezielt in die Tagesstunden legen kann, ohne auf irgendwelchen Komfort zu verzichten.

1) Die Waschmaschine mit Walzenprogrammsteuerung
2) Der Wirlpool, der eh jeden Tag laeuft

3) Die LWP fuer Warmwasser und Heizung.
   Hier hat sich herausgestellt, dass der PV Modus im Sommer nicht unbedingt notwendig ist und im Durchschnitt auch nicht wirklich etwas einspart.
   Sehr gut ist der PV Modus der LWP in der Uebergangszeit und im Winter. Wenn PV Ueberschuss vorhanden ist, kann man so WW z.B  fuer zwei Tage puffern,
   was in unserem zwei Personen Haushalt gut klappt. Bei Rueckfrage kann ich hierzu auch gerne noch mehr Information/Erfahrung beisteuern.

4) Das Thema Kuehschrank oder Truhe ist ja eine gespaltene Diskussion

Generell hat der Plenticore, bzw. das Kostal Portal noch keine Moeglichkeit Geraete zu steuern, so wie es bei SMA bereits implementiert waere. Meine Beitraege sind bezueglich der Parametrisierung, eine Ableitung aus dem SMA Portal gewesen und dank FHEM somit frei von Cloud/Internet.

Aus meinem Gefuehl heraus wuerde ich sagen, dass man ohne FHEM, also nur der Plenticore mit dem Speicher bereits sehr gut ueber den Sommer kommt. Hierbei sollte man natuerlich nicht einen Pool nachts aufheizen, aber den hat ja auch nicht jeder im Haushalt.
Mein Traum waere im Jahresschnitt auf eine Autarkie von 80% zu kommen, man muss ja immer ein Ziel haben :-) Ich habe mal die Bilanz von heute angehaengt.

Gruss
    Christian

RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Zitat von: gvzdus am 14 Juni 2020, 21:37:36
> Die bessere Lösung, ein Energiemanagement a.)transparent und b.)zu überschaubaren Kosten zu realisieren, ist ein FHEM-basiertes Empfehlungssystem.
Nichts ist doch schwerer erträglich, als einer Lösung zuzusehen, die Geld gekostet hat und es schlechter macht, als man es selbst könnte (oder zu können meint). Und den Schabernack, den ich mit dem Takten der HK-Pumpe oder des Tiefkühlschranks mache, würde ich keinem Hersteller erlauben: Ich weiß, wie alt die Tiefkühltruhe ist und dass die Heizung absehbar rausfliegt, deswegen frage ich mich nicht, ob das Takten auf die Lebenserwartung geht.
In Bezug auf den Kuehlschrank springt der ja eher weniger an, dafuer aber einmal etwas laenger um die Temperatur wieder heraus zu holen. Ich sehe da jetzt kein Problem.

Dei unserer LWP wird die HK-Pumpe auch getaktet, was mit der Einstellung Pumpenoptimierung im Herstellermenue einzustellen ist. Ergo machen die Hersteller das auch so. Ich wuerde nur halt die Abstaende nicht zu kurz waehlen.

Bei meiner LWP versuche ich durch den PV Modus, der den Puffer Ueberheizt, einig LWP Heizungseinschaltungen aus der Nacht in den Tag zu verlagern. WW wird durch die Sperrzeiten auch auf 14:00 Uhr geschoben, da dort die hoechste Aussentemperatur zu erwarten ist. Der Plenticore mit dem Speicher liefert meistens dann auch die volle Leistung. Oft hat es im Winter dann auch noch gereicht den Speicher wieder nachzuladen, der dann oft bis 21:00 Uhr oder manchmal auch bis 01:00 Uhr nachts gereicht hat. Im Winter muss man halt auch bedenken, dass die LWP nachts nachheizt, da stehen jedoch noch weitere Versuche im naechsten Winter an.
Die Nachtabsenkung wird jetzt ja auch gerne Taganhebung genannt ;-)

Viele Gruesse
      Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Zitat von: Prof. Dr. Peter Henning am 14 Juni 2020, 16:50:32
Die bessere Lösung, ein Energiemanagement a.)transparent und b.)zu überschaubaren Kosten zu realisieren, ist ein FHEM-basiertes Empfehlungssystem.
Hierbei ist mein Ansatz, zuerst dem Hersteller die Optimierung zu ueberlassen und dann den letzten Rest mit FHEM noch herauszuholen. Wie bereits geschrieben 60% Autarkie ohne Eingriffe nur durch die Hersteller Loesung und das Ziel dann auf 80% mit FHEM Unterstuetzung.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

speedAmaster

#70
Hallo Christian,

ZitatDie Nutzung von Modbus/TCP muss muss zuerst auf dem KSEM aktiviert werden, da Kostal diese ja noch nicht ueber LAN nutzt. Bei Bedarf koennte ich das bei mir nochmal nachschauen.

Ich habe euf meinem KSEM den Modbus aktiviert. Allerdings keinen Slave.

Unklar ist mir nur, ob ich für ModbusAttr auch das KSEM Paßwort brauche. Aktuell bekomme ich noch "disconnected" über FHEM.

Woran könnte das denn liegen?

Gruß
Bernd

speedAmaster

Hallo Christian,

ich habe eben Deinen anderen Kommentar im Foum gefunden (KOSTAL Smart Energy Meter auslesen: #3): https://forum.fhem.de/index.php/topic,109749.msg1037838.html#msg1037838

ZitatDort habe ich den Kostal Wechselrichter als Master mit Port 1502 eingetragen. Diese Verbindung dient momentan nur zur zusaetzlichen Datenuebermittlung und reicht noch nicht fuer die Steuerung des WR. Zusaetzlich wird die RS485 fuer den WR benoetigt.

Zum Auslesen des KSEM muss dann noch "Enable Slave" aktiviert werden.

Nun kann man mit dem Modbus TCP Modul von FHEM die Verbindung zum KSEM aufbauen und die Register auslesen, so wie ich es schon verlinkt habe.
Zu beachten ist, das die Slave Verbindung ueber Port 502 laeuft.

Damit habe ich jetzt die Verbindung geschafft! Muss mich jetzt noch durch die Werte quälen und zusehen, ob wirklich der Plenticore alle Werte vom KSEM hat.

VG
Bernd

ch.eick

Hallo Bernd,
die Werte vom KSEM habe ich hier beim Plenticore mit Modbus/TCP ausgelesen und entsprechend der Kostal Dokumentation benannt. Blanks sind mit "_" ersetzte. In der Dokumentation sind die Werte vom KSEM mit "(powermeter)" im Namen angegeben.
Fuer die Statistik und Bilanz findest Du hier auch bereits fertige Beispiele. Die Statistiken vom Plenticore sind etwas anders auszulesen und nicht mit Modbus/TCP zu erreichen. Dazu habe ich jedoch in anderen Forumen gewildert und eine Python Loesung zusammen gestellt.

Somit braucht man nichts mehr selber im FHEM zu sammel oder aufzusummieren.
Die Bilanz habe ich von den SMA Kollegen, hier aus dem Forum, uebernommen und auf den Plenticore angepasst. Durch den KSEM muss man auch nicht einen separaten Lesekopf fuer den EVU Zaehler haben. Im Listing habe ich bewusst alle Werte, auch die vom KSEM, aus dem Plenticore ausgelesen, damit die Werte Zeitlich synchron sind. Ob KSEM oder EM300 ist auch egal.
Diese Bilanz beruecksichtigt, hoffendlich richtig, auch den Speicher am Plenticore, was mich einige schlaflose Naechte gekostet hat :-) Ueber den Wirkungsgrad des Speichers (Laden/Entladen) habe ich mir keine Gedanken gemacht.

Hier geht es zum auslesen des  KSEM

Bei mir gehen alle Loggingwerte ins DBLog, wo ich auch schon einige Datenbankauswertungen zugesteuert habe. Hier werde ich mich noch mit einer Jahres Bilanz beschaeftigen, um z.B. das Vorjahr noch in der Bilanz anzeigen zu koennen, was jetzt ja nicht sichtbar ist. Aber das kann man sich mit DBRep ja wieder aus der DB rausholen.

Viele Gruesse
     Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Zitat von: speedAmaster am 15 Juni 2020, 14:45:58
Unklar ist mir nur, ob ich für ModbusAttr auch das KSEM Paßwort brauche. Aktuell bekomme ich noch "disconnected" über FHEM.

Woran könnte das denn liegen?

Wenn Du eine Definition von mir kopiert hast, koennte eventuel noch "disable 1" gesetzt sein. Also einfach das attr loeschen, oder auf 0 setzen.

Es ist nach der KSEM Kofiguration kein Passwort notwendig!

Hier nochmal die aktuellste Version, aber Achtung, einige Werte werden noch nicht richtig decodiert, da gibt es noch einen Thread dazu.
Mit "attr PV_KSEM dev-type-INT16_Current-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Current_SF",0))" habe ich die Umrechnung nach der Kostal Dokumentation umgesetzt.
Es werden auch noch nicht alle Werte gelesen, da die Werte ja im Plenticore verfuegbar sind und ich noch keine Zeit hatte es zu kompetieren.

defmod PV_KSEM ModbusAttr 1 60 [IP-Adresse]:502 TCP

attr PV_KSEM DbLogExclude .*
attr PV_KSEM alias PV_Energy_Manager
attr PV_KSEM comment Kostal EM410 Energy Manager
attr PV_KSEM dev-h-defPoll 1
attr PV_KSEM dev-type-INT16-len 1
attr PV_KSEM dev-type-INT16-unpack s>
attr PV_KSEM dev-type-INT16_Current-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Current_SF",0))
attr PV_KSEM dev-type-INT16_Current-format %.2f
attr PV_KSEM dev-type-INT16_Current-len 1
attr PV_KSEM dev-type-INT16_Current-unpack s>
attr PV_KSEM dev-type-INT16_Freq-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Freq_SF",0))
attr PV_KSEM dev-type-INT16_Freq-format %.2f
attr PV_KSEM dev-type-INT16_Freq-len 1
attr PV_KSEM dev-type-INT16_Freq-unpack s>
attr PV_KSEM dev-type-INT16_PF-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_PF_SF",0))
attr PV_KSEM dev-type-INT16_PF-format %.2f
attr PV_KSEM dev-type-INT16_PF-len 1
attr PV_KSEM dev-type-INT16_PF-unpack s>
attr PV_KSEM dev-type-INT16_Power-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Power_SF",0))
attr PV_KSEM dev-type-INT16_Power-format %.2f
attr PV_KSEM dev-type-INT16_Power-len 1
attr PV_KSEM dev-type-INT16_Power-unpack s>
attr PV_KSEM dev-type-INT16_VA-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_VA_SF",0))
attr PV_KSEM dev-type-INT16_VA-format %.2f
attr PV_KSEM dev-type-INT16_VA-len 1
attr PV_KSEM dev-type-INT16_VA-unpack s>
attr PV_KSEM dev-type-INT16_VAR-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_VAR_SF",0))
attr PV_KSEM dev-type-INT16_VAR-format %.2f
attr PV_KSEM dev-type-INT16_VAR-len 1
attr PV_KSEM dev-type-INT16_VAR-unpack s>
attr PV_KSEM dev-type-INT16_Voltage-expr $val * (10 ** ReadingsNum("$name" ,"M_AC_Voltage_SF",0))
attr PV_KSEM dev-type-INT16_Voltage-format %.2f
attr PV_KSEM dev-type-INT16_Voltage-len 1
attr PV_KSEM dev-type-INT16_Voltage-unpack s>
attr PV_KSEM dev-type-STR32-expr $val =~ s/[\00]+//gr
attr PV_KSEM dev-type-STR32-format %s
attr PV_KSEM dev-type-STR32-len 16
attr PV_KSEM dev-type-STR32-unpack a*
attr PV_KSEM dev-type-UINT16-format %s
attr PV_KSEM dev-type-UINT16-len 1
attr PV_KSEM dev-type-UINT32-format %s
attr PV_KSEM dev-type-UINT32-len 2
attr PV_KSEM dev-type-UINT64-expr $val/10000
attr PV_KSEM dev-type-UINT64-format %s
attr PV_KSEM dev-type-UINT64-len 4
attr PV_KSEM dev-type-UINT64-unpack Q>
attr PV_KSEM disable 0
attr PV_KSEM group PV Eigenverbrauch
attr PV_KSEM icon measure_power
attr PV_KSEM obj-h40071-reading M_AC_Current
attr PV_KSEM obj-h40071-type INT16_Current
attr PV_KSEM obj-h40071-unpack f>
attr PV_KSEM obj-h40072-reading M_AC_Current_A
attr PV_KSEM obj-h40072-type INT16_Current
attr PV_KSEM obj-h40073-reading M_AC_Current_B
attr PV_KSEM obj-h40073-type INT16_Current
attr PV_KSEM obj-h40074-reading M_AC_Current_C
attr PV_KSEM obj-h40074-type INT16_Current
attr PV_KSEM obj-h40075-reading M_AC_Current_SF
attr PV_KSEM obj-h40075-type INT16
attr PV_KSEM obj-h40076-reading M_AC_Voltage_LN
attr PV_KSEM obj-h40076-type INT16_Voltage
attr PV_KSEM obj-h40077-reading M_AC_Voltage_AN
attr PV_KSEM obj-h40077-type INT16_Voltage
attr PV_KSEM obj-h40078-reading M_AC_Voltage_BN
attr PV_KSEM obj-h40078-type INT16_Voltage
attr PV_KSEM obj-h40079-reading M_AC_Voltage_CN
attr PV_KSEM obj-h40079-type INT16_Voltage
attr PV_KSEM obj-h40080-reading M_AC_Voltage_LL
attr PV_KSEM obj-h40080-type INT16_Voltage
attr PV_KSEM obj-h40081-reading M_AC_Voltage_AB
attr PV_KSEM obj-h40081-type INT16_Voltage
attr PV_KSEM obj-h40082-reading M_AC_Voltage_BC
attr PV_KSEM obj-h40082-type INT16_Voltage
attr PV_KSEM obj-h40083-reading M_AC_Voltage_CA
attr PV_KSEM obj-h40083-type INT16_Voltage
attr PV_KSEM obj-h40084-reading M_AC_Voltage_SF
attr PV_KSEM obj-h40084-type INT16
attr PV_KSEM obj-h40085-reading M_AC_Freq
attr PV_KSEM obj-h40085-type INT16_Freq
attr PV_KSEM obj-h40086-reading M_AC_Freq_SF
attr PV_KSEM obj-h40086-type INT16
attr PV_KSEM obj-h40087-reading M_AC_Power
attr PV_KSEM obj-h40087-type INT16_Power
attr PV_KSEM obj-h40088-reading M_AC_Power_A
attr PV_KSEM obj-h40088-type INT16_Power
attr PV_KSEM obj-h40089-reading M_AC_Power_B
attr PV_KSEM obj-h40089-type INT16_Power
attr PV_KSEM obj-h40090-reading M_AC_Power_C
attr PV_KSEM obj-h40090-type INT16_Power
attr PV_KSEM obj-h40091-reading M_AC_Power_SF
attr PV_KSEM obj-h40091-type INT16
attr PV_KSEM obj-h40092-reading M_AC_VA
attr PV_KSEM obj-h40092-type INT16_VA
attr PV_KSEM obj-h40093-reading M_AC_VA_A
attr PV_KSEM obj-h40093-type INT16_VA
attr PV_KSEM obj-h40094-reading M_AC_VA_B
attr PV_KSEM obj-h40094-type INT16_VA
attr PV_KSEM obj-h40095-reading M_AC_VA_C
attr PV_KSEM obj-h40095-type INT16_VA
attr PV_KSEM obj-h40096-reading M_AC_VA_SF
attr PV_KSEM obj-h40096-type INT16
attr PV_KSEM obj-h40097-reading M_AC_VAR
attr PV_KSEM obj-h40097-type INT16_VAR
attr PV_KSEM obj-h40098-reading M_AC_VAR_A
attr PV_KSEM obj-h40098-type INT16_VAR
attr PV_KSEM obj-h40099-reading M_AC_VAR_B
attr PV_KSEM obj-h40099-type INT16_VAR
attr PV_KSEM obj-h40100-reading M_AC_VAR_C
attr PV_KSEM obj-h40100-type INT16_VAR
attr PV_KSEM obj-h40101-reading M_AC_VAR_SF
attr PV_KSEM obj-h40101-type INT16
attr PV_KSEM obj-h40102-reading M_AC_PF
attr PV_KSEM obj-h40102-type INT16_PF
attr PV_KSEM obj-h40103-reading M_AC_PF_A
attr PV_KSEM obj-h40103-type INT16_PF
attr PV_KSEM obj-h40104-reading M_AC_PF_B
attr PV_KSEM obj-h40104-type INT16_PF
attr PV_KSEM obj-h40105-reading M_AC_PF_C
attr PV_KSEM obj-h40105-type INT16_PF
attr PV_KSEM obj-h40106-reading M_AC_PF_SF
attr PV_KSEM obj-h40106-type INT16
attr PV_KSEM obj-h512-reading Active_energy+
attr PV_KSEM obj-h512-type UINT64
attr PV_KSEM obj-h516-reading Active_energy-
attr PV_KSEM obj-h516-type UINT64
attr PV_KSEM obj-h8192-reading ManufacturerID
attr PV_KSEM obj-h8192-type UINT16
attr PV_KSEM obj-h8193-reading ProductID
attr PV_KSEM obj-h8193-type UINT16
attr PV_KSEM obj-h8194-reading ProductVersion
attr PV_KSEM obj-h8194-type UINT16
attr PV_KSEM obj-h8195-reading FirmwareVersion
attr PV_KSEM obj-h8195-type UINT16
attr PV_KSEM obj-h8196-reading VendorName
attr PV_KSEM obj-h8196-type STR32
attr PV_KSEM obj-h8212-reading Productname
attr PV_KSEM obj-h8212-type STR32
attr PV_KSEM obj-h8228-reading SerialNumber
attr PV_KSEM obj-h8228-type STR32
attr PV_KSEM obj-h8244-reading MeasuringInterval
attr PV_KSEM obj-h8244-type UINT16
attr PV_KSEM room Strom->Photovoltaik
attr PV_KSEM sortby 02
attr PV_KSEM verbose 0
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

speedAmaster

Hallo Christian,
das ist ja interessant. Ich scheine überall Werte zu bekommen.
Habe zudem (nach der Kostal ModbusDoku) noch folgende Werte hinzugefügt:
attr PV_EM410 obj-h40108-reading M_Exported
attr PV_EM410 obj-h40108-type UINT32
attr PV_EM410 obj-h40110-reading M_Exported_A
attr PV_EM410 obj-h40110-type UINT32
attr PV_EM410 obj-h40112-reading M_Exported_B
attr PV_EM410 obj-h40112-type UINT32
attr PV_EM410 obj-h40114-reading M_Exported_C
attr PV_EM410 obj-h40114-type UINT32
attr PV_EM410 obj-h40116-reading M_Imported
attr PV_EM410 obj-h40116-type UINT32
attr PV_EM410 obj-h40118-reading M_Imported_A
attr PV_EM410 obj-h40118-type UINT32
attr PV_EM410 obj-h40120-reading M_Imported_B
attr PV_EM410 obj-h40120-type UINT32
attr PV_EM410 obj-h40122-reading M_Imported_C
attr PV_EM410 obj-h40122-type UINT32

attr PV_EM410 obj-h40125-reading M_Exported_VA
attr PV_EM410 obj-h40125-type UINT32
attr PV_EM410 obj-h40127-reading M_Exported_VA_A
attr PV_EM410 obj-h40127-type UINT32
attr PV_EM410 obj-h40129-reading M_Exported_VA_B
attr PV_EM410 obj-h40129-type UINT32
attr PV_EM410 obj-h40131-reading M_Exported_VA_C
attr PV_EM410 obj-h40131-type UINT32
attr PV_EM410 obj-h40133-reading M_Imported_VA
attr PV_EM410 obj-h40133-type UINT32
attr PV_EM410 obj-h40135-reading M_Imported_VA_A
attr PV_EM410 obj-h40135-type UINT32
attr PV_EM410 obj-h40137-reading M_Imported_VA_B
attr PV_EM410 obj-h40137-type UINT32
attr PV_EM410 obj-h40139-reading M_Imported_VA_C
attr PV_EM410 obj-h40139-type UINT32


Anbei meine Werte (jungfräulich und verregnet).

VG
Bernd

PS: wo finde ich denn deine neuesten "PV_Anlage_1" "PV_EM410" und "DB statistiken"?