-
-
Notifications
You must be signed in to change notification settings - Fork 4
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
binary_sensor.senec_wallbox_1_smart_charge_active reset after about 3 minutes #72
Comments
First of all thank you very much for your feedback... When I understood you correctly: In HA you switch the "Wallbox mode" from OFF to OPTIMIZED... this implies that the smart_charge_active sensor will set to ON... After a short while the HA display witch back to MODE: OFF and smart_charge_active OFF ? If this is the case, then it looks like, that the required SYNC via the WEB-API does not work - can you please enable the DEBUG-Log for the integration and restart HA and then share the output of the LOG? |
and just to repeat - you must have configured the additional WebAPI-Integration to use the new Wallbox feature |
WebAPI-Integration is integrated indeed. Energy Dashboard is working correctly. I try to publish the log after it is generated |
Hallo Matthias,
das habe ich on der LOG gefunden:
2024-01-21 17:28:42.323 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/mnt/dietpi_userdata/homeassistant/custom_components/senec/pysenec_ha/__init__.py", line 2928, in update
await self.authenticate(do_update=True, throw401=False)
File "/mnt/dietpi_userdata/homeassistant/custom_components/senec/pysenec_ha/__init__.py", line 2878, in authenticate
async with self.web_session.post(self._SENEC_WEB_AUTH, data=auth_payload, max_redirects=20, ssl=False) as res:
File "/home/homeassistant/.pyenv/versions/3.11.5/lib/python3.11/site-packages/aiohttp/client.py", line 1187, in __aenter__
self._resp = await self._coro
^^^^^^^^^^^^^^^^
File "/home/homeassistant/.pyenv/versions/3.11.5/lib/python3.11/site-packages/aiohttp/client.py", line 629, in _request
raise TooManyRedirects(
aiohttp.client_exceptions.TooManyRedirects: 0, message='', url=URL('https://mein-senec.de/auth/login')
Ich denke, das geht in die Richtung?
Werde versuchen die BETA zu installieren.
Melde mich dazu dann.
|
das sieht mir nach "kaputtem" CookieHandling aus - Du sagst, dass die WebAPI Sensoren aber Daten liefern? [sieht irgendwie für mich nicht so gut aus]... aber wie es auch sei - ein Update auf die aktuellste BETA (2024.0.3) könnte helfen... |
Hallo Matthias,
leider besteht das Problem auf die neueste Beta noch gleich. Ich kann die Wallbox in HA einstellen:
Wenn man das in der SENEC-App verfolgt, sieht man unmittelbar die Änderung.
Nach 1-2 Minuten sieht es in HA dann wieder so aus:
Das Ergebnis in der SENEC-App ist aber dasselbe. D.h. dort bleibt alles eingestellt, wie es war. Das LOGFILE hat ebenfalls noch dieselbe Meldung.
|
Leider kommt hier nichts von dem an (attachments/screenshots) die Du in eine eMail Antwort steckst... das geht nur direkt hier in GitHub... Wenn auch die aktuellste Beta version nicht wie gewünscht arbeitet, dann benötige ich leider den output, den man in dem HA-Log file findet (wenn man für die Integration den DEBUG modus aktiviert)... DEBUG Modus aktivieren - einmal den Modus von AUS auf OPTIMIERT schalten - ein - zwei Minuten warten und dann den DEBUG-LOG Modus wieder ausschalten - beim ausschalten (über einen Webbrowser), wird dann auch gleich das LOG file vom Backend mit ausgeliefert... "das" würde ich gerne haben... |
Hallo Matthias,
die Fehlermeldungen aus der Log mit dem Zertifikat traten seltsamerweise nun nicht mehr auf. Es geht nun auch länger, bis sich in HA der Smart-Charge-Status der „zurücksetzt“ (wie gesagt, in der SENEC-App bleibt trotzdem alles unverändert). Ich habe nun die DEBUG-Meldungen aus der Log gefiltert und als Datei angehängt. Vielleicht bringt das etwas mehr Erkenntnis?
LG
|
wenn Du das File direkt 'hier' (#72) GitHub postet - und nicht als eMail Antwort sendest, dann erreicht mich das log file vielleicht auch ;-) |
[FILE-REMOVED-BY-MARQ24-I-HAVE-IT] OK, hier das Logfile. Ich deaktivierte die Wallbox, startete dann die debug-Protokollierung, stellte dann die Wallbox auf "Optimiert" und wartete ca. 3 Minuten, bis HA den Schalter "binary_sensor.senec_wallbox_1_smart_charge_active" wieder zurückgesetzt hatte. Wie bereits erwähnt: die Wallbox bleibt korrekt eingestellt, was auch in der SENEC-App nachvollziehbar ist. Lediglich HA zeigt den Staus dann nicht mehr korrekt an. ich weiß auch nicht, ob es vorgesehen ist, dass der Schalter "select.senec_wallbox_1_mode" dauerhaft den eingestellten Wallbox-Modus anzeigen soll. Dort wird spätestens nach Verlassen und zurückkehren auf die Seite mit der SENEC-Erweiterung nichts angezeigt. |
Danke für das LOG! - Ich verstehe zwar immer noch nicht was bei Dir da genau passiert - aber Dein HA Installation läuft m.E. alles andere als Rund... hier ein paar Einträge, um die Du dich m.E. kümmern solltest/müsstest
Vermutlich ist das "alles" diese 'audiconnect' Erweiterung... Hier mal zusammengedampft was bei Dir passiert...
Zwei Dinge die mich wundern:
Also eigentlich steht ICMAX auf 32A - und wenn auf OPTIMIZED umgestellt wird, müsste ICMAX wieder auf 6 gestellt werden... aber "irgendwas" läuft da nicht gerade aus - die Integration meint, der Wert steht schon auf 6 ?! |
Genau so ist es aber auch. Stelle ich aus "Schnell", dann steht ICMAX auf 31A, bei "Optimiert" auf 6A. |
Hallo Matthias,
ich habe den thread wohl aus Versehen geschlossen ☹ Wollte noch etwas bemerken: Die Einstellung von HA bzgl. Lademodus von SENEC wird direkt im Senec-Speicher lokal geändert und parallel über das Web-Api auch bei Senec so hinterlegt. Dieser Status wird nach 300 Sek. Bei Senec neu abgefragt und nicht oder falsch beantwortet. Ich habe das daran gemerkt, dass ich den optimierten Lademodus direkt in der Senec-App umgestellt habe. Dann bekommt HA den Status ohnehin nur vom Senec-Server. Das „binary_sensor.senec_wallbox_1_smart_charge_active“ bleibt von vorneherein „off“.
LG
Ulrich Otto
|
Also Du sagt, wenn Du den Status über die SenecAPP änderst, dann wird der Status in HA nach einer gewissen Zeit (Backend-Synchronisation) auch korrekt übernommen & angezeigt [das ist ja die "default" Funktionalität]... Wenn Du die Änderung, über die HA-Integration vornimmst, dann werden [im lokalen Speicher und über die App-API] die Werte "korrekt" in der SenecApp als auch im Speicher angezeigt [das ist eben die "neue" Funktionalität - und in den LOGs die Du bereitgestellt hast, sieht es eigentlich so aus, als wäre alles soweit korrekt]... Allerdings (auch wenn SenecApp und HA sauber aussehen) gerät nach der "Default Synchronisation" zwischen Backend und Speicher irgendwas in Schieflage ?! So habe ich Dich jetzt zumindest verstanden? |
Ich möchte das Problem nochmals ganz genau definieren: Egal ob ich die Ladeart der Wallbox über HA oder über die SENEC-App einstelle. Die Einstellung erfolgt immer korrekt und bleibt auch so. Einzig der Status der Entität "binary_sensor.senec_wallbox_1_smart_charge_active" spätestens nach ca. 3 Minuten stimmt nicht (mehr). Ausgangssituation: Wallbox ist aus. Szenario 1: Lademodus wird in HA auf "Optimiert" eingestellt. Dann geht "binary.sensor.senec_wallbox_1_prohibit_usage" von on auf off (korrekt!), der "binary_sensor.senec_wallbox_1_smart_charge_active" (korrekt!) auf on. Nach ca. 3 Minuten aber wieder auf off (ohne dass sich der Lademodus aber ändert). Szenario 2: Lademodus wird in der SENEC-App auf "Optimiert" eingestellt. Dann dauert es ca. 3 Minuten, bis der Lademodus aktiv ist. "binary.sensor.senec_wallbox_1_prohibit_usage" geht dann von on auf off, "binary_sensor.senec_wallbox_1_smart_charge_active" bleibt aber unverändert auf off. Es ist also nicht mehr nachvollziehbar, ob dann aktuell der optimierte oder schnelle Lademodus aktiv ist. Nur dass ein Lademodus aktiv ist da "binary.sensor.senec_wallbox_1_prohibit_usage" korrekt eingestellt wird. Meine Schlussfolgerung: Alles funktioniert korrekt, außer die Statusabfrage der Art des Lademodus über das SENEC-Web-API |
kannst Du bitte nach den 3 min einmal auf Deinem Speicher lokal gucken (via https://[LOCAL-IP-HERE]//vars.html ), worauf dann der Wert SMART_CHARGE_ACTIVE steht?! (offensichtlich wechselt das vom Wert '3' auf etwas anderes ?! die // vor dem vars.html sind wichtig... |
Der Wert wird bei Einstellung in HA sofort auf 03 gesetzt und wechselt dann nach ca. 3 Minuten auf den Wert 04.
Wenn über die SENEC-App eingestellt wird, ist der Wert von Anfang an 04
|
danke für das schnelle feedback... "jetzt" müsste man nur noch jemanden bei SENEC finden, der einem erklären kann, bei welchen Wallboxen der 'SMART_CHARGE_ACTIVE' auf 3 und bei welchen auf 4 gestellt wird... -> das eigentliche von Dir reportete Problem kann ich aber wohl mit dieser Info fixen... [neue (Beta) Version kommt] |
Ich habe dir die Ergebnisse der Tests geschickt. Zusammenfassung: "Ladeunterbrechung verhindern" an = 3 aus = 4 |
Ich habe die neue BETA gestern Abend noch aufgespielt. Sieht jetzt gut aus! Ich denke, das von mir geschilderte Problem ist damit gelöst. Vielen lieben Dank Matthias! |
Hallo schalte mal in der App die Ladeunterbrechung aus. Dann übermittelt die App leider nicht nur diesen Status, sondern auch den dort hinterlegten min. Ladestrom an deine Senec Anlage. |
Das neue Release 2024.0.7 bietet jetzt zwei "Optimierungs-Modi" an - mit und ohne 'Ladeunterbrechung' |
Wow. Super! Das ging fix und funktioniert auf den ersten Blick einwandfrei. Auch die Skala des min. Ladestroms ist jetzt von 6 auf 32A begrenzt. Herzlichen Dank für die gute Anpassung!
|
also - solved - affe tot - issue zu ;-) |
Whenever I activate the smart charge mode for my SENEC- wallbox, the entity "binary_sensor.senec_wallbox_1_smart_charge_active" will be set to "on" for only a short time and then reset to "off" though the smart charge mode ist still avtive. After that, it is not possible in HA to determine, which charge mode (quick or smart) ist active, because the pop-up menu of "select.senec_wallbox_1_mode" is also reset.
The text was updated successfully, but these errors were encountered: