Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EMS setter tags #57

Closed
git-kick opened this issue Jan 29, 2022 · 21 comments
Closed

EMS setter tags #57

git-kick opened this issue Jan 29, 2022 · 21 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@git-kick
Copy link
Owner

EMS namespace is only partially supported so far. There are several setter tags which should be supported, like

  • GENERATOR_MODE
  • START_EMERGENCY_POWER_TEST
  • START_MANUAL_CHARGE
  • START_ADJUST_BATTERY_VOLTAGE
  • CANCEL_ADJUST_BATTERY_VOLTAGE
  • BATTERY_TO_CAR_MODE
  • BATTERY_BEFORE_CAR_MODE
  • BATTERY_BEFORE_CHARGE_MODE
  • SET_OVERRIDE_AVAILABLE_POWER
  • SET_EMERGENCY_POWER
  • SET_ERROR_BUFFER_ENABLED
  • SET_POWER_CONTROL_OFFSET

There is no direct request for one of these. If so, prioritization is done on demand.

@git-kick git-kick added enhancement New feature or request postponed Item is near bottom of backlog labels Jan 29, 2022
@git-kick git-kick changed the title Add EMS setter tags EMS setter tags Jan 29, 2022
@ArnoD15
Copy link

ArnoD15 commented Sep 1, 2023

Hallo Uli,

an drei Tags würde Interesse bestehen.

  • START_EMERGENCY_POWER_TEST um den Notstromtest zu starten
  • SET_EMERGENCY_POWER um auf Notstrom umschalten zu können
  • SET_OVERRIDE_AVAILABLE_POWER um die Ladeleistung der Wallbox zu regeln. (Wenn ich das richtig verstanden habe)

Was mir noch fehlt, wäre eine Möglichkeit, die Kalibrierung der Batterie zu starten. Das kann aktuell nur über den E3DC Service gemacht werden. Ich weiß aber leider nicht, welcher Tag dafür verwendet wird.
Könnte das START_ADJUST_BATTERY_VOLTAGE eventuell sein?

@smartboart
Copy link

smartboart commented Sep 4, 2023

Hallo, ich schliesse mich hier an.
Ich benötige diese 3 Tags auch ansteuerbar wenn möglich...
Vielen Dank ..
START_EMERGENCY_POWER_TEST um den Notstromtest zu starten
SET_EMERGENCY_POWER um auf Notstrom umschalten zu können
SET_OVERRIDE_AVAILABLE_POWER

@git-kick
Copy link
Owner Author

git-kick commented Sep 4, 2023

Okay, ich danke euch für den Input und sehe mir das bei nächster Gelegenheit an.
Funktionen, die "nur der Service machen kann", sind vermutlich durch die Rolle bei der Authentisierung abgeschottet. In diesem Fall kann ich wenig Hoffnung machen, weil ich selbst auf meiner E3/DC auch nur "User" bin und deshalb solche Funktionen nicht testen kann.

D.h. START_ADJUST_BATTERY_VOLTAGE bearbeite ich nicht (UserLevel: INSTALLER) - die anderen drei sind User-tags.

@git-kick git-kick removed the postponed Item is near bottom of backlog label Oct 7, 2023
@git-kick git-kick self-assigned this Oct 7, 2023
@git-kick
Copy link
Owner Author

Es gibt eine erste Implementierung: Issue#57ep
(dieser Branch enthält auch andere Erweiterungen seit v1.2.3, u.a. #174, #184 und #185)

OVERRIDE_AVAILABLE_POWER: sollte funktionieren. Mangels E3/DC-Wallbox kann ich allerdings die Wirkung nicht bestätigen. Da die Antwort ein bool ist, verwende ich sie nur, um ack im ioBroker-Objekt zu setzen.

EMERGENCY_POWER: auch hier funktioniert das Setzen des Modus grundsätzlich und die Antwort ist ein bool-Wert, den ich als ack nutze. Die Wirkung habe ich nicht weiter getestet, weil das ohne USV für alle IT-Geräte im Haus wenig Spass macht...

START_EMERGENCY_POWER_TEST: Wenn man hier einen (beliebigen?) bool-Wert einträgt, geht meine S10 in den Inselmodus. Die Antwort ist laut Tagliste die Anzahl gestarteter EP-Tests. Allerdings verwende ich sie auch hier nur für den ack des ioBroker-Objekts. Den Wert gibt es ohnehin bereits in EPTEST_START_COUNTER - dieser hat bei meinem Versuch auch wie erwartet hochgezählt.

Ich bitte euch zu testen und hier Rückmeldung zu geben. Release der drei setter Tags ist geplant mit v1.2.4

@git-kick git-kick added this to the V1.2.4 milestone Oct 18, 2023
@smartboart
Copy link

Hi, danke für die Umsetzung.
Ich muss auch erst diverse Systeme runterfahren bevor ich in den Notstromtest gehe. Das habe ich schon automatisiert. Wie genau berschreibe ich den State EMERGENCY_POWER: damit der Notstromtest startet? true start und false beenden? Ich implementiere das dann gleich in mein Script und teste alles zusammen.

@git-kick
Copy link
Owner Author

Ich habe bei START_EMERGENCY_POWER_TEST false eingegeben, dann ging die Anlage in den Inselmodus.

Mehr weiß ich nicht, ich kenne auch keine Dokumentation.

@smartboart
Copy link

oh ok...dann muss ich testen. hätte es eher anders herum erwartet. Wie bist du wieder raus aus dem Inselbetrieb?

@git-kick
Copy link
Owner Author

Naja, mein Netzwerk war ja noch unten, deshalb habe ich an der Anlage manuell den Inselmodus beendet.

@smartboart
Copy link

ok, wird bestimmt Wochenende bis ich dazu komme. Meine IT hängt an ner DC UPS.
Alle anderen Hosts fahre ich vor dem Test bzw, wenn ich den Test über vis einleite mit nem Script runter. Quasi ein button für Notstromtest einleiten und beenden... Mal sehen wies wird...Danke schon mal.. Ich melde mich.

@smartboart
Copy link

smartboart commented Oct 19, 2023

Also habe das Update mal installiert . Die states werden angelegt. Mir ist aber aufgefallen, dass mit der Version im Minutentakt zwischen Batterieentladung und Netzbezug hin und her geschaltet wird.
Hast du das auch bemerkt?

grafik

grafik

@smartboart
Copy link

smartboart commented Oct 19, 2023

Hier nen Debug log dazu.

2023-10-20 00:23:23.328 - info: e3dc-rscp.0 (11411) Connection to E3/DC is established
2023-10-20 00:23:23.329 - debug: e3dc-rscp.0 (11411) Sending request TAG_EMS_REQ_GET_POWER_SETTINGS
2023-10-20 00:23:23.403 - debug: e3dc-rscp.0 (11411) Sending request TAG_EP_REQ_IS_READY_FOR_SWITCH
2023-10-20 00:23:23.608 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:23.679 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:23.717 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:23.765 - info: e3dc-rscp.0 (11411) Device reports that PVI.REQ_VOLTAGE_MONITORING is not available - setting polling interval to 'N'
2023-10-20 00:23:23.766 - info: e3dc-rscp.0 (11411) Device reports that PVI.REQ_FREQUENCY_UNDER_OVER is not available - setting polling interval to 'N'
2023-10-20 00:23:23.769 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:23.822 - info: e3dc-rscp.0 (11411) Adjusted PVI max. index to 0
2023-10-20 00:23:23.823 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:23.866 - debug: e3dc-rscp.0 (11411) Sending request TAG_SYS_REQ_IS_SYSTEM_REBOOTING
2023-10-20 00:23:23.916 - debug: e3dc-rscp.0 (11411) Sending request TAG_INFO_REQ_SERIAL_NUMBER
2023-10-20 00:23:23.947 - debug: e3dc-rscp.0 (11411) state e3dc-rscp.0.EMS.MANUAL_CHARGE_ENERGY changed: 0 (ack = true)
2023-10-20 00:23:23.976 - debug: e3dc-rscp.0 (11411) state e3dc-rscp.0.RSCP.AUTHENTICATION changed: 10 (ack = true)
2023-10-20 00:23:24.305 - debug: e3dc-rscp.0 (11411) Sending request TAG_WB_REQ_CONNECTED_DEVICES
2023-10-20 00:23:24.332 - warn: e3dc-rscp.0 (11411) Received data type ERROR: RSCP_ERR_NOT_HANDLED (1) - tag TAG_WB_CONNECTED_DEVICES (0xe84101c)
2023-10-20 00:23:25.273 - warn: e3dc-rscp.0 (11411) TAG_EMS_REQ_WB_DISCHARGE_BAT_UNTIL has no assigned polling interval - assuming 'M' - please check io-package.json
2023-10-20 00:23:25.273 - warn: e3dc-rscp.0 (11411) TAG_EMS_REQ_WB_ENFORCE_POWER_ASSIGNMENT has no assigned polling interval - assuming 'M' - please check io-package.json
2023-10-20 00:23:25.274 - warn: e3dc-rscp.0 (11411) TAG_EMS_REQ_EMERGENCY_POWER_TEST_STATUS has no assigned polling interval - assuming 'M' - please check io-package.json
2023-10-20 00:23:25.275 - warn: e3dc-rscp.0 (11411) TAG_EMS_REQ_EMERGENCY_POWER_OVERLOAD_STATUS has no assigned polling interval - assuming 'M' - please check io-package.json
2023-10-20 00:23:25.275 - warn: e3dc-rscp.0 (11411) TAG_EMS_REQ_EMERGENCY_POWER_RETRY has no assigned polling interval - assuming 'M' - please check io-package.json
2023-10-20 00:23:25.293 - debug: e3dc-rscp.0 (11411) Sending request TAG_EMS_REQ_POWER_PV
2023-10-20 00:23:25.311 - debug: e3dc-rscp.0 (11411) Sending request TAG_EP_REQ_IS_READY_FOR_SWITCH
2023-10-20 00:23:25.322 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:25.337 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:25.350 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:25.375 - debug: e3dc-rscp.0 (11411) Sending request TAG_INFO_REQ_TIME
2023-10-20 00:23:27.284 - debug: e3dc-rscp.0 (11411) Sending request TAG_EMS_REQ_POWER_PV
2023-10-20 00:23:27.297 - debug: e3dc-rscp.0 (11411) Sending request TAG_EP_REQ_IS_READY_FOR_SWITCH
2023-10-20 00:23:27.310 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:27.320 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:27.334 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:27.353 - debug: e3dc-rscp.0 (11411) Sending request TAG_INFO_REQ_TIME
2023-10-20 00:23:29.295 - debug: e3dc-rscp.0 (11411) Sending request TAG_EMS_REQ_POWER_PV
2023-10-20 00:23:29.309 - debug: e3dc-rscp.0 (11411) Sending request TAG_EP_REQ_IS_READY_FOR_SWITCH
2023-10-20 00:23:29.322 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:29.332 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:29.347 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:29.400 - debug: e3dc-rscp.0 (11411) Sending request TAG_INFO_REQ_TIME
2023-10-20 00:23:30.281 - debug: e3dc-rscp.0 (11411) Sending request TAG_EMS_REQ_GET_POWER_SETTINGS
2023-10-20 00:23:30.352 - debug: e3dc-rscp.0 (11411) Sending request TAG_EP_REQ_IS_READY_FOR_SWITCH
2023-10-20 00:23:30.377 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:30.408 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:30.486 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:30.590 - debug: e3dc-rscp.0 (11411) Sending request TAG_SYS_REQ_IS_SYSTEM_REBOOTING
2023-10-20 00:23:30.634 - debug: e3dc-rscp.0 (11411) Sending request TAG_INFO_REQ_SERIAL_NUMBER
2023-10-20 00:23:30.744 - debug: e3dc-rscp.0 (11411) state e3dc-rscp.0.EMS.MANUAL_CHARGE_ENERGY changed: 0 (ack = true)
2023-10-20 00:23:31.046 - debug: e3dc-rscp.0 (11411) Sending request TAG_WB_REQ_CONNECTED_DEVICES
2023-10-20 00:23:31.075 - warn: e3dc-rscp.0 (11411) Received data type ERROR: RSCP_ERR_NOT_HANDLED (1) - tag TAG_WB_CONNECTED_DEVICES (0xe84101c)
2023-10-20 00:23:31.286 - debug: e3dc-rscp.0 (11411) Sending request TAG_EMS_REQ_POWER_PV
2023-10-20 00:23:31.317 - debug: e3dc-rscp.0 (11411) Sending request TAG_EP_REQ_IS_READY_FOR_SWITCH
2023-10-20 00:23:31.329 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:31.349 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:31.367 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:31.404 - debug: e3dc-rscp.0 (11411) Sending request TAG_INFO_REQ_TIME
2023-10-20 00:23:33.286 - debug: e3dc-rscp.0 (11411) Sending request TAG_EMS_REQ_POWER_PV
2023-10-20 00:23:33.298 - debug: e3dc-rscp.0 (11411) Sending request TAG_EP_REQ_IS_READY_FOR_SWITCH
2023-10-20 00:23:33.307 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:33.313 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:33.323 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:33.342 - debug: e3dc-rscp.0 (11411) Sending request TAG_INFO_REQ_TIME
2023-10-20 00:23:35.288 - debug: e3dc-rscp.0 (11411) Sending request TAG_EMS_REQ_POWER_PV
2023-10-20 00:23:35.299 - debug: e3dc-rscp.0 (11411) Sending request TAG_EP_REQ_IS_READY_FOR_SWITCH
2023-10-20 00:23:35.309 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:35.321 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:35.335 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:35.357 - debug: e3dc-rscp.0 (11411) Sending request TAG_INFO_REQ_TIME
2023-10-20 00:23:37.287 - debug: e3dc-rscp.0 (11411) Sending request TAG_EMS_REQ_GET_POWER_SETTINGS
2023-10-20 00:23:37.304 - debug: e3dc-rscp.0 (11411) Sending request TAG_EP_REQ_IS_READY_FOR_SWITCH
2023-10-20 00:23:37.355 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:37.418 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:37.486 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:37.544 - debug: e3dc-rscp.0 (11411) Sending request TAG_SYS_REQ_IS_SYSTEM_REBOOTING
2023-10-20 00:23:37.561 - debug: e3dc-rscp.0 (11411) Sending request TAG_INFO_REQ_SERIAL_NUMBER
2023-10-20 00:23:37.622 - debug: e3dc-rscp.0 (11411) state e3dc-rscp.0.EMS.MANUAL_CHARGE_ENERGY changed: 0 (ack = true)
2023-10-20 00:23:37.846 - debug: e3dc-rscp.0 (11411) Sending request TAG_WB_REQ_CONNECTED_DEVICES
2023-10-20 00:23:37.863 - warn: e3dc-rscp.0 (11411) Received data type ERROR: RSCP_ERR_NOT_HANDLED (1) - tag TAG_WB_CONNECTED_DEVICES (0xe84101c)
2023-10-20 00:23:37.864 - debug: e3dc-rscp.0 (11411) Sending request TAG_EMS_REQ_POWER_PV
2023-10-20 00:23:37.877 - debug: e3dc-rscp.0 (11411) Sending request TAG_EP_REQ_IS_READY_FOR_SWITCH
2023-10-20 00:23:37.894 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:37.918 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:37.950 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:37.972 - debug: e3dc-rscp.0 (11411) Sending request TAG_INFO_REQ_TIME
2023-10-20 00:23:39.305 - debug: e3dc-rscp.0 (11411) Sending request TAG_EMS_REQ_POWER_PV
2023-10-20 00:23:39.318 - debug: e3dc-rscp.0 (11411) Sending request TAG_EP_REQ_IS_READY_FOR_SWITCH
2023-10-20 00:23:39.329 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:39.340 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:39.352 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:39.375 - debug: e3dc-rscp.0 (11411) Sending request TAG_INFO_REQ_TIME
2023-10-20 00:23:41.309 - debug: e3dc-rscp.0 (11411) Sending request TAG_EMS_REQ_POWER_PV
2023-10-20 00:23:41.322 - debug: e3dc-rscp.0 (11411) Sending request TAG_EP_REQ_IS_READY_FOR_SWITCH
2023-10-20 00:23:41.332 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:41.341 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:41.350 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:41.371 - debug: e3dc-rscp.0 (11411) Sending request TAG_INFO_REQ_TIME
2023-10-20 00:23:43.318 - debug: e3dc-rscp.0 (11411) Sending request TAG_EMS_REQ_POWER_PV
2023-10-20 00:23:43.340 - debug: e3dc-rscp.0 (11411) Sending request TAG_EP_REQ_IS_READY_FOR_SWITCH
2023-10-20 00:23:43.351 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:43.361 - debug: e3dc-rscp.0 (11411) Sending request TAG_BAT_REQ_DATA
2023-10-20 00:23:43.372 - debug: e3dc-rscp.0 (11411) Sending request TAG_PVI_REQ_DATA
2023-10-20 00:23:43.397 - debug: e3dc-rscp.0 (11411) Sending request TAG_INFO_REQ_TIME
2023-10-20 00:23:43.549 - info: host.ioBroker-Master "system.adapter.e3dc-rscp.0" disabled

@git-kick
Copy link
Owner Author

git-kick commented Oct 20, 2023

@smartboart danke fürs Testen. Das wiederholte Hin- und Herschalten habe ich nicht beobachtet. Kann es sein, dass ein Skript oder eine andere Software bei Dir Objektwerte ändert?

Im Debug-Log sehe ich folgendes:

  • Received data type ERROR: RSCP_ERR_NOT_HANDLED - ich nehme an Du hast keine E3/DC Wallbox; wenn du den WB-Namespace in den Adaptereinstellungen ausschaltest verschwinden diese Meldungen.
  • TAG_EMS_REQ_WB_DISCHARGE_BAT_UNTIL has no assigned polling interval - offenbar hast du bei der v1.2.4-Installation keine neue Adapterkonfiguration angelegt - hier steht warum das gut wäre.
  • state e3dc-rscp.0.EMS.MANUAL_CHARGE_ENERGY changed: 0 (ack = true)
    • um 00:23:23.947 auf 0
    • um 00:23:30.744 auf 0
    • um 00:23:37.622 auf 0

Die letzten drei Ereignisse dürften von der Adapterinitialisierung herrühren: der Adapter sendet einige Anfragen an die E3/DC und da könnten auch mehrere EMS.MANUAL_CHARGE_ACTIVE=false Antworten daraus resultieren, die jeweils den Wert des Objekts EMS.MANUAL_CHARGE_ENERGY auf 0 setzen.

Allerdings sehe ich keine einzige Meldung Sending request TAG_EMS_REQ_START_MANUAL_CHARGE - das wäre das Tag zum Starten des Ladevorgangs. Die müsste eigentlich kommen, wenn man den Wert von EMS.MANUAL_CHARGE_ENERGY ändert.

Kannst du bitte die Grafik noch etwas erklären? Ich sehe nur, dass die Batterie offenbar hin und wieder etwas Leistung abgibt (oder aufnimmt); aber was sagt das über unsere Fragestellung aus?

@git-kick
Copy link
Owner Author

Hier noch ein Beispiel zur Illustration:
grafik

Ich habe um 12:19 in das Objekt EMS.MANUAL_CHARGE_ENERGY den Wert 100 [Wh] eingetragen.
Man sieht, dass daraufhin die Ladeleistung auf 2 kW ansteigt, unter Nutzung von Grid-Strom.
Nach etwa 3 Minuten (2 kW * 180 sec sind 100 Wh) sinkt die Ladeleistung wieder ab (nicht auf 0, weil meine PV zunehmend Sonne hat).

Das ist eigentlich genau das, was ich vom manuellen Laden erwartet hätte.

@smartboart
Copy link

smartboart commented Oct 20, 2023

Hi ,
danke für die Antworten.
Nein alle externe Eingriffe welche auf den RSCP Adapter wirken z.B das Script von ArnoD hatte ich deaktiviert. Auch das System neugestartet.
Habe mehrmals hin und her probiert. Also neuen Adapter gestartet, sofort hin und her schalten zwischen Batterie und Netzbezug.
offizielle Version installiert und gestartet keine Reaktion nur Batteriebezug. Dann wieder neu installiert und wieder hin und her schalten. Externe Eingriffe waren dabei immer aus.

Und ja ich habe aus Faulheit die Konfig über das json file geladen.
Danke für den Hinweis. Könnte das der Grund sein für das Verhalten?

Ja ich habe eine Wallbox von E3DC aber ich habe sie nicht über die S10EPro eingebunden. Das erklärt das schonmal.

Da ich den Test Nachts gemacht habe wurde nicht geladen. Ich hätte nur das Entladen erwartet ohne Netzbezug. Die Grafik von mir sollte das nur verdeutlichen. Also das hin und her springen zwischen Netz und Batterie bzw. Batterileistung - also Batterie Bezug und 0 kein Batteriebezug also Netzbezug.

@git-kick
Copy link
Owner Author

@smartboart, woran genau machst du den unerwünschten Effekt fest? Eine kurzzeitige Last mal auf der Batterie, mal auf dem Grid ist bei mir ganz normal, z.B. wenn ein Gerät sich ein- oder ausschaltet. Aus den Daten kann ich kein unnormales Verhalten ableiten und im Debug-log kann ich nicht sehen, dass der Adapter überhaupt irgendeinen Steuerbefehl an deine E3/DC gesendet hat - also auch keinen Start einer manuellen Ladung. Insofern kann ich nach dem jetzigen Datenstand nichts auf den Adapter zurückführen, sorry.

Ich würde sogar behaupten, dass der Adapter mit Effekten, die du in den 20 Sekunden (Debug-log) beobachtet hast, nichts zu tun hat - denn er hat nur Werte ausgelesen, was nach meinen bisherigen Erkenntnissen das Verhalten der E3/DC nicht beeinflusst.

Wenn du überzeugt bis, dass der Adapter (in der Version Issue#57ep) zu einem unerwünschten Verhalten führt, brauche ich ein Debug-Log mit den verdächtigen Steuerbefehlen - der Adapter schreibt für jeden gesendeten Frame einen "Sending request..." Eintrag ins Log. Da bin ich so sicher, weil es im gesamten Adapter nur einen einzigen tcpConnection.write() Befehl gibt, nämlich in der Funktion sendFrame().

Die Konfiguration aus dem json-log kann eigentlich nicht der Grund sein: die führt nur zu den Meldungen und dazu, dass ein paar Tags (die neu eingeführten) alle auf polling interval 'M' gesetzt werden. Also das kann m.E. nicht zu solchen Effekten führen.

Also ich hab momentan keine weitere Idee, was da los sein könnte ...

@smartboart
Copy link

smartboart commented Oct 20, 2023

Ok. Werde nochmal hochruesten und schauen ob der effekt noch auftritt. Es war nicht das beschriebene verhalten von dir...es gab auch kein lastwechsel...1minute bat 500 watt dann eine minute netz 500 watt usw. Das war kein normales verhalten..es war sofort vorbei wenn der adapter angehalten wurde.. und ging beim start direkt wieder los..
Nach dem downgrade war auch wieder ruhe.
Mal gespannt ob andere das auch beobachten..

@git-kick
Copy link
Owner Author

Ja, schönes Rätsel - bin gespannt, ob wir das noch gelöst bekommen.
Ist eigentlich ein Showstopper für v1.2.4, wenn das noch jemand berichtet.
Danke fürs Dranbleiben!

@git-kick
Copy link
Owner Author

Nur nochmal zum Vergleich: um 18:42 habe ich den Adapter (Issue#57ep) gestartet und laufen lassen - da passiert in meiner Anlage rein gar nichts.
grafik
(Um 18:39-18:40 sieht man so "normale Schwankungen", die ich erwähnt habe.)

@git-kick
Copy link
Owner Author

Es ist eine Woche still geblieben, deshalb kommt der Code mit v1.2.4 (aber "stable" erst nach einer weiteren Testphase).

Der Übersicht wegen schließe ich Issue #57 - für weitere Tags bitte ein neues Issue anlegen.

@smartboart
Copy link

Hallo, kann es sein, dass der setter Tag SET_EMERGENCY_POWER nicht mit aufgenommen wurde?

@git-kick
Copy link
Owner Author

EMS.EMERGENCY_POWER sollte read/write sein, steht auch so im README.md

Repository owner locked as resolved and limited conversation to collaborators Nov 19, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants