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