Hallo Ihr, der Betreff erläutert mein Vorhaben:
Studer Xtender XTM mit Xcom-232i Kommunikationsmodul / Solarwechselrichter-Lader über RS232 in fhem abfragen und steuern
Einer von euch ein solches Setup am Laufen?
Primär gehts mir erstmal "nur" um die Verbindung Xtender/fhem und mit welchem fhem-Modul ihr Daten empfangt und sendet. Welchen RS232 -> USB Adapter ihr nutzt.
Das "nur" killt mich gerade ;)
liebe Grüße und Danke für jede Idee
H.
Hallo. Sowas suche ich auch,wobei ich z.Zt. etwas einfacher fahre. Steuern tu ich nur die Ladung/Entladung,mit Homematic Actoren auf den frei programmierbaren Eingängen
Sent from my OPO
Jo, genauso mach ichs auch noch. Homematic Sensor an Aux 1 und Aux 2. Aux 1 gibt mir Transfer aktiv/inaktiv und Aux 2 SOC über/unter 90%. Damit lässt sich schon einiges an Verbrauchern und (Über)-Kapazitäten steuern.
fhem schaltet Homematic wired Komponenten die mir z. B. Klima und Warmwasserboiler je nach Sonne/Batterie aktivieren. Schöne Sache. Ich hätts halt eben nur gerne noch ein bißchen filigraner was die Infos vom Xtender angehen.
Überhaupt ist fhem in Kombi mit einer Solarinsel der Knaller. Hier gibts irgendwo einen Thread wo Verschiedene dem Nutzen eines solchen Setups widersprechen. Kann ich nicht nachvollziehen.
Falls du oder andere noch mehr Nutzungsideen haben, oder tatsächlich jemand fhem mit dem Xcom zusammenspielen lässt -> Traumwelt
Hallo,
nachdem ich auch über eine ähnliche einfach Lösung nachdenke (ggf. mit einer Xcom Erweiterung nach einer ersten Testphase), habt Ihr für eure Lösung einen Schaltplan und Konfiguration des Studer XTM, damit ich meine Idee damit prüfen kann?
Gruß Oswald
Hallo Oswald, Konfi vom Studer:
siehe nächsten Beitrag
XTENDER
# Ref Bezeichnung User Wert QSP Wert Factory Wert
# 01107 Maximaler Eingangsstrom AC (Input limit) 16 16 32
# 01107 Maximaler Eingangsstrom AC (Input limit) 16 16 32
# 01108 Batterie- unterspannung ohne Last 23.5 23.5 23.2
# 01138 Batterieladestrom 0 0 60
# 01138 Batterieladestrom 0 0 60
# 01140 Schwebeladungs- spannung 27.4 27.4 27.2
# 01143 Spannung 1 um neuen Zyklus zu starten 24.4 24.4 25.0
# 01145 Spannung 2 um neuen Zyklus zu starten 23.6 24.6 24.6
# 01148 Minimale Dauer zwischen den Ladezyklen 24 24 3
# 01156 Ladeschlussspannung 29.4 29.4 28.8
# 01194 Anpassung der Batterie Unterspannung erlaubt (B.L.O) Yes Yes No
# 01200 Eingangsspannung die umgehend das Transferrelais öffnet (USV) 150 150 90
# 01202 Betriebsmodus des Hilfskontaktes (AUX 1) Reversed automatic Automatic Automatic
# 01246 Batteriespannung 1 (AUX 1) Yes No Yes
# 01247 Batterie- spannungswert 1 (AUX 1) 24.4 24.4 23.4
# 01248 Dauer vor Aktivierung 1 (AUX 1) 0 1 1
# 01249 Batteriespannung 2 (AUX 1) No No Yes
# 01252 Batteriespannung 3 (AUX 1) No No Yes
# 01255 Batteriespannung zum Deaktivieren (AUX 1) 26.1 24.7 27.0
# 01256 Dauer vor dem Deaktivieren (AUX 1) 10 30 60
# 01259 Leistungslevel 1 Wert in % (AUX 1) 50 50 120
# 01260 Dauer vor Aktivierung 1 (AUX 1) 0 0 1
# 01267 Leistungslevel zum Deaktivieren (AUX 1) 30 30 40
# 01286 Ausgangspannung AC 220 230 230
# 01288 Dynamische Kompensation der Batteriespannung benutzen (AUX 1) No No Yes
# 01297 Batteriespannung als Priorität 26 24.4 25.8
# 01311 Betriebsmodus des Hilfskontaktes (AUX 2) Automatic Automatic Reversed automatic
# 01333 Xtender OFF (AUX 2) No No Yes
# 01334 Alarm Unterspannung Batterie (AUX 2) No No Yes
# 01335 Ueberspannung Batterie (AUX 2) No No Yes
# 01336 Ueberlast Wechselrichter- oder Boostbetrieb (AUX 2) No No Yes
# 01337 Uebertemperatur (AUX 2) No No Yes
# 01432 Maximale Limite für die Eingangsspannung 265 265 270
# 01433 Spannungsdifferenz zum Senken des Eingangsstroms 30 10 10
# 01516 Deaktivierung wenn die Batterie in Schwebe- ladungsphase (AUX 1) No No Yes
# 01538 Verbietet den Transfer Yes No No
# 01545 Fernsteuereingang aktiv Closed Open Open
# 01548 Erhöhen der Ausgangsspannung entsprechend der Batteriespannung Yes Yes No
# 01575 Aktive Filtrierung des Eingangsstromes Yes No No
# 01578 Aktiviert durch den Zustand von AUX1 Yes No No
# 01589 Desaktivierung wenn die Batterie in Schwebe- ladungsphase (AUX 1) No No Yes
# 01598 Deaktiviert wenn die Batterie in der Schwebeladung (AUX 2) No No Yes
Das sind die veränderten Werte zum Standard (BattPrio ist bei mir eingeschaltet). Leider bekomme ich aus Excel keine saubere Tabelle hier fürs Forum exportiert. Da mußt du ein bißchen mit spielen und auf deine Gegebenheiten anpassen. Das Handbuch ist recht gut verständlich.
AUX 1 und AUX 2 hängst du dann noch auf einen Sensor zB http://www.elv.de/homematic-wired-rs485-schliesserkontakt-12-eingaenge-hutschienenmontage.html (http://www.elv.de/homematic-wired-rs485-schliesserkontakt-12-eingaenge-hutschienenmontage.html) und mit diesen Informationen (offen/geschlossen) kannst du dann dir deine eigene Logik in fhem basteln.
Aah, jetzt fällt mir gerade auf, dass das noch ein altes Backup ist wo AUX2 noch gar nicht auf den SOC programmiert ist. Muß ich die Tage mal schauen, ob ich Zeit habe an den Xtender zu kommen. Aber das Prinzip bleibt gleich.
Anbei als pdf aktuelle Einstellungen. Das sind nur die vom Factory Default abweichenden Werte.
Trotzdem empfinde ich das wegen der Existenz des Xcoms eigentlich einmal durch die Lasche und hintenrum. Falls es irgendwann mal jemand schafft den Xcom mit fhem zu verbinden wäre das sicherlich die galantere Methode..... und man könnte alle Werte auslesen und noch viel filigraner steuern.
Hallo,
danke für die Antwort,
ich wollte mir einen XTM 1500/12 zulegen, bei dem weiteren Studium der Studer Dokumente gibt es Einschränkungen für die 12V Geräte!?
damit ist die Frage auftaucht:
kann man die XTM 1500/12 auch zur 1-phasigen Netzeinspeisung/Eigenbedarfsdeckung verwenden??
Welche Geräte verwendet Ihr?
Gruß Oswald
Hallo Oswald, ich benutze einen XTM 3500-24. Inwieweit der von dir genannte 1500/12 Einschränkungen unterliegt weiss ich nicht. Der 3500er kann das von dir angesprochene.
Hallo. Ich habe den 2600/48. Auch meiner könnte einspeisen, muss aber von Studer freigeschalten werden. Als Privater kommst an den Experten-Code nicht ran.
Aber ich will auch gar nicht, ich lade tagsüber bei Überschuss meine Batterie, und abends beziehe ich den Strom aus der Batterie.
Alles von FHEM gesteuert/überwacht.
gruss
Hallo satprofi, spannend wäre jetzt noch wie du die Anbindung Studer -> fhem umgesetzt hast? Auch über AUX oder wie liest du die Zustände vom Studer in fhem? ...
lg
H.
über die 2 AUX Kontakte. Zusätzlich 2 SDM220M im Ein- u. Ausgangskreis.
Wenn die Akkus voll sind, schliesst der AUX2, laden erlaubt macht AUX1.
Zu mehr ist es leider auch noch nicht gekommen, wobei ich eigentlich damit zufrieden sein kann. Aber Ladestromsteuerung wäre echt interessant, wo man je nach überschuss die Ladekurve steuern könnte.
Jup, exakt so mach ich es auch. Mit den Daten der 2x SDM220M male ich mir noch schöne Plots und freu mich wieviel wann und wie über die Sonne reingekommen ist.
OT: wie hast du dein Transferrelais programmiert? reversed automatic? Irgendwie bin ich dabei das Setting zu überdenken. Irgendwann mal aus dem Photovoltaik-Forum übernommen und nie drüber nachgedacht. Insbesondere interessieren mich die Positionen 1202, 1538 und 1545. Wieso reversed??
Hallo,
hier habe ich etwas zum Studer Xcom gefunden (http://www.photovoltaikforum.com/datenlogger-f5/raspberry-pi-rs485-sma-wechselrichter-t104414.html#p1249303).
Dort ist auch eine Projektarbeit abgelegt worden. Letzte Seite. Ich hänge einmal die PDF + Pythonscript an. Bitte vorher in das Script schauen. Benutzung auf eigene Gefahr.
Es gibt auch noch ein DOS-Tool scom.exe zum auslesen der Com-Schnittstelle und eine C-Schnittstelle. Ist im Zip.
Ich benutze einen SolarEdge SE5000.
pejonp
Hallo.
habe letzes WE einen Xcom-Lan in Betrieb genommen, zusätzlich billigst Mox Nport5150 abgestaubt. Es funktioniert sowohl das "originale" von Studer als auch der billige aus China. Settings übertragen, umgesteckt, und server wurde sofort wieder verbunden.
Jetzt werde ich mich dahingehend schlau machen, wie man das ganze über fhem steuern kann.
Falls wer schon mehr Infos hat, bitte her damit.
LG
Hallo satprofi, ich bin aus Zeitmangel noch nicht weitergekommen. Köln-Solar (Markus) hatte mir mal sein Modul für einen Fronius zum Umarbeiten geschickt, aber ich war damals (und heute erstmal sicherlich auch noch) ein wenig überfordert. Aber irgendwann wage ich mich da nochmal dran. Wenn du zwischenzeitlich Lust und Zeit hast.... hau rein. Schick doch Köln-Solar eine PM ob er dir das Modul zukommen lässt? Kann das nicht einfach weitergeben.
H.
Aha, danke. Köln-Solar finde ich hier?
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Ja, such mal Mitglieder KölnSolar. Kann gerade mobil nicht annehmbar scrollen
Danke, habe Homepage von Köln-Solar angefragt
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
ZitatKann das nicht einfach weitergeben.
Brav ;)
ZitatSchick doch Köln-Solar eine PM ob er dir das Modul zukommen lässt?
ist über den Umweg
ZitatDanke, habe Homepage von Köln-Solar angefragt
angekommen. Dass man uns so noch findet ;D
Mail mit "Prototyp"-Modul kommt per Mail.
Na da sind wir ja wieder alle beisammen :)
Anbei nochmal was ich bisher zusammengetragen hatte (zT wahllos). Obs hilft ... ?
Wenn du weiterkommst, lass wissen!
Gruß
Hallo @all. Danke an Markus für das Modul. Ist zwar für USB, aber ich sehe mir trotzdem an.
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Falls wer ein xcom232 per LAN verbinden will, ein billiger moxa klappt auch, nicht nur der von Studer. Habe erfolgreich die settings in einen 20.- moxa eingestellt und bin mit Studer Portal verbunden
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Welcher Moxa genau? Könntest du die Settings hier verewigen?
Moxa 51xx
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Settings per Pn
hat schon wer das neue webif vom studerportal gesehen? nummer eingeben und status empfangen
Gesendet von meinem ONEPLUS A5000 mit Tapatalk
... könnte man da nicht mit dem Modul HTTPMOD einen Ansatz finden? ... so ganz ins Blaue?
... wahrscheinlich könnte man auch den Moxa direkt im Heimnetz abfragen. Irgendwie muß der ja mit dem Studer Portal kommunizieren.
mittlerweile habe ich schon die can daten gefunden, also die nummern zum abfragen.
wäre jetzt interessant wie man das mit httpmod ans studerportal senden könnte und empfangen.
So , ein Schritt weiter.
Habe aus dem Nachbarforum ein python file bekommen, wo man die BattSpg. abfragen kann.
Mit diesem File habe ich am raspi die abfrage gestartet, was nicht sofort klappte.
man muss den Xcom vorher auf 232 Modus umstellen, mit Xcomkonfigurator. Danach klappte das file sofort.
Draufgekommen bin ich dadurch, das scom.exe am Laptop keine Verbindung zusammenbrachte, und ich den Konfigurator noch in erinnerung hatte ;-)
Jetzt muss ich nur noch das File anpassen, mehrere Werte abzufragen, und vielleicht noch den Xtender zu steuern.
Fakt ist aber, wenn man das WebIF auch verwenden will, man 2 Xcom 232i benötigt. Werde ich mir auch zulegen.
So, liebe Forumsgemeinde.
ich habe es jetzt geschafft, den Xtender u. seine Zusatzgeräte abzufragen.
Für mich vorerst wichtige Werte wie Batt_Spg., SOC der Akkus, frage ich erfolgreich über Xcom232 per Raspi u. pythonscript ab.
Diese schreibe ich dann in FHEM angelegte Dummys.
Das script ist leicht anzupassen, benötigte Werte sind hier (http://www.studer-innotec.com/media/document/0/technical-specification-xtender-serial-protocol-v1.6.26.zip) zu finden. Zusätzlich das DOS commandotool scom, mit der man die werte abfragen kann und den string ins script kopieren kann.
Vielleicht findet sich jemand der das ganze verbessern kann, oder Vorschläge dazu hat.
Nachtrag: Wenn man den Xcom bisher auf LAN laufen lies, muss man mit dem Xcomkonfigurator dies auf serial umstellen.
LG
So, Forumsmitglieder.
Update des scriptes.
Auswertung von negativen Werten (Batteriestrom) angepasst.
Akt. Ladeleistung , und Entladewert vom Vortag.
Vielleicht kanns wer brauchen.
Datei einfach umbenennen in Xtender.py
Das Modul NT5000.pm (im contrib-Ordner) kommuniziert seriell mit einem NT5000-Wechselrichter von Sunways.
LG
pah
So.
Werk fast vollendet.
Habe jetzt die wichtigsten Werte u. Commandos per Scom ausgelesen, und in div. pythonscripte eingetragen.
in FHEM habe ich Dummys angelegt die von Python gefüttert werden, bzw. Pythonscripte starten.
Mit DOIF rufe ich die jeweiligen scripte in python auf die mir den richtigen Ladestrom bei div. Überschuss einstellen.
Alle Minuten errechne ich den Überschuss, der dann DOIF triggert.
Ich bin auch am überlegen diese Ladesteuerung in ein eigenes Script zu packen, das alle minuten per cron gestartet wird.
das hat aber den nachteil das alle minuten selber befehl an den xtender geschickt wird, was bei doif nur dann erfolgt wenn sich der wert zur nächsten stufe ändert.
aber vielleicht fällt mir noch etwas besseres ein. habe die letzte woche einen crashkurs in python , mir raucht die birne.
define Batt_Ladung notify Batt_Ladung:on { {system('sudo python2 /usr/local/bin/ladung_on.py&');;} }
define ladestrom DOIF ([Ueberschuss] >1300 and [Lader] eq "on") ({system('sudo python2 /usr/local/bin/25Amp.py&')}
Weitere Optimierung, den Ladestrom noch feiner gesteuert.
DOELSEIF ([Ueberschuss] >1400 and [Lader] eq "on" and [Wert_I:A] !=25) ("python2 /usr/local/bin/25Amp.py")
DOELSEIF ([Ueberschuss] >1200 and [Lader] eq "on" and [Wert_I:A] !=22) ("python2 /usr/local/bin/22Amp.py")
DOELSEIF ([Ueberschuss] >1100 and [Lader] eq "on" and [Wert_I:A] !=20) ("python2 /usr/local/bin/20Amp.py")
DOELSEIF ([Ueberschuss] >1000 and [Lader] eq "on" and [Wert_I:A] !=18) ("python2 /usr/local/bin/18Amp.py")
DOELSEIF ([Ueberschuss] >900 and [Lader] eq "on" and [Wert_I:A] !=16) ("python2 /usr/local/bin/16Amp.py")
DOELSEIF ([Ueberschuss] >800 and [Lader] eq "on" and [Wert_I:A] !=14) ("python2 /usr/local/bin/14Amp.py")
DOELSEIF ([Ueberschuss] >700 and [Lader] eq "on" and [Wert_I:A] !=12) ("python2 /usr/local/bin/12Amp.py")
DOELSEIF ([Ueberschuss] >600 and [Lader] eq "on" and [Wert_I:A] !=10) ("python2 /usr/local/bin/10Amp.py")
DOELSEIF ([Ueberschuss] >500 and [Lader] eq "on" and [Wert_I:A] !=8) ("python2 /usr/local/bin/8Amp.py")
DOELSEIF ([Ueberschuss] >400 and [Lader] eq "on" and [Wert_I:A] !=6) ("python2 /usr/local/bin/6Amp.py")
DOELSEIF ([Ueberschuss] >300 and [Lader] eq "on" and [Wert_I:A] !=4) ("python2 /usr/local/bin/4Amp.py")
DOELSEIF (([Ueberschuss] >200 and [Lader] eq "on" and [Wert_I:A] >2.5) or ([Lader] eq "off" and [Wert_I:A] >2)) ("python2 /usr/local/bin/2Amp.py")
DOELSEIF ([Ladestrom:state] eq "25A" and [Ueberschuss] <0) ("python2 /usr/local/bin/22Amp.py")
DOELSEIF ([Ladestrom:state] eq "22A" and [Ueberschuss] <0) ("python2 /usr/local/bin/20Amp.py")
DOELSEIF ([Ladestrom:state] eq "20A" and [Ueberschuss] <0) ("python2 /usr/local/bin/18Amp.py")
DOELSEIF ([Ladestrom:state] eq "18A" and [Ueberschuss] <0) ("python2 /usr/local/bin/16Amp.py")
DOELSEIF ([Ladestrom:state] eq "16A" and [Ueberschuss] <0) ("python2 /usr/local/bin/14Amp.py")
DOELSEIF ([Ladestrom:state] eq "14A" and [Ueberschuss] <0) ("python2 /usr/local/bin/12Amp.py")
DOELSEIF ([Ladestrom:state] eq "12A" and [Ueberschuss] <0) ("python2 /usr/local/bin/10Amp.py")
DOELSEIF ([Ladestrom:state] eq "10A" and [Ueberschuss] <0) ("python2 /usr/local/bin/8Amp.py")
DOELSEIF ([Ladestrom:state] eq "8A" and [Ueberschuss] <0) ("python2 /usr/local/bin/6Amp.py")
DOELSEIF ([Ladestrom:state] eq "6A" and [Ueberschuss] <0) ("python2 /usr/local/bin/4Amp.py")
DOELSEIF ([Ladestrom:state] eq "4A" and [Ueberschuss] <0) ("python2 /usr/local/bin/2Amp.py")
attr cmdState 25A|22A|20A|18A|16A|14A|12A|10A|8A|6A|4A|2A|22A|20A|18A|16A|14A|12A|10A|8A|6A|4A|2A
attr doalways 1
attr wait 0:0:0:0:0:0:0:0:0:0:0:0:5:5:5:5:5:5:5:5:5:5:5
So, sensationell was jetzt geht. Bis zu 30% mehr Batterieladung.
Habe weiterhin an der Stellschraube gedreht.
DOELSEIF (([Ueberschuss] >1400 and [Lader] eq "on" and [Xtender_Batt_A] <25) or ([Ladestrom:state] eq "22A" and [Ueberschuss] >150)) ("python2 /usr/local/bin/25Amp.py")
DOELSEIF (([Ueberschuss] >1200 and [Lader] eq "on" and [Xtender_Batt_A] <22) or ([Ladestrom:state] eq "20A" and [Ueberschuss] >150)) ("python2 /usr/local/bin/22Amp.py")
DOELSEIF (([Ueberschuss] >1100 and [Lader] eq "on" and [Xtender_Batt_A] <20) or ([Ladestrom:state] eq "18A" and [Ueberschuss] >150)) ("python2 /usr/local/bin/20Amp.py")
DOELSEIF (([Ueberschuss] >1000 and [Lader] eq "on" and [Xtender_Batt_A] <18) or ([Ladestrom:state] eq "16A" and [Ueberschuss] >150)) ("python2 /usr/local/bin/18Amp.py")
DOELSEIF (([Ueberschuss] >900 and [Lader] eq "on" and [Xtender_Batt_A] <16) or ([Ladestrom:state] eq "14A" and [Ueberschuss] >150)) ("python2 /usr/local/bin/16Amp.py")
DOELSEIF (([Ueberschuss] >800 and [Lader] eq "on" and [Xtender_Batt_A] <14) or ([Ladestrom:state] eq "12A" and [Ueberschuss] >150)) ("python2 /usr/local/bin/14Amp.py")
DOELSEIF (([Ueberschuss] >700 and [Lader] eq "on" and [Xtender_Batt_A] <12) or ([Ladestrom:state] eq "10A" and [Ueberschuss] >150)) ("python2 /usr/local/bin/12Amp.py")
DOELSEIF (([Ueberschuss] >600 and [Lader] eq "on" and [Xtender_Batt_A] <10) or ([Ladestrom:state] eq "8A" and [Ueberschuss] >150)) ("python2 /usr/local/bin/10Amp.py")
DOELSEIF (([Ueberschuss] >500 and [Lader] eq "on" and [Xtender_Batt_A] <8) or ([Ladestrom:state] eq "6A" and [Ueberschuss] >150)) ("python2 /usr/local/bin/8Amp.py")
DOELSEIF (([Ueberschuss] >400 and [Lader] eq "on" and [Xtender_Batt_A] <6) or ([Ladestrom:state] eq "4A" and [Ueberschuss] >150)) ("python2 /usr/local/bin/6Amp.py")
DOELSEIF (([Ueberschuss] >300 and [Lader] eq "on" and [Xtender_Batt_A] <4) or ([Ladestrom:state] eq "2A" and [Ueberschuss] >150)) ("python2 /usr/local/bin/4Amp.py")
DOELSEIF (([Ueberschuss] >200 and [Lader] eq "on" and [Xtender_Batt_A] <=2) or ([Lader] eq "off" and [Wert_I:A] >2)) ("python2 /usr/local/bin/2Amp.py")
DOELSEIF ([Ladestrom:state] eq "25A" and [Ueberschuss] <1) ("python2 /usr/local/bin/22Amp.py", setreading Wert_I A 22)
DOELSEIF ([Ladestrom:state] eq "22A" and [Ueberschuss] <1) ("python2 /usr/local/bin/20Amp.py", setreading Wert_I A 20)
DOELSEIF ([Ladestrom:state] eq "20A" and [Ueberschuss] <1) ("python2 /usr/local/bin/18Amp.py", setreading Wert_I A 18)
DOELSEIF ([Ladestrom:state] eq "18A" and [Ueberschuss] <1) ("python2 /usr/local/bin/16Amp.py", setreading Wert_I A 16)
DOELSEIF ([Ladestrom:state] eq "16A" and [Ueberschuss] <1) ("python2 /usr/local/bin/14Amp.py", setreading Wert_I A 14)
DOELSEIF ([Ladestrom:state] eq "14A" and [Ueberschuss] <1) ("python2 /usr/local/bin/12Amp.py", setreading Wert_I A 12)
DOELSEIF ([Ladestrom:state] eq "12A" and [Ueberschuss] <1) ("python2 /usr/local/bin/10Amp.py", setreading Wert_I A 10)
DOELSEIF ([Ladestrom:state] eq "10A" and [Ueberschuss] <1) ("python2 /usr/local/bin/8Amp.py", setreading Wert_I A 8)
DOELSEIF ([Ladestrom:state] eq "8A" and [Ueberschuss] <1) ("python2 /usr/local/bin/6Amp.py", setreading Wert_I A 6)
DOELSEIF ([Ladestrom:state] eq "6A" and [Ueberschuss] <1) ("python2 /usr/local/bin/4Amp.py", setreading Wert_I A 4)
DOELSEIF ([Ladestrom:state] eq "4A" and [Ueberschuss] <1 and [Lader] eq "on") ("python2 /usr/local/bin/2Amp.py", setreading Wert_I A 2)
cmdState 25A|22A|20A|18A|16A|14A|12A|10A|8A|6A|4A|2A|22A|20A|18A|16A|14A|12A|10A|8A|6A|4A|2A
do always
wait 0:0:0:0:0:0:0:0:0:0:0:0:5,5:5,5:5,5:5,5:5,5:5,5:5,5:5,5:5,5:5,5:5,5
Hallo satprofi, Hut ab, erstaunlich was du da hinbekommen hast. Spannend wäre für Menschen die zwar fhem "können", aber mit Python noch nichts am Hut hatten, eine kleine Hilfestellung, wie man das von dir erarbeitete zB auf einem Raspi umsetzt? Weil deine Anwendung ist ja jetzt speziell auf dich zugeschnitten, denke aber, jeder möchte vielleicht gerne seine eigenen Einstellungen abfragen und seine eigenen daraus resultierenden notifys/DOIF´s basteln? Vielleicht ist deswegen die response hier im Thread recht klein?
Oder jemand der Perl kann deine Scripts zB in das Modul von pah umwandelt/einbastelt? .... dass man auch ohne den Umweg Python direkt in fhem arbeiten kann. Hexcodes und weiterer Ausbau kann man dann ja zusammen machen wenn das Gerüst (das Modul) steht (mehr/alle Hexcodes einpflegen).
lieb Gruß
H.
Hallo.
Das mit einbindung in FHEM hab ich mir schon angesehen, über das script vom SolarLogUtils.pm.
Ich finde dort aber nicht den Abschnitt mit den Commandos.
Was aber zu bedenken wäre, schafft es evt. ein Modul alle Werte vom Xtender abzufragen? Es ist eine Unsumme an Werten, wo ich denke das FHEM in die Knie gehen wird bei de Abfrage. Man müsste wie, bei SolarLogUtils nur die Werte eintragen die man wirklich möchte. aber dann kann man mein Abfragescript auch hernehmen und anpassen.
man könnte ja über attribute des Moduls die für sich spannenden Werte definieren? Das externe script macht das Ganze für fhemler die sich eher mit Linux rumschlagen als dass sie sich das ausgesucht hätten recht komplex ;) .... und irgendwie um die Ecke wenn ich doch direkt in fhem arbeiten könnte ...... Also versteh mich nicht falsch, ich wurschtel gerne in .pm´s rum, aber da weiß ich, wie ich es rückgängig machen kann. Linux/RPI bin ich einfach happy, dass alles läuft und mehr will ich damit nicht zu tun haben, solange ich nicht muß. Brauch nicht noch eine Baustelle.
Ich hatte mir das Modul von pah ganz am Anfang auch mal angeschaut, aber das ist wenn man sich nicht auskennt zu komplex (und zu weitreichend bezüglich der Auswirkungen auf den Xtender). Hatte aber das "Gefühl", dass das schon die richtige Richtung ist (Kommunikation über RS232 und alles dabei was es als Modul in fhem integrierbar macht).
Hey, ich schreibsel hier weit über meiner Verständniskategorie ;)
Hier einmal ein Beispiel, wie es läuft.
Man sieht schön wann der Lader rauf od. runterregelt.
Hallo Alle,
ich möchte gern einen Xtender von Studer einbinden über die xcom-232.
Kennt Ihr jemanden der schon so ein fhem-modul geschrieben hat?
Danke
Kersten
zwar eine späte Antwort, aber vielleicht kommt ja tatsächlich mal einer dazu, das zu tun.
Meines Wissens nach gibt es noch kein direktes Modul.
Zitat von: Kersten am 12 Februar 2020, 12:49:42
Hallo Alle,
ich möchte gern einen Xtender von Studer einbinden über die xcom-232.
Kennt Ihr jemanden der schon so ein fhem-modul geschrieben hat?
Danke
Kersten
Die Befehlsstrings könnte ich beisteuern, je nach Erfordernis.
mit scom.exe alle werte auslesbar.
LG
Studer über Modbus
Das:
https://www.studer-innotec.com/de/actualites/die-studer-python-library-mit-einem-schritt-sind-sie-in-der-welt-der-entwickler-7439
ist doch was für uns?! ... in Kombi mit Stefan´s Modbus Modul
https://forum.fhem.de/index.php?topic=75638.0
Ich lese zwar zwei Stromzähler über Modbus aus, nur leider habe ich damals nicht verstanden was ich tue sondern mich an Anleitungen gehalten :o
EDIT: @satprofi ... seh gerade, du hast schon gepostet
https://forum.fhem.de/index.php/topic,113688.msg1079516.html#msg1079516
... eigentlich hatte ich auf dich gehofft! ;D
-> https://forum.fhem.de/index.php/topic,117826.0.html (https://forum.fhem.de/index.php/topic,117826.0.html)
Hallo,
seit kurzem besitze ich jetzt einen XTM1500-12 mit einem XCOM232i und einem USB-RS232 Adapter.
Ich kann bequem die Batteriespannung id:3000 Ladestrom id:3005 auslesen.
Sobald ich aber versuche den Ladestrom zu begrenzen (wie hier schon im Thread beschrieben mit)
cmd2Amp = '\xAA\x00\x01\x00\x00\x00\x65\x00\x00\x00\x0E\x00\x73\x79\x00\x02\x02\x00\x72\x04\x00\x00\x05\x00\x00\x00\x00\x40\xBE\x1A' id:1138 Ladestrom 2A
findet keine Reaktion im XTM statt und vor allem die Abfragen sind nicht mehr möglich!
Erst wenn ich die Verbindung XTM-XCOM trenne und neu verbinde laufen meine Abfragen wieder.
hat jemand eine Idee was mein Problem ist?
Gruß osid-timo
wichtig ist , zu beginn den zugriff auf den flashspeicher zu sperren.. denn jeder steuerbefehl wird sonst in den flash geschrieben, der aber nach 1000 befehlen tot ist.
versuche einmal den befehl über scom.exe abzusenden, da siehst du sofort was nicht passt.
Hallo,
der Tipp war gut
mit dem Schreiben des max. Ladestromes kommt
scom.exe --port=COM3 --verbose=3 write_property src_addr=1 dst_addr=101 object_type=2 object_id=1138 property_id=5 format=FLOAT value=2.0
debug: verbose_level=3
debug: port=COM3
send property_request:
device_addr=101
object_type=0x2
object_id=1138
property_id=5
length=4
data=
000| 00 00 00 40
debug: tx bytes:
000| AA 00 01 00 00 00 65 00 00 00
010| 0E 00 73 79 00 02 02 00 72 04
020| 00 00 05 00 00 00 00 40 BE 1A
debug: rx bytes:
error (3): RESPONSE_TIMEOUT
ein Versuch das Schreiben ins Flash zu verhindern kommt auch ein Fehler
scom.exe --port=COM3 --verbose=3 write_property src_addr=1 dst_addr=101 object_type=2 object_id=1550 property_id=5 format=BOOL value=0
debug: verbose_level=3
debug: port=COM3
send property_request:
device_addr=101
object_type=0x2
object_id=1550
property_id=5
length=1
data=
000| 00
debug: tx bytes:
000| AA 00 01 00 00 00 65 00 00 00
010| 0B 00 70 73 00 02 02 00 0E 06
020| 00 00 05 00 00 1C B0
debug: rx bytes:
000| AA 23 65 00 00 00 01 00 00 00
010| 0C 00 94 86 03 02 02 00 0E 06
020| 00 00 05 00 22 00 41 34
error (34): OBJECT_ID_NOT_FOUND
Ich hatte den Verdacht das die nötige SW Version nicht ausreicht, aber das auslesen der Version bringt mich auch nicht weiter:
scom --port=COM3 --verbose=3 write_property src_addr=1 dst_addr=101 object_type=1 object_id=3130 property_id=5 format=FLOAT value=0
debug: verbose_level=3
debug: port=COM3
send property_request:
device_addr=101
object_type=0x1
object_id=3130
property_id=5
length=4
data=
000| 00 00 00 00
debug: tx bytes:
000| AA 00 01 00 00 00 65 00 00 00
010| 0E 00 73 79 00 02 01 00 3A 0C
020| 00 00 05 00 00 00 00 00 4D E6
debug: rx bytes:
000| AA 23 65 00 00 00 01 00 00 00
010| 0A 00 92 82 02 02 01 00 3A 0C
020| 00 00 05 00 4F C6
scom --port=COM3 --verbose=3 write_property src_addr=1 dst_addr=101 object_type=1 object_id=3131 property_id=5 format=FLOAT value=0
debug: verbose_level=3
debug: port=COM3
send property_request:
device_addr=101
object_type=0x1
object_id=3131
property_id=5
length=4
data=
000| 00 00 00 00
debug: tx bytes:
000| AA 00 01 00 00 00 65 00 00 00
010| 0E 00 73 79 00 02 01 00 3B 0C
020| 00 00 05 00 00 00 00 00 4E F0
debug: rx bytes:
000| AA 23 65 00 00 00 01 00 00 00
010| 0A 00 92 82 02 02 01 00 3B 0C
020| 00 00 05 00 50 CC
waren wg der SW Version es die richtigen Befehle?
noch bin ich ratlos, was das schreiben verhindert.
Jeder weitere Tipp ist willkommen
Gruß osid-timo
SW u. andere Infos nicht mit "write" , sondern mit "read"
scom.exe --port=COM3 --verbose=3 read_property src_addr=1 dst_addr=101 object_type=1 object_id=3000 property_id=1 format=FLOAT #Battery Spg.
scom.exe --port=COM3 --verbose=3 read_property src_addr=1 dst_addr=101 object_type=1 object_id=3130 property_id=1 format=FLOAT # ID SOFT msb
Danke für die schnelle Antwort
Parameter lesen geht mit dem read_property!!! ich konnte die Version auslesen: 1.6.34, damit ist es die aktuelle
mit jedem write verliere ich die Kommunikation (bisher nur die Paramter 1550 und 1138 getestet)
muss man sich mit einem xcom-232 erst Rechte zu beschreiben geben? wenn ja wie, wenn nein was ist mein Problem
kann die property_id helfen?
Gruß Oswald
szell mal auf experte ei den xtender
Hallo,
es sieht so aus als wenn ich den XCOM232 sowohl auf Expert wie Installer stellen kann
>scom.exe --port=COM3 --verbose=3 write_property src_addr=1 dst_addr=501 object_type=2 object_id=5012 property_id=8 format=ENUM value=0x0030
debug: verbose_level=3
debug: port=COM3
send property_request:
device_addr=501
object_type=0x2
object_id=5012
property_id=8
length=2
data=
000| 30 00
debug: tx bytes:
000| AA 00 01 00 00 00 F5 01 00 00
010| 0C 00 02 DA 00 02 02 00 94 13
020| 00 00 08 00 30 00 E2 C3
debug: rx bytes:
000| AA 23 F5 01 00 00 01 00 00 00
010| 0A 00 23 2B 02 02 02 00 94 13
020| 00 00 08 00 B4 13
>scom.exe --port=COM3 --verbose=3 read_property src_addr=1 dst_addr=501 object_type=2 object_id=5012 property_id=8 format=ENUM
debug: verbose_level=3
debug: port=COM3
send property_request:
device_addr=501
object_type=0x2
object_id=5012
property_id=8
length=0
data=
debug: tx bytes:
000| AA 00 01 00 00 00 F5 01 00 00
010| 0A 00 00 D6 00 01 02 00 94 13
020| 00 00 08 00 B1 F6
debug: rx bytes:
000| AA 23 F5 01 00 00 01 00 00 00
010| 0C 00 25 2F 02 01 02 00 94 13
020| 00 00 08 00 30 00 E3 D0
response:
device_addr=501
object_type=0x2
object_id=5012
property_id=8
length=2
data=48
Ich kann auch die Xtender Infos auslesen Spannung, Strom, SOC..
scom.exe --port=COM3 --verbose=3 read_property src_addr=1 dst_addr=101 object_type=1 object_id=3007 property_id=1 format=FLOAT value=2.0
debug: verbose_level=3
debug: port=COM3
send property_request:
device_addr=101
object_type=0x1
object_id=3007
property_id=1
length=0
data=
debug: tx bytes:
000| AA 00 01 00 00 00 65 00 00 00
010| 0A 00 6F 71 00 01 01 00 BF 0B
020| 00 00 01 00 CC BA
debug: rx bytes:
000| AA 22 65 00 00 00 01 00 00 00
010| 0E 00 95 7F 02 01 01 00 BF 0B
020| 00 00 01 00 00 FE FF 43 0E 41
response:
device_addr=101
object_type=0x1
object_id=3007
property_id=1
length=4
data=511.984
sobald ich aber auf einen Parameter zugreife read wie write
bekomme ich Fehler
scom.exe --port=COM3 --verbose=3 read_property src_addr=1 dst_addr=101 object_type=2 object_id=1138 property_id=5 format=FLOAT
debug: verbose_level=3
debug: port=COM3
send property_request:
device_addr=101
object_type=0x2
object_id=1138
property_id=5
length=0
data=
debug: tx bytes:
000| AA 00 01 00 00 00 65 00 00 00
010| 0A 00 6F 71 00 01 02 00 72 04
020| 00 00 05 00 7D D9
debug: rx bytes:
error (3): RESPONSE_TIMEOUT
oder
scom.exe --port=COM3 --verbose=3 read_property src_addr=1 dst_addr=101 object_type=2 object_id=1550 property_id=5 format=FLOAT
debug: verbose_level=3
debug: port=COM3
send property_request:
device_addr=101
object_type=0x2
object_id=1550
property_id=5
length=0
data=
debug: tx bytes:
000| AA 00 01 00 00 00 65 00 00 00
010| 0A 00 6F 71 00 01 02 00 0E 06
020| 00 00 05 00 1B 8B
debug: rx bytes:
000| AA 23 65 00 00 00 01 00 00 00
010| 0C 00 94 86 03 01 02 00 0E 06
020| 00 00 05 00 22 00 40 29
error (34): OBJECT_ID_NOT_FOUND
wer hat noch einen Tipp das Problem zu lösen oder welche Konfiguration verhindert den Parameterzugriff?
Gruß osid-timo
Hallo,
nach einem Software Update von XTM und XCOM232i kann ich nun auf die Parameter lesend zugreifen.
den XCOM232 konnte ich in den Expert Mode mit scom.exe --port=COM3 --verbose=3 write_property src_addr=1 dst_addr=501 object_type=2 object_id=5012 property_id=8 format=ENUM value=0x0020
versetzten.
den Parameter 1550 (kein schreiben ins Flash) konnte ich mit scom.exe --port=COM3 --verbose=3 write_property src_addr=1 dst_addr=101 object_type=2 object_id=1550 property_id=5 format=BOOL value=0
auf false setzten.
Ein schreiben der Parameter z.B 1138 gelingt mir immer noch nicht, den Befehl habe ich aus dem Manual kopiert,
scom.exe --port=COM3 --verbose=3 write_property src_addr=1 dst_addr=101 object_type=2 object_id=1138 property_id=5 format=FLOAT value=12.0
mit anderen property_id habe ich auch keinen Erfolg.
hat noch jemand eine Idee?
Gruß osid-timo
lädt er mit 12 A?
eine abfrage geht ja nur vom eintrag im flash, der ändert sich nicht, wenn du zugriff sperrst. ich habe 2A im flash, also startet er mit 2A, den rest stelle ich über xcom ein
Hallo,
ich habe jetzt den Strom auf 2A begrenzt und damit wird geladen.
jetzt bleibt nur die Frage wie ich den max Strom dynamisch erhöhen kann um die Ladung zu steuern.
welche Kommandos verwendet Ihr?
und habt Ihr den Parameter 1550 auf true or false?
Gruß osid-timo
na dann klappts ja. 1550 muss off sein, den jeder befehl an den studer wird sonst in flash geschrieben.
steuern musst du halt bei jedem neuen überschuss
Hallo,
Mittlerweile konnte ich mit den Infos von Satprofi der tollen Xcom API: https://gogs.es-lab.de/mueller_to/Xcom-API (https://gogs.es-lab.de/mueller_to/Xcom-API)
einen scom Nachbau für Linux zu realisieren und man muss nicht immer den USB-Adapter umstecken. Die Lösung hat noch Prototypen Status und es ist einiges an Test Code enthalten, ich möchte es trotzdem hier mal zurückgeben, falls noch Bedarf besteht.
Die Befehlstruktur ist an scom angelehnt und kann über FHEM in meinem Fall ein DOIF oder die Kommandozeile genutzt werden. ACHTUNG das Python Programm schreibt einen Status an mein DOIF "XtenderDO" zurück.
Befehlsbeispiel für die Kommandozeile: python3 /usr/local/bin/Studer/XtenderPara.py write parameter 1124 value_qsp bool 0
hier mein DOIF mit um zyklisch Xtender Daten holen um die Visiualsierung über FHEM zu integrieren und die entsprechende Ladesteuerung.
([+[$SELF:P_time]]) ##schrittweises einlesen der Xtender infos, variabel damit bei zusätzlichen Befehlen über die Konsole weniger Konflikte entstehen
(IF ([$SELF:P_Step] == 0) ("python3 /usr/local/bin/Studer/XtenderPara.py read info 3000 value float")) ##BattU
(IF ([$SELF:P_Step] == 1) ("python3 /usr/local/bin/Studer/XtenderPara.py read info 3005 value float")) ##BattIavg
(IF ([$SELF:P_Step] == 2) ("python3 /usr/local/bin/Studer/XtenderPara.py read info 3137 value float")) ##InputACPower
(IF ([$SELF:P_Step] == 3 and [$SELF:P_Step1] == 0) ("python3 /usr/local/bin/Studer/XtenderPara.py read info 3004 value float")) ##BattIwant
(IF ([$SELF:P_Step] == 3 and [$SELF:P_Step1] == 1) ("python3 /usr/local/bin/Studer/XtenderPara.py read info 3095 value float")) ##BattIcurr
(IF ([$SELF:P_Step] == 3 and [$SELF:P_Step1] == 2) ("python3 /usr/local/bin/Studer/XtenderPara.py read info 3006 value float")) ##BattUrip
(IF ([$SELF:P_Step] == 3 and [$SELF:P_Step1] == 3) ("python3 /usr/local/bin/Studer/XtenderPara.py read info 3078 value float")) ##BattDischarge
(setreading $SELF P_Step {([$SELF:P_Step] + 1)}) ##next Step
(IF ([$SELF:P_Step] >= 4) (setreading $SELF P_Step 0,setreading $SELF P_Step1 {([$SELF:P_Step1] + 1)}))
(IF ([$SELF:P_Step1] >= 4) (setreading $SELF P_Step1 0))
##
DOELSEIF ([$SELF:Lader] eq "on"
and (([MyEnergieEl:EasymeterQ3C_power] < -200 and [$SELF:Xtender_Batt_A] < 8)
or ([MyEnergieEl:EasymeterQ3C_power] < -50 and [$SELF:Xtender_Batt_A] == 6)))
("python3 /usr/local/bin/Studer/XtenderPara.py Ladestrom 8", setreading $SELF Xtender_Batt_A 8)()
##3
DOELSEIF ([$SELF:Lader] eq "on"
and (([MyEnergieEl:EasymeterQ3C_power] < -150 and [$SELF:Xtender_Batt_A] < 6)
or ([MyEnergieEl:EasymeterQ3C_power] < -50 and [$SELF:Xtender_Batt_A] == 4) ##auframpen
or ([MyEnergieEl:EasymeterQ3C_power] > -10 and [$SELF:Xtender_Batt_A] == 8))) ##abrampen
("python3 /usr/local/bin/Studer/XtenderPara.py Ladestrom 6", setreading $SELF Xtender_Batt_A 6)()
##4
DOELSEIF ([$SELF:Lader] eq "on"
and (([MyEnergieEl:EasymeterQ3C_power] < -100 and [$SELF:Xtender_Batt_A] <4) ##auframpen
or ([MyEnergieEl:EasymeterQ3C_power] < -50 and [$SELF:Xtender_Batt_A] == 2) ##auframpen
or ([MyEnergieEl:EasymeterQ3C_power] > -10 and [$SELF:Xtender_Batt_A] == 6))) ##abrampen
("python3 /usr/local/bin/Studer/XtenderPara.py Ladestrom 4", setreading $SELF Xtender_Batt_A 4)()
##5
DOELSEIF ([$SELF:Lader] eq "on"
and (([MyEnergieEl:EasymeterQ3C_power] < -50 and [$SELF:Xtender_Batt_A] < 2) ##auframpen
or ([MyEnergieEl:EasymeterQ3C_power] > -10 and [$SELF:Xtender_Batt_A] == 4))) ##abrampen
("python3 /usr/local/bin/Studer/XtenderPara.py Ladestrom 2", setreading $SELF Xtender_Batt_A 2)()
##6
DOELSEIF ([$SELF:Lader] eq "on" and [MyEnergieEl:EasymeterQ3C_power] > 10 and [$SELF:Xtender_Batt_A] > 0) ##0A laden
("python3 /usr/local/bin/Studer/XtenderPara.py Ladestrom 0", setreading $SELF Xtender_Batt_A 0)()
##7
DOELSEIF ([$SELF:P_mybutton] eq "on" or [[myTwilight:sr_weather]]) ("python3 /usr/local/bin/Studer/XtenderPara.py Lader on",setreading $SELF Lader on,$SELF cmd_6)
##8
DOELSEIF ([$SELF:P_mybutton] eq "off" or [[myTwilight:ss_weather]]) ("python3 /usr/local/bin/Studer/XtenderPara.py Lader off",setreading $SELF Lader off,set $SELF cmd_6)
##9
DOELSEIF ([$SELF:P_mybutton] eq "InverterOn") ("python3 /usr/local/bin/Studer/XtenderPara.py Inverter on")
##10
DOELSEIF ([$SELF:P_mybutton] eq "InverterOff") ("python3 /usr/local/bin/Studer/XtenderPara.py Inverter off")
##11
DOELSEIF ([$SELF:P_mybutton] eq "init") (setreading $SELF P_myPythonCmd "python3 /usr/local/bin/Studer/XtenderPara.py ) (setreading $SELF P_Step 0)(setreading $SELF P_Step1 0)
##12
DOELSEIF ([$SELF:P_mybutton] eq "disable") (setreading $SELF P_Step {([$SELF:P_Step] + 1)})
##
DOELSEIF ([$SELF:P_mybutton] eq "x1")("python3 /usr/local/bin/Studer/XtenderPara.py User Expert") ##XCOM auf Experte
##
DOELSEIF ([$SELF:P_mybutton] eq "xx")("python3 /usr/local/bin/Studer/XtenderPara.py write parameter 1138 value_qsp float 2.0") ##Ladestrom
Gruß osid-timo
hallo.
klappt das auch mit python2 ?
LG
Hallo,
kann mit Anpassungen des COM Interfaces auch mit Python2 klappen
Die XtenderPara, habe ich aus eigenen und fremden Quellen zusammen gezogen und ist in meinem letzten Post zum Herunterladen
Ach deswegen bekomme ich Fehlermeldung bzgl. Com port