Modul für AE-Conversion Wechselrichter

Begonnen von Roger, 27 Dezember 2015, 15:03:03

Vorheriges Thema - Nächstes Thema

Roger

Hallo FHEM-Gemeinde,
ich habe zwei Micro Wechselrichter INV350 von AE-Conversion mit RS485 Schnittstelle.
Diese arbeiten mit dem AESGI-Protokoll. Dafür habe ich zwei FHEM-Module erstellt:
98_AESGI.pm           --> AESGI Protokoll-Modul
98_AEConversion.pm --> Modul für die Wechselrichter, setzt auf 98_AESGI.pm auf.

Aufruf:

define <name1> AESGI /dev/ttyUSB0@9600
define <name2> AEConversion 01 30
attr   <Name2> IODev <name1>


Anmerkung:
  • User, unter dem FHEM läuft, muss unter Linux in der Gruppe dialout sein --> sudo usermod -a -G dialout fhem
  • Die Adresse habe ich mit dem Windows-Tool von AEConversion auf 1 gestellt (über Seriennummer)
  • 30 --> Werte werden aller 30s ausgelesen
Anbei die beiden Module zur freien Verwendung.
Zum Anschluss kann ein beliebiger RS485 Adapter verwendet werden, z.B. http://www.amazon.de/gp/product/B00GWEGZOI.

neue Version zum Testen.
- 0x40 Füllzeichen-Behandlung eingebaut (Dank an mfischer-ffb) --> bisher keine CRC-Fehler mehr
- Attribute 'dummy' und 'showtime' gelöscht, da nicht verwendet
- neues Attribut 'intervalDelay' um 1. Abfrage nach DEF um x Sekunden zu verzögern, Standard WR-Adresse als Sekundenanzahl

mit bereitgestelltem Gruß
Roger
Zotac, BBB, RPIs mit 10*FHEM
2*HM-LAN, 2*JeeLink, 2*RS485, SignalESP
HomeMatic, PCA301 Komponenten, ModBus: Stromzähler, Fronius WR, Shelly

voller

Danke Roger,
dat is wat wo nach ich schon lange gesucht hab ums nich selber zum machen!! :D
Werde ich demnächst mal mit meinen 6 Wexelrichtern ausprobieren.

Und Tschüß
Voller

pv_ae500

Hallo Roger,
vielen dank für die Erweiterung wie die WR in die Fhem.cfg eingebaut werden.
Ist meine erster Fhem Anwendung;=)
Gruß
Hans

fjrbiker63

bin hier Anfänger... wo muss ich das alles wie einbinden?

leupin

Hallo Roger,
ich habe vor einigen Tagen Deine beiden Module für das Auslesen von Leistungsdaten aus einer Klein-Solaranlage mit FHEM installiert.
Nun meine Frage - gibt es zu den Modulen irgendwo eine detailliertere Beschreibung zu den Attributen, die gesetzt werden können.
Ich habe aktuell noch einige Probleme mit TimeOuts, die ich noch in den Griff bekommen möchte...
Vielen Dank und beste Grüsse
Andreas

leupin

Hallo Roger,
ich versuchs nochmals über diesen Weg, nachdem es über die persönliche Benachrichtigung nicht funktioniert hat:
Ich habe die beiden Module AESGI und AEConversion an sich zum Laufen gebracht, habe aber insbesondere wenn die Wechselrichter in den Ruhezustand gehen oder daraus aufwachen immer wieder Fehler, die zum Absturz der AESGI-Instanz (Device) führen. Dann hilft nur ein Löschen und Neudefinieren der AESGI-Instanz und der beiden AEConversion Instanzen, welche bei mir aktiv sind.
Ich habe nun zwar eine Lösung gefunden, die das Ganze automatisiert (d.h. überprüft, ob die AESGI-Instanz hängt) und dann AESGI und AEConversion automatisch neu konfiguriert (i.e. die zugehörigen devices löscht und neu definiert), aber das scheint mir schon ein bisschen ein "Murks" zu sein. Schöner wäre es, wenn man z.B. dem AESGI-Device das Attribut "dummy" zuweisen und so die Kommunikation während der kritischen Phase des Aufwachens der Inverter aus dem Ruhemodus inaktiv setzen könnte.
Wäre eine diesbezügliche Ergänzung im Modul möglich.
Alternativ wäre es auch möglich, dass der Internal Partial auch geleert würde, wenn beim Lesen ein Fehler auftritt - das würde wohl auch verhindern, dass sich das AESGI-Device bei Fehlern aufhängt...
Mit besten Grüssen
Andreas

Roger

Hi Andreas,
bin noch im Urlaub, aber leider nicht mehr lange  :(.
Wenn ich zurück bin und das Wetter nicht schön --> schaue ich es mir an.

Roger
Zotac, BBB, RPIs mit 10*FHEM
2*HM-LAN, 2*JeeLink, 2*RS485, SignalESP
HomeMatic, PCA301 Komponenten, ModBus: Stromzähler, Fronius WR, Shelly

mfischer-ffb

Hallo Roger,

schön dass du noch aktiv bist, bei mir hängt sich FHEM auch sporadisch mit crc-Fehlern auf bzw. manchmal werden auch nur keine Werte mehr in´s log geschrieben meist in der früh, dazu hab ich was im Photovoltaik Forum gefunden.
https://www.photovoltaikforum.com/viewtopic.php?f=3&t=105173&p=1224421&hilit=0x0D#p1224421

Bezüglich Ausblendzeichen 0x40  und Endzeichen 0x0D
evtl. hilft das bei der Fehlersuche.
meine Wechselrichter adresse ist 15 und nicht 01 wie bei dir, ich werds jetzt mal umstellen evt. hängt dass damit irgendwie zusammen...

Einen anderen Fehler konnte ich selbst beheben:
Beim Modul 98_AEConversion.pm  fehlt der Eintrag

use SetExtensions;

Ohne diesen stürzt FHEM in der Aktuellen Version ab wenn die Seite mit dem Wechselrichter aufgerufen wird.

Vielen Dank für deine tolle Arbeit  :)

Gruß
Markus

leupin

Lieber Roger,
vielen Dank für Deine Antwort und noch einen schönen Resturlaub...
Noch einige Hinweise zur Problematik:
- die auch von Markus beschriebenen CRC-Errors treten vornehmlich am Morgen resp. am Abend auf, wenn die Inverter in den Ruhezustand gehen oder daraus erwachen. Anschliessend ist die AESGI Instanz blockiert und kann nach meinen bisherigen Tests nur wieder zum Laufen gebracht werden durch ein delete und neues define - dann müssen aber auch die aeconversion-Instanzen gelöscht und neu gesetzt werden, damit die Kommunikation wieder funktioniert.
- Die AESGI-Instanz scheint allerdings nicht völlig tot zu sein, sondern im definierten Zeitintervall wächst der Internal "Anwort" und der Internal "PARTIAL" immer mehr - im Normalbetrieb ist der Internal Partial fast immer ein leerer String, in der Antwort steht der letzte von einem der Inverter gelesene Datenstring, so wie ich das sehe...
- Vielleicht liesse sich das Problem einfach lösen, indem beim Auftreten eines CRC-Fehlers einfach der Inhalt des PARTIAL und der Antwort verworfen und gelöscht würde.
- Das Modul aeconversion besitzt ja das Attribut "dummy" - ich hätte gedacht, dass sich damit die Abfrage der Inverter unterbinden lässt, dies scheint aber nicht zu funktionieren, auch wenn ich dummy = 1 setze... Wenn es funktionieren würde, wäre auch das wohl eine einfache Möglichkeit, um das Abfragen der Inverter während dem "Einschlafen" und dem "Aufwachen" zu verhindern...
Vielen Dank auch von mir für Deine Arbeit!
Gruss
Andreas

Roger

Hallo FHEMler,
im 1. Post ist eine neue Version zum Testen.
- 0x40 Füllzeichen-Behandlung eingebaut (Dank an mfischer-ffb) --> bisher keine CRC-Fehler mehr  :)
- Attribute 'dummy' und 'showtime' gelöscht, da nicht verwendet
- neues Attribut 'intervalDelay' um 1. Abfrage nach DEF um x Sekunden zu verzögern, Standard WR-Adresse als Sekundenanzahl (für leupin :) )

mit bereitgestelltem Gruß
Roger
Zotac, BBB, RPIs mit 10*FHEM
2*HM-LAN, 2*JeeLink, 2*RS485, SignalESP
HomeMatic, PCA301 Komponenten, ModBus: Stromzähler, Fronius WR, Shelly

mfischer-ffb

Hallo Roger,

Vielen Dank, schaut soweit gut aus ich werde es die Woche mal testen..

Gruß
Markus

leupin

Danke Roger,
werde es einbauen und testen, sobald ich von einer Konferenz wieder zu Hause bin...
Nochmals vielen Dank und beste Grüsse
Andreas

leupin

Hallo Roger,
vielen Dank für Deine neue Version - ich habe sie installiert und bisher (abgesehen von einem Fall direkt nach der Neuinstallation) keine CRC-Errors mehr erhalten.
Allerdings habe ich jetzt das Problem, dass ich vermehrt beim Auslesen der Inverter bei einem oder beiden Invertern ein timeout gemeldet bekomme.
Ich lösche aktuell (noch - historisch bedingt durch die Vorgängerversion) die beiden Instanzen des AEConversion-Moduls (AEconv_RO_1 und AEconv_RO_2) jeweils am Abend bei Sonnenuntergang und definiere sie jeweils am Morgen wieder bei Sonnenaufgang. Das Attribut intervalDelay habe ich bisher nicht verwendet.
Das ganze geschieht über ein "at" welches zyklisch den dummy "is_sleeping" abfragt - bei Sonnenaufgang hat dieser den Wert -1, am Abend bei Sonnenuntergang den Wert 2.
Die Definition des "at" habe ich im Folgenden angehängt. 

+*00:10:00
{my $val=InternalVal("aeconv_prot","PARTIAL","");
my $partlen=length($val);
fhem("set AESGI_partiallength $partlen");
my $num=Value("is_sleeping");
if ($num==-1) {
  if ($partlen>0) {
    fhem("delete aeconv_prot");
    fhem("define aeconv_prot AESGI /dev/ttyUSB0@9600");
    fhem("attr aeconv_prot TimeOut 4");
    fhem("attr aeconv_prot room E-Management");
    };
  fhem("set is_sleeping 0");
  fhem("define AERO1 at +00:00:10 define AEconv_RO_1 AEConversion 07 600");
  fhem("define AERO2 at +00:00:25 define AEconv_RO_2 AEConversion 12 600");
  fhem("define AERO3 at +00:00:44 attr AEconv_RO_1 room E-Management");
  fhem("define AERO4 at +00:00:45 attr AEconv_RO_2 room E-Management");
  };
if ($num==2) {
  fhem("set is_sleeping 1");
  fhem("delete AEconv_RO_1");
  fhem("delete AEconv_RO_2");
  };
}

Hast Du allenfalls eine Idee, worauf die häufigen timeouts bei diesem Vorgehen zurückzuführen sein könnten?
Vielen Dank nochmals für die neuen Module und beste Grüsse
Andreas

hein21

Hallo Roger,
Danke für das tolle Modul, das wochenlang bei mir auch sang- und klanglos seine Dienste verrichtet hat.
Neulich musste ich leider meinen Raspberry Pi mit FHEM neu aufsetzen, ich hatte zum Glück ein halbwegs aktuelles Backup der SD-Karte und auch die fhem.cfg war aktuell. Nur die AESGI- und AECONVERSION-Module musste ich neu installieren.
Leider klappt es aber nun nicht mehr.
FHEM verabschiedet sich, wenn das AECONVERSION-Modul geladen wird. Ich bekomme es dann erst wieder zum laufen, wenn ich es in der fhem.cfg auskommentiere oder das Modul aus dem FHEM-Modulordner lösche...

in der cfg habe ich folgenden Eintrag:

#Solaranlage Westbalkon
define Aesgiprotokoll AESGI /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@9600
define Westbalkon AEConversion 01 30
attr Westbalkon IODev Aesgiprotokoll
attr Westbalkon room Energie
attr Westbalkon verbose 1

Wie gesagt, damit ging es schon mal... Wechselrichteradresse war 26, habe ich per Software auf 01 umgestellt.


Im Log taucht (nach Absturz) folgendes auf:
2018.09.14 18:05:13 3: Opening Aesgiprotokoll device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2018.09.14 18:05:13 3: Setting Aesgiprotokoll serial parameters to 9600,8,N,1
2018.09.14 18:05:13 3: Aesgiprotokoll device opened
2018.09.14 18:05:14 3: 98_AEConversion.pm: AEConversion_Define Registrierung WR-Adresse: 01, in: Aesgiprotokoll
Undefined subroutine &main::AttrNum called at ./FHEM/98_AEConversion.pm line 139, <$fh> line 696.

Kannst Du mir bitte weiterhelfen ?

Viele Grüße,
Stefan

Roger

Hi Stefan,
AttrNum(<devicename>,<attribute>, <defaultvalue>,<round>) ist eine Standardfunktion in FHEM. Mach mal ein update.
Dann sollte es wieder gehen.

//Roger
Zotac, BBB, RPIs mit 10*FHEM
2*HM-LAN, 2*JeeLink, 2*RS485, SignalESP
HomeMatic, PCA301 Komponenten, ModBus: Stromzähler, Fronius WR, Shelly

hein21

Hi Roger,
you made my day!  :)
Jetzt geht's. Wenn doch alle Probleme so leicht zu beheben wären....

Dankeschön und viele Grüße,
Stefan

dougie

#16
...ich befürchte ich hab da doch noch ein Problem.

Ich bekomme unglaublich viele CRC Fehler und versuche das Problem einzukreisen.
Ich verwende aktuell einen einzelnen Wechselrichter und das PLC Gateway zusammen mit einem höherwertigen RS485 Konverter mit FTDI Chipsatz an einem RPI.

fhem habe ich extra neu auf dem RPi aufgesetzt und will nur das die Werte in ein Logfil auf dem Server geschrieben werden.

Der Abstand vom WR zum PLC Gateway sind nur 2m und auch vom Gateway zum RPI sind nur 2m.

Wo könnten da die vielen CRC Fehler her kommen?

VG
Ralf


Edit: hab's gefunden!
Der AEC PLC Adapter ist ein RS485 Slave.
Ich verwende den Delock RS485 / USB Konverter von Reichelt. Der ist aber auch kein RS485 Master Device! Das heisst man muss die Kiste aufschrauben und zwei 390 Ohm Widerstände einlöten. Und zwar einen von D+ nach 3,3V und einen von D- nach Masse. So ist es nach RS485 Standard.

Hoffe es hilft dem ein oder anderen bei der Fehlersuche!

voller

#17
Moin,
ich bin jetzt erst zum testen gekommen und beiß mir die Zähne daran aus.  :(

Das funzt noch in der Befehlszeile:
define Aesgiprotokoll AESGI /dev/serial/by-id/usb-CTI_GmbH_Serial_Converter_CTXOSFJA-if00-port0@9600
wird angelegt und erscheint in der Oberfläche.

Der Befehl geht in die Hose:
define Wechselrichter2 AEConversion 02 30
Der führt zu einem Neustart von FHEM

Der Fehler im Log lautet:
98_AEConversion.pm: AEConversion_Define Registrierung WR-Adresse: 02, in: Aesgiprotokoll
PERL WARNING: Use of uninitialized value $cmd in concatenation (.) or string at ./FHEM/98_AEConversion.pm line 239.

Das System ist ein 64bit Debian 10 auf einem 4 Kerne Celeron mit 16GB Speicher mit Software SSD-Raid1 neu aufgesetzt.

Leider reichen meine Perl-Kenntnisse (noch) nicht aus um den Fehler zu beseitigen. Hat jemand eine Idee?

Update:
OK, das ganze FHEM mit Visual Code zu debuggen war keine gute Idee (bin wahrscheinlich zu blöd dazu), aber immerhin die Zeile die FHEM zum Krachen gebracht haben sind erstmal in 98_AEConversion.pm auskommentiert. Hat natürlich derzeit zur Folge, dass es keine Get und Set Kommandos für die Geräte gibt. Die Basisauswertung Leistung, Spannung und Strom funzt aber. Das mit SetExtentions ist, wenn ich den Koenig richtig interpretiere, nicht so eine gute Idee.

201      return; # SetExtensions($WRhash, join(" ", sort keys %AESGI_gets), @a); # Probleme
241      return; # SetExtensions($WRhash, join(" ",sort keys %AESGI_sets),@a); # Problem!!!!

Wenn die Wechselrichter morgens wieder angesprungen sind gab es den nächsten Crash mit der Meldung im LOG
"Undefined subroutine &main::Modbus_HandleSendQueue called at fhem_debug.pl line 3306."

Lösung in 98_AESGI.pm diese Zeilen auskommentieren:

406 #      Log3($name,5,"98_AESGI.pm: AESGI_SendQueue neue Queue Anzahl von: ".$name.", Laenge: ".(@{$queue}));
407 #      if(@{$queue} > 0) {         # more items in queue -> schedule next handle
408 #         Log3($name,5,"98_AESGI.pm: AESGI_SendQueue Queue von: ".$name." noch nicht leer, Laenge: ".(@{$queue})." --> naechstes Senden vorbereiten");
409 #         InternalTimer($now+$queueDelay, "Modbus_HandleSendQueue", "queue:$name", 0);
410 #      }

Insgesamt kommen alle Daten meiner 5 Wechselrichter zwar rumpelig aber ohne FHEM abzuschießen an. ;-)

Mal gucken ob ich es schaffe das alles in funktionsfähig hin zu bekommen.

Update:
Ist zwar nicht die feine Art der Lösung aber was solls ;-)
In 98_AEConversion.pm die Zeilen auf diese Werte ändern und schon klappt alles inklusive der get und set Befehle.

201   return "Unknown argument $cmd , choose one of Betriebsparameter Wechselrichtertyp Leistungsreduzierung Abschaltparameter Fehlerspeicher Stromvorgabe Betriebsmodus";
241   return "Unknown argument $cmd , choose one of Leistungsreduzierung_alle Leistungsreduzierung Autotest Stromvorgabe BM_normal BM_Spannungsvorgabe";

Damit sind für mich alle Ansprüche, die ich an die beiden Module habe "Leistungswerte erfassen" und "Leistungsbegrenzung setzen" hinreichend erfüllt.

Danke Roger für die für die Module.

Gruß
Voller




Matthias76

Hallo zusammen

Zunächst einmal danke für das schreiben dieser zwei Module.
Ich wollte das auch nutzen, um die Daten von INV350 und INV500 sowie eines AEDL-UH in FHEM nutzbar zu machen.
Diese drei Gerätetypen unterhalten sich schon jetzt via RS485-Bus untereinander erfolgreich.
Es sind jedoch PLC-Ausführungen, die aufgrund von unterschiedlichen Phasen via PLC-Gateways (Powerline Gateway von AEc) ihre Kommunikations in den Bus finden. Tiefer brauchen wir darauf nicht eingehen.

Hin und wieder gibt es schon auf dem Bus sichtbar am Logger AEDL-UH CRC-Fehler, obwohl der Bus beidseits mit 220Ohm-Widerstände abgeschlossen ist und im AEDL-UH auch eine Pull/Push/Up/Down-Verschaltung nach TIA vorhanden ist (390Ohm/+/-).
Lassen wir das als unbekanntes Problem A da stehen, welches aber nur geringe Relevant hat, da nur selten, wenig, kurz störend...

Nun zu FHEM und den zwei Modulen.
Ich habe die .PM-Dateien für AESGI und WR von AEconversion reinkopiert und definiert.
Soweit so gut.
Dann habe ich WRs angelegt und mit der Geräte-ID = Seriennummer angelegt, also 0302010650 und nicht einfach nur 01 oder 13 oder 28, wie hier so oft gezeigt.
So steht es ja auf dem Gerät (eindeutige Nummer) und so sind sie auch im AEDL-UH angelegt und kommen an!

Beim AESGI steht beim ttyUSB0 "opened".
Beim WR steht kurz opened, dann "timeout".
Im Log beim AESGI war viel Bewegung, aber auch viele CRC-Fehler-Einträge.

Vorhin habe ich dann mal doch mit Gerätenummer 1 einen angelegt.
Dann stürzte FHEM in einer Endlosschleife ab.
Diese konnte ich erst beenden, als ich die beidem Module aus /opt/fhem/FHEM rausgeholt hatte!

Jetzt traue ich mich gar nicht mehr, sie nochmal rein zu bringen.
Als Adapter nehme ich diesen:
https://www.amazon.de/USB-RS485-Adapter-mit-Geh%C3%A4use/dp/B00I9H5J02/ref=sr_1_5?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=rs485&qid=1582473404&sr=8-5

Mal mit cat o.ä. den COM-Port sichtbar gemacht, kommt was an, irgendwas im Takt.


Matthias76

Für alle die es (wie ich vorher) nicht wissen:
Die Geräte-ID ist die Zahl, die man ließt, wenn man nur die letzten 5 Ziffern der Seriennummer notiert.
INV500 - Seriennummer: 0403010650  --> Dann ist die Geräte-ID: 10650
(!)

So, und ohne AEDL-UH, nur mit 485-Geräten oder PLC-485-Gateways funktioniert es auch - mit der AEsolar-Software und mit den Modulen hier.
Nur dass ich den AEDL-UH als CO3- und L1-Erfasser benötige.
Hängt der mit im 485-Bus, geht auf der anderen Seite nichts mehr.

Dabei gilt ein 485-Bus auf Zweidrahttechnik (AB) als Multimaster-fähig.
Abgesehen davon braucht der PC (FHEM, AEsolar) eigentlich auch kein Master sein, nur mit-schnüffeln.
Sch... AEc....!

Ich habe das Projekt nun erstmal aufgegeben und hoffe an brauchbare Daten am EM24 zu kommen.
Das sieht auf dem ersten Blick schon mal vielversprechender aus...

voller

Moin Matthias,
Die Wechselrichter können 2 Übertragungsprotokolle das "native" aenconversion-Protokoll (dann ist die Geräte ID 5-stellig) und zusätzlich das AEGSI (da ist die Geräte- ID 2-stellig für max 32 Wechselrichter)
In dem "Dachplan" der AEsolar-Software kann man sehen, wie die Zuordnung zwischen den beiden ID's ist.
Die FHEM Module können nur das AEGSI und das AEDL-UH arbeitet mit dem nativen Protokoll, also beim blossen mitsniffen des FHEM wird das in die Grütze gehen.
Die beiden Protokolle unterscheiden sich in der Startsquenz, AEGSI #<WR-Adresse(2stellig ASCII, 32 Adressen)> und Werte sind in Klartext ASCII, das "native" !<WR-Adresse (HEX zwei Byte, 64000 mögliche Adressen)> und die Werte sind im Binärformat.
Wie gesagt zwei Protokolle über den gleichen Bus stelle ich mir ein wenig haarig vor. Zumal wenn FHEM und das AEDL-UH "gleichzeitig" aktiv sind. Ich habs über das normale PLC/RS485-Gateway laufen und damit funzen die FHEM-Module mit meinen Modifikationen.

Ich hoffe ich konnte das etwas erhellen, hat mich auch n paar Wochen gekostet bis ich dahinter gekommen bin. ;-)

Und Tschüß
Voller