Da die ECU normalerweise mit 300sec pollt macht es seitens des Adapters keinen Sinn die ECU schneller abzufragen.
Auch hatten manche ECU-FW Versionen ein Problem mit der TCP-Verbindung bei häufigen Abfragen. Die ECU musste dann z.B. nach einem Tag resetet werden.
Deshalb baut der Adapter zu jedem Service eine neue TCP-Verbindung auf. Das ist zwar inefizent aber beseitigt die ECU hänger.
Deshalb ist 60sec eine brauchbare Zykluszeit.

Ich benutze bei mir ein Shelly und die Daten vom Zähler. Die kommen im 10sec Intervall. Damit habe ich die Daten zur Gesamtleistung (Erzeugung, Einspeisung, Verbrauch) nahezu in Echtzeit.

@apollon77 said in Test Adapter apsystems-ecu v0.2.x GitHub:

Ich erinnere mich aus einem Home Assistant thread das man mit einem Befehl man die Ecu in nen service Mode versetzen kann.

Den Servicemode kann man über die Service-App aktivieren. Dannach pollt die ECU die Inverter so schnell sie kann. Der Servicemode beendet sich automatisch nach einer gewissen Zeit.

Eine Möglichkeit den Servicemode über das Protokoll zu aktivieren ist mir z:Z. nicht bekannt. Habe das damals grob untersucht, war aber nicht erfolgreich.

@esp8266 said in Test Adapter apsystems-ecu v0.2.x GitHub:

woher kommen diese error Meldungen:

Da das Problem sporatisch auftritt nehme ich an, dass der Fehler in der ECU liegt.

Bei der Überprüfung der Antwort von der ECU werden Fehler festgestellt.

• Der Kommando-Code wird nicht unterstützt.
• Das Frame ist unvollständig

Ich gehe davon aus, dass die Transportschicht (TCP) Übertragungsfehler erkennen würde.

Annahme: Die ECU hat falsche und/oder unvollständige Anwendungsdaten geschickt. Vielleicht ist sie temp. überlastet. Aber das ist letztlich Kaffeesatzleserei.

Wenn du mir einen Log schickst kann ich die empfangenen Daten mal anschauen.

Aktuelle Version: 0.2.10 (Testversion)
Veröffentlichungsdatum: 10.10.2023
Github Link: https://github.com/npeter/ioBroker.apsystems-ecu

Ich habe einen Adapter für APSystems Microinverter erstellt. Hiebei wird das ECU-R Überwachungsgerät von APSystems benötigt. Die Überwachungeinheit sammelt Daten von den Wechselrichtern und den angeschlossenen Solarmodulen über Zigbee. Ein Großteil dieser Daten wird vom Adapter abgefragt und bereitgestellt.
Der Adapter unterstützt im Prinzip einen oder mehrere Wechselrichter vom Typ QS1, YC600, DS3 und YC1000 und die Überwachungsgeräte ECU-R und ECU-B.

Da meine eigene Analge nur aus einem QS1 und einer ECU-R besteht waren bisher nur eingeschränkte Tests möglich.
Auch ist zur Zeit nicht klar, ob eine bestimmte Firmwareversionen in der ECU notwendig ist.

Würde mich über weiter Tests mit anderen Konfigurationen und Anregungen freuen.

Der Adapter steht in Github (Link siehe oben) bereit.

Installation der Alpha:

• Unter Adapter Expertenmodus aktivieren
• Unter Adapter das Github Icon klicken
  
• Benutzerdefiniert anwählen
• URL eintragen
• Warnung berücksichtigen
• Installieren klicken

• Hier eine Testinstallation auf einem PI

• Jetzt muss nur noch eine Instanz angelegt werden mit

iobroker add apsystems-ecu

• In der Konfiguration muss jetzt nur die ECU WLAN IP Adresse angepasst werden

• Weitere Informationen sind im README zu finden.

Das wars auch schon!

@esp8266
... der Cach ist eine Eigenschaft von Homeassistant.
Bei der Homeassistant-Lösung wird nach n cach-Zugriffen die ECU über einen externen Switch aus- und eingeschaltet.
Das ist im iobroker ja sehr elegant mit ein paar Zeilen JS zu realisieren.

Wenn du im "homeassistant python-code"(link) was anderes findest lasse es mich wissen.

@esp8266
Welche Optionen?

@air-q
Danke für die schnelle Aktion.

• Speichern funktioniert
• Objekte werden angelegt und aktualisiert (ohne Fehler)
• Das gilt für Realtime data und Average data
• Anmeldung erfolgt über IP
• Scheint noch ein kleines Problem beim Aufräumen zu geben

air-q.0
	2023-11-23 15:25:42.655	info	terminating
air-q.0
	2023-11-23 15:25:42.654	warn	Found uncleared intervals (report to developer): 2
air-q.0
	2023-11-23 15:25:42.144	info	Got terminate signal TERMINATE_YOURSELF
air-q.0
	2023-11-23 15:19:58.339	info	starting. Version 0.0.1 in E:/Projekte/iobroker/node_modules/iobroker.air-q, node: v18.18.0, js-controller: 3.3.22
air-q.0
	2023-11-23 15:19:55.320	info	Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
air-q.0
	2023-11-23 15:19:55.320	info	terminating
air-q.0
	2023-11-23 15:19:55.319	warn	Found uncleared intervals (report to developer): 2
air-q.0
	2023-11-23 15:19:54.811	info	Got terminate signal TERMINATE_YOURSELF 

Grüße
Peter

@air-q

air-q:
Nachdem ich gesehen hatte, dass ein Adapter in Arbeit ist, habe ich einen air-q basic bestellt und heute erhalten.
Inbetriebnahme/Einrichtung per Webbrowser hat problemlos funktioniert.
Aktuellen Messwerte sind per 192.168.178.107 abrufbar.

iobroker:

• Meine Installation ist auf dem aktuellsten Stand.
• Platform ist ein Min-PC mit Linux Mint.
• Adapterinstallation (github) verlief unauffällig.
• Instanzierung war erfolgreich.
• Der Adapter ist grün (ohne spez. Konfiguration)
  

Mein Problem:
Die Konfiguration lässt sich nicht abbspeichern!
Hier meine Konfigdaten:

Nur der Button ABBRECHEN ist aktiv

Wo liegt mein Fehler?
Danke und Gruesse
peter

@rkccorian
Danke für Dein Feedback!

@esp8266
Sorry - nö war daneben geschaut

@esp8266

Beschreibung siehe Test Adapter apsystems-ecu v0.2.x GitHub

...

Jetzt muss nur noch eine Instanz angelegt werden mit

iobroker add apsystems-ecu

In der Konfiguration muss jetzt nur die ECU WLAN IP Adresse angepasst werden

Weitere Informationen sind im README zu finden.

@esp8266 said in Test Adapter apsystems-ecu v0.2.x GitHub:

woher kommen diese error Meldungen:

Da das Problem sporatisch auftritt nehme ich an, dass der Fehler in der ECU liegt.

Bei der Überprüfung der Antwort von der ECU werden Fehler festgestellt.

• Der Kommando-Code wird nicht unterstützt.
• Das Frame ist unvollständig

Ich gehe davon aus, dass die Transportschicht (TCP) Übertragungsfehler erkennen würde.

Annahme: Die ECU hat falsche und/oder unvollständige Anwendungsdaten geschickt. Vielleicht ist sie temp. überlastet. Aber das ist letztlich Kaffeesatzleserei.

Wenn du mir einen Log schickst kann ich die empfangenen Daten mal anschauen.

@tschensie said in Test Adapter apsystems-ecu v0.2.x GitHub:

Allerdings werden die Werte nicht aktualisiert.
Hier mal das Protokoll seit ich den Haken gesetzt habe:

Bestimmte FW-Versionen der ECU-B unterstützen nichtmehr alle Dienste:
Siehe Changelog zur 0.2.9

• New config parameter extended_service to disable/enable GetEnergyOfWeekMonthYear service processing
  • avoid warnings if firmware support for GetEnergyOfWeekMonthYear service is missed
  • checked: GetEnergyOfWeekMonthYear states created and services executed
  • not checked (default): GetEnergyOfWeekMonthYear services are skiped and states not created

Da hat ApSystems wohl etwas Speicher benötigt

@fluri said in Test Adapter apsystems-ecu v0.2.x GitHub:

versteh ich nicht. In der EMA APP werden mir die Daten korrekt und immer angezeigt. Nur der Adapter im IOBroker verliert aller paar Stunden die Verbindung zur ECU.

Das ist so nicht korrekt!
Nicht der Adapter verliert die Verbindung sondern die ECU antwortet nicht mehr. Die ECU befindet sich dann in einem Zustand aus der nur ein RESET der ECU weiterhilft.
Nach dem RESET der ECU erhält der Adapter ohne Restart wieder Daten. Gefühlt läuft die ECU in ein Ressourcenproblem, Memory leak o.ä. Aber das ist Kaffeesatz lesen und hilft nicht weiter.
Auch stellt sich die Frage, ob die "EMA Service App" auch nach vielen Stunden noch Daten erhält!

Richtig ist natürlich auch, dass der Adapter eine undokumentierte, nicht-öffentliche Schnittstelle der ECU verwendet, was vom Hersteller so nicht vorgesehen war und von dessen Tests ggf. nicht vollständig abgedeckt wird.
Unklar ist, warum sich einige wenige ECUs so verhalten. Ich kenne bisher nur einen weiteren Fall mit ähnlichem Verhalten. Ich habe aber keinen Überblick (ECU-typ, Firmware, Inverter usw.) über laufende System da typischerweise nur bei Problemen eine Rückmeldung erfolgt.