Test Adapter apsystems-ecu v0.2.x GitHub
-
In einer RealTimeData- Response werden 6 Inverter gelistet:
- 703000015029 - YC600/DS3
- 703000014489 - YC600/DS3
- 806000058312 - QS1
- 806000055586 - QS1 - ohne Daten
- 806000055796 - QS1
- 806000056773 - QS1 - ohne Daten
Denke, das passt zu Deinen Angaben.
Aktuell sehe ich drei Punkte:
1 - Instabilität der ECU Verbindung
2 - DS3 werden als InverterType 01 (YC600) gemeldet (ID beginnt mit 70)
3 - Angemeldete Inverter werden im RealTimeProtokoll in einem eigenem Format aufgeführt.OK! Für diese Punkte habe ich vorab genug Infos.
-
Ich habe Testversion V0.2.5 bereitgestellt.
Bearbeitet wurden die Punkte:
1 - Instabilität der ECU Verbindung
2 - DS3 werden als InverterType 01 (YC600) gemeldet (ID beginnt mit 70)
3 - Angemeldete Inverter werden im RealTimeProtokoll in einem eigenem Format aufgeführt.Details siehe Changelog.
Zum (schnelleren) Testen kann man die ECU Pollzeit auf 10sec setzen. Später sollten ca. 60sec ausreichend sein.
- Die ECU-Verbindung ist jetzt hoffentlich stabiler.
- Die DS3 sollten jetzt auch als DS3 in der Datenbank auftauchen.
- An der ECU-angemeldete, aber nicht vorhandene Inverter werden ignoriert bis die ECU auch RealTimeDaten liefert
Die V0.2.5 läuft auf meinem Minisystem (1 QS1) ohne Probleme
Tiefergehende tests konnte ich natürlich nicht durchführen.Bei Problemen wie immer ein Logfile posten!
-
habe die 0.2.5 problemlos installieren können.
Der Adapter bleibt grün.Der Log ist angenehm unaufregend.
apsystems-ecu.0 2022-03-25 19:25:10.946 warn rspWatchDog +++ timeout apsystems-ecu.0 2022-03-25 19:24:07.805 warn rspWatchDog +++ timeout apsystems-ecu.0 2022-03-25 19:21:03.673 error Ecu.decodeAndProcessRealTimeData() - +++ invalid inverter type:64Werde gleich mal den Test QS1 ans Netzteil hängen.
Vielen Dank schonmal bis hierher!
-
Es scheint tatsächlich alles zu laufen.
Der bisher unbekannte WR ist bei den Objekten angelegt und dessen aktuellen Daten werden gelesen.Werde morgen berichten wie es mit den anderen WR gelaufen ist wenn die Sonne bekommen.
Wenn ich das Objekt mit dem YC600 lösche, sollte der dann ja später als DS3 erkannt werden oder?
1000 Dank!
Sebastian
-
Sieht auf jedem Fall schon mal besser aus
Die DS3 sollten erkannt werden und als neues Device mit ds3_.... erscheinen. Die yc600 objekte einfach löschen.
Mit dem PowerOfMWYService scheint es noch Probleme zu geben. Auch gefällt mir die Meldung: "+++ invalid inverter type" nicht. Aber mal das Gesamtbild abwarten.
gruesse peter -
@peter_n
habe einen yc600 gelöscht. Es wird dafür auch kein DS3-S angelegt und der vorhandene yc600 erhält keine frischen Daten.
Habe auf einem Testsystem den Adapter auch mal ganz neu installiert. Auch dort werden nur die QS1 angelegt.Der ECU-B funktioniert auch nach dem Update normal mit einem QS1.
Hier mal ein aktueller Log.
-
Positiv
1 ECU-Kommunikation läuft stabil
2 Registrierte Inverter die nicht vorhanden sind werden als solche erkannt und ignoriertNegativ
3 YC600 und DS3 werden nicht mehr erkannt. Habe in der 0.2.6 was eingebaut, bin mir aber nicht ganz sicher ob das passt. Bitte testen.
4 PowerOfWeekMonthYear-Service wird von der ECU nicht mehr beantwortet. Habe den Eindruck das der Service von der Pro-Firmware nicht mehr unterstützt wird! Mal beobachten.Gelegentlich würde mich auch ein Log der ECU-B interessieren.
-
zu 3
Installation hat geklappt und Objekte werden angelegt. Wie es mit frischen Daten aussieht kann ich morgen früh sagen.
iob_ecu-r_0-2-6.logzu 4
Ist für mich nicht tragisch.
Hast Du Deine ECU-R nicht am Netz und hast daher ein anderes Verhalten?Ist es generell eine Überlegung Wert die ECU nicht an das Internet zu hängen, nicht dass APSystems mal auf die Idee kommt die Möglichkeit des Auslesens zu sperren oder erschweren?
Hier nochmal ein Log von der ECU-B Instanz. iob_ecu-b_0-2-6.log
Diese beiden Logs sind von einer anderen ioBroker Installation als bisher. Dann sind die aber konsistent.Mal an alle mit einer ECU-R: Habt ihr auch das Problem dass nach ~anderthalb Tagen keine Daten mehr von ioBroker oder Homeassistant abgerufen werden können? EMA bekommt aber weiter Daten. Dann hilft bei mir nur ein Reboot der ECU-R. Die verwendete ECU-B hat das verhalten nicht und läuft seit dem ersten Start am Stück durch.
-
Es sieht sehr viel besser aus. iob_ecu-b_0-2-6_220327.log
-
Mir fällt gerade auf dass bei den DS3 "dc_power1&2" nicht angelegt werden.
-
@stundenblume
Voltage1 und Voltage2 fehlen auch ...
Bin dran. -
V0.2.7: Voltage und Power sollten nun angelegt werden.
zu 4.
Meine ECU ist ständig mit der Cloud verbunden. Div. Forenbeiträgen kann man entnehmen, dass die ECU auch online sein muss damit die hier verwendeten Services funktionieren. Es gibt aber auch Aktivitäten, die eine Fake-Cloudverbindung anlegen, damit die ECU zufrieden ist. Habe mich aber damit nicht befasst und ist nicht bestätigt.Zur Zeit gibt es wohl FW Versionen "Pro_2.x" bei ECU-R und ECU-B. Bei mir läuft eine 1.x. Das könnte den Unterschied ausmachen.
-
-
Noch ein Copy/Past Fehler! V02.8 rausgestellt.
Zum vollständigen Neuanlegen muessen die unvollständigen DS3 Objekte zuvor gelöscht werden. Zum neu Anlegen wird nur das Vorhandensein des States .online geprüft.
Beim Log (fals erforderlich) zwei Durchläufe aufzeichnen! -
@peter_n
Bei einer neu installierten Instanz ist jetzt alles da.
Evtl 1x "ac_voltage" zu viel? Ein WR hat ja nur 1x AC und bei den QS1 ist auch nur 1x AC_Voltage da. Nicht störend, ist mir einfach aufgefallen.1000 Dank!
-
Die beiden Voltage-Werte werden von der ECU beim YC600 und DS3 in der GetRealTimeData-Response geliefert. Ist wohl ein Relikt der Weiterverwendung der YC600 Struktur.
-
@apollon77
ECU-B Geräte scheinen wohl doch zu funktionieren! Habe pos. Rückmeldungen bekommen. Z.B. mit ECU-FW ECU_B_1.2.20 und QS1. -
@peter_n Interessant, ist die FW "neu"? Über FW hat man ja nicht wirklich kontrolle oder ?!
-
Meine ECU-R hat die gleiche Version und ist schon älter.
-
@peter_n Habe gescannt ... 8899 ist nicht offen bei meiner ECU-B
