-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
Hallo Uli, an drei Tags würde Interesse bestehen.
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. |
Hallo, ich schliesse mich hier an. |
Okay, ich danke euch für den Input und sehe mir das bei nächster Gelegenheit an. D.h. START_ADJUST_BATTERY_VOLTAGE bearbeite ich nicht (UserLevel: INSTALLER) - die anderen drei sind User-tags. |
Es gibt eine erste Implementierung: Issue#57ep OVERRIDE_AVAILABLE_POWER: sollte funktionieren. Mangels E3/DC-Wallbox kann ich allerdings die Wirkung nicht bestätigen. Da die Antwort ein EMERGENCY_POWER: auch hier funktioniert das Setzen des Modus grundsätzlich und die Antwort ist ein START_EMERGENCY_POWER_TEST: Wenn man hier einen (beliebigen?) Ich bitte euch zu testen und hier Rückmeldung zu geben. Release der drei setter Tags ist geplant mit v1.2.4 |
Hi, danke für die Umsetzung. |
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. |
oh ok...dann muss ich testen. hätte es eher anders herum erwartet. Wie bist du wieder raus aus dem Inselbetrieb? |
Naja, mein Netzwerk war ja noch unten, deshalb habe ich an der Anlage manuell den Inselmodus beendet. |
ok, wird bestimmt Wochenende bis ich dazu komme. Meine IT hängt an ner DC UPS. |
Hier nen Debug log dazu. 2023-10-20 00:23:23.328 - info: e3dc-rscp.0 (11411) Connection to E3/DC is established |
@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:
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 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? |
Hi , Und ja ich habe aus Faulheit die Konfig über das json file geladen. 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. |
@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 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 ... |
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.. |
Ja, schönes Rätsel - bin gespannt, ob wir das noch gelöst bekommen. |
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. |
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. |
Hallo, kann es sein, dass der setter Tag SET_EMERGENCY_POWER nicht mit aufgenommen wurde? |
EMS.EMERGENCY_POWER sollte read/write sein, steht auch so im README.md |
EMS namespace is only partially supported so far. There are several setter tags which should be supported, like
There is no direct request for one of these. If so, prioritization is done on demand.
The text was updated successfully, but these errors were encountered: