ModbusAttr an Wechselrichter SolarEdge SE10k [gelöst]

Begonnen von BenMarloe, 09 Dezember 2017, 00:14:24

Vorheriges Thema - Nächstes Thema

StefanStrobel

Hallo Jörg / Benni,

der Fehler beim Starten von Fhem ist klar, das liegt wie schon geschrieben daran, dass beim Starten der attr-Befehl ausgewertet wird, der will die Expression testen und davor ist natürlich noch kein readingsBeginUpdate aufgerufen worden. Um das zu umgehen kann man $inCheckEval abfragen. Das ist nur gesetzt, wenn tatsächlich ein Reading gesetzt werden soll bzw. wenn ParseObj CheckEval aufruft. Nicht aber wenn die attr-Funktion die Expression testet.

Was die Funktion im Modul angeht, so rufst Du darin ja selbst readingsBeginUpdate und danach auch ReadingEndUpdate auf. Das führt dann zu dem Problemen dass der spätere Aufruf von readingsBulkUpdate in ParseObj selbst nach Deinem Aufruf von readingsEndUpdate kommt. Das crasht dann.

Lösung: readingsBeginUpdate und readingsEndUpdate müssen aus Deiner Funktion und aus den Expressions raus. Zusätzlich idealerweise $inCheckEval abfragen.

Ein Blick in die Funktion ModbusLD_ParseObj im Modul sollte es erklären :-)

Gruss
   Stefan


pejonp

Hallo Stefan / Benni,

habe das Modul angepasst. Bei mir läuft es jetzt. Ich hänge es mal an. Wer möchte kann ja mal testen.

Stefan vielen Dank für deine Hilfe.

Jörg
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

Chris_XXX

Hallo zusammen,

ich habe hier mal eine Frage: Wie bekomme ich die aktuelle Version vom 98_Modbus.pm? Ein Update sagt bei mir das nichts zu tun wäre. Der Versionscheck auf Modbus.pm sagt mir allerdings dass ich diese Version habe:
98_Modbus.pm 15871 2018-01-13
So wie eure Diskussion hier aber verstanden habe ist die aktuelle Version vom 18.10.2018  :-\
Gibts da einen Trick?

Vielen Dank und Grüße
Christian

StefanStrobel

Hallo,

die aktuelle Version steht im Post 152 dieses Threads:
https://forum.fhem.de/index.php/topic,75638.150.html

In der neuen Version hat sich sehr viel geändert, deshalb habe ich sie auch noch nicht eingecheckt und hoffe auf weitere Testberichte ;-)

Gruss
   Stefan

Chris_XXX


Chris_XXX

Hallo zusammen,

jetzt hätte ich nochmal eine Frage: Wie habt ihr die Sache mit der Skalierung in den Griff bekommen? Ich habe immer wieder Ausreißer noch oben und unten. Da schaut im Plot besonders hübsch aus. Ich habe die aktuelle Leistung bei mir so definiert:
obj-h40083-expr $val * (10 ** ReadingsNum ('SolarEdge' ,'I_AC_Power_SF',0))
obj-h40083-len 2
obj-h40083-reading I_AC_Power
obj-h40083-unpack s>

Ich dachte dass dieser len 2 der Schlüssel zum Erfolg ist, leider nicht :(

Grüße
Christian

kingmathers

#81
obj-h40083-reading I_AC_Power
obj-h40083-len 2
obj-h40083-unpack s>s>
obj-h40083-expr $val[0] * (10 ** $val[1])


Damit liest du beide Werte aus und berechnest den Wert direkt (nicht über Zugriff auf eine andere, evtl. davor/danach ausgelesene Variable). Mit $val[0,1,2,..] stehen alle gleichzeitig ausgelesenen Werte zur Verfügung.
Raspberry Pi B+, FS20, 1-Wire, HM
FHEM Home Control (App für Windows 10): https://forum.fhem.de/index.php/topic,49891.0.html
FHEM Arduino Library: https://forum.fhem.de/index.php/topic,94093.0.html

pejonp

Hallo Chris_XXX,


versuche mal die im Post (https://forum.fhem.de/index.php/topic,80767.msg850976.html#msg850976) angehangen Datei. Da wird alles berechnet. Einfach ins FHEM legen, Rechte anpassen, fhem neu starten.

def:  defmod SEdge SolarEdge ID 60 IP:PORT RTU oder TCP

pejonp

LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

Chris_XXX

#83
Herzlichen Dank an euch beide.
Ich habe das Modul von Jörg jetzt am laufen.
Folgendes ist mir dabei aufgefallen:
Bei den Spannungen zwischen Phase und N ist ein Kommafehler:

I_AC_VoltageAN 2279.00 V
I_AC_VoltageBN 2270.00 V
I_AC_VoltageCN 2271.00 V

Abgesehen von diesem kleinen Schönheitsfehler ist das Modul aber super. Ich bin voll begeistert.

Gibt es auch eigentlich auch eine Möglichkeit die erzeugte Tagesleistung vom WR auszulesen?

Grüße
Christian

pejonp

@Chris_XXX

Versuche mal ein Update. Ich habe das Modul auf github zu liegen. https://github.com/pejonp/FHEM---SolarEdge

update all https://raw.githubusercontent.com/pejonp/FHEM---SolarEdge/master/controls_SolarEdge.txt

Dort habe ich noch ein Paar Änderungen vorgenommen.
in den Readings: pv_energy pv_energytoday pv_energytoweek pv_energytomont ... wird die erzeugte Energie gespeichert. Ist aber noch nicht fertig, daher erst mal testen.

pejonp

LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

Chris_XXX

Hallo pejonp, ich habe das Modul getestet und bin begeistert.
Der einizge Fehler den ich bisher feststellen konnte ereignete sich bei der Installation:
2018.11.05 07:16:38 1 : New entries in the CHANGED file:
2018.11.05 07:16:38 1 : 4.11.2018
2018.11.05 07:16:38 1 : Readings: pv_energy pv_energytoday pv_energytoweek pv_energytomont ...
2018.11.05 07:16:38 1 : Calling /usr/bin/perl ./contrib/commandref_join.pl -noWarnings, this may take a while
2018.11.05 07:16:55 3 : SolarEdge: MapConvert called from ModbusLD_ParseObj did not find 3 in map 1:Aus, 2:Nachtmodus, 4:WR_An
2018.11.05 07:17:56 3 : SolarEdge: MapConvert called from ModbusLD_ParseObj did not find 3 in map 1:Aus, 2:Nachtmodus, 4:WR_An
2018.11.05 07:18:55 3 : SolarEdge: MapConvert called from ModbusLD_ParseObj did not find 3 in map 1:Aus, 2:Nachtmodus, 4:WR_An
2018.11.05 07:19:55 3 : SolarEdge: MapConvert called from ModbusLD_ParseObj did not find 3 in map 1:Aus, 2:Nachtmodus, 4:WR_An
2018.11.05 07:20:55 3 : SolarEdge: MapConvert called from ModbusLD_ParseObj did not find 3 in map 1:Aus, 2:Nachtmodus, 4:WR_An
2018.11.05 07:23:55 3 : SolarEdge: MapConvert called from ModbusLD_ParseObj did not find 3 in map 1:Aus, 2:Nachtmodus, 4:WR_An

Tut der Sache aber keinen Abbruch, funktioniert trotzdem.

Jetzt bin ich aber bei einem neuen Problem das meine Horizont übersteigt.
Ich möchte, sobald meine PV Anlage einen gewissen Wert an Leistung liefert, eine Aktion auslösen. Aktuell verschicke ich eine EMail, nachher soll eine Steckdose geschaltet werden. Damit die Steckdose im Falle von abfallender Leistung an der PV Anlage aber nicht sofort ausgeht, sondern eine Mindestlaufzeit hat, habe ich einen Sleep eingebaut.
Dazu habe ich ein Notify angelegt das so aussieht:



SolarEdge:I_AC_Power.* {if ($EVTPART1 < 300 ) {
fhem{exmail('Darthvader@Deathstar.galaxy', 'myHome: Strom weg', "Die aktuelle Leistung betraegt $EVTPART1 Watt")};
}else {
if ($EVTPART1 > 1500 ) {
fhem{exmail('Darthvader@Deathstar.galaxy', 'myHome: Strom da', "Die aktuelle Leistung betraegt $EVTPART1 Watt"), sleep 120};
  }
  }
}

Theoretisch und in Trockenübungen hat das auch funktioniert. Im praktischen Einsatz gefällt das dem FHEM aber gar nicht, er bleibt für ca. 2 minuten hängen bis er wieder im reagiert. Im Log sehe ich folgendes:

2018.11.07 09:31:55 3: HASH(0x3991c78) : Unknown command HASH(0x3991c78), try help.
2018.11.07 09:31:55 3: nt.PV.Energie.da return value: Unknown command HASH(0x3991c78), try help.
2018.11.07 09:31:55 3: 192.168.99.14:502 disconnected, waiting to reappear (SolarEdge)
2018.11.07 09:31:55 3: 192.168.99.14:502 reappeared (SolarEdge)
2018.11.07 09:31:57 3: SolarEdge: ResponseTimeout called, devhash=HASH(0x2e41d80), name of devhash=SolarEdge
2018.11.07 09:31:57 3: SolarEdge: Timeout waiting for a modbus response, request: id 1, fCode 3, tid 123, type h, adr 40100, len 8 for device SolarEdge reading Block_DC_Power, read buffer empty

Hat jemand eine Idee was hier falsch läuft?

Danke und Grüße
Christian

pejonp

Hallo Christian,

Ich würde das sleep 120 rausnehmen und das wiederholte abfragen anders einstellen. Müsste ich mir erst einmal leif ansehen.

Das mit der map Funktion und dem Fehler sehe ich mir mal. Dauert aber ein bisschen.

Jörg
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

Chris_XXX

Hallo Jörg,

kein Thema, ich wollte dir nur eine Rückmeldung geben nachdem du dir schon soviel Mühe gemacht hast.
Dann muss ich wohl mal ein bischen Hirnen wie ich das anders hinbekomme.... kommt Zeit kommt Rat ;)

Grüße
Christian

pejonp

#88
Hallo Christian,

Versuche beim notify  mal

disabledAfterTrigger someSeconds
disable the execution for someSeconds after it triggered

Jörg
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

StefanStrobel

Mit DOIF kann man solche bedingten Reaktionen mit diversen Verzögerungen auch schön realisieren.

Gruss
   Stefan