ThomasH

Volltreffer und versenkt. Danke Dir. Ich bin davon ausgegangen dass der Default tatsächlich "true" ist (laut Doku von EVCC wird hier nämlich kein Wert gesetzt). Zum Test habe ich jetzt "true" eingetragen und schon geht es ;)

Ich habe in der Zwischenzeit im Thread für die Beta-Firmware folgendes gefunden: Ich nehme mal an dass es daran liegt.

Hallo Thomas, sieht gut aus bzw. sollte passen: chargers: - name: warp # Konfigurationsname der Wallbox type: template template: tinkerforge-warp fw2: host: 192.168.30.10 port: 1883 topic: warp/U7X # Der Topic-Präfix # timeout: 30s Gruß, Thomas

Hallo zusammen, ich habe meine Warp 1 heute von V2.0.1 auf V2.0.5 aktualisiert und seit dem meckert EVCC dass es keine Updates bekommt: "warp/U7X/evse/state outdated". Ich kann im MQTT Explorer nachvollziehen dass das Topic "warp/U7X/evse/state" keine automatische Aktualisierung mehr bekommt (zumindest momentan ohne angeschlosseses Auto). Der Topic "warp/U7X/evse/low_level_state" wird allerdings aktualisiert. Meine Frage: Gab es hier einen change bezüglich der Aktualisierung des Topics "warp/U7X/evse/state"? Wenn ja, wäre es super wenn entweder wieder alle paar Sekunden ein update gesendet würde ODER eine Aussage kommt das nicht nicht mehr passieren würde (dann müsste ich wohl bei EVCC ein Issue öffnen). Danke und Gruß, Thomas

Ich würde Dir dazu raten die Steuerung der Überschussladung per EVCC zu machen. EVCC muss alle Werte der einzelnen Komponenten kennen und kann dann den Ladestrom zwischen zum Beispiel 6A und 16A steuern. Funktioniert bei mir einwandfrei. Es gibt auch eine kurze Anleitung hier.

Test erfolgreich, mit den kalibrierten Werten startet die Ladung ab 6A! Top. Was bedeutet das jetzt für die Zukunft? Kann ich die Werte gefahrlos so lassen? Bleiben die bei Firmwareupdate bestehen? Danke für die Hilfe ;-)

Ist gemacht. Ich werde leider erst heute Abend testen können wenn das Auto wieder da ist.

Hallo zusammen, ich habe heute einen Test gemacht und habe ein Downgrade von der V1.2.90-60f6c347 zur V1.2.4-60f17413 durchgeführt um zu testen ob ich den ID.4 einphasig mit 6A laden kann. Das Fehlerbild ist exakt gleich wie bei V1.2.9x, ich kann den Ladevorgang erst ab 11A starten. Ich habe ein Ladelog hier angefügt. evse-debug-log-2021-10-06T14-19-49-578Z.txt

Hallo zusammen, ich habe hier noch eine Frage: Ich nutze im moment die Last-Management Beta da MQTT sonst nicht gut funktioniert hat (bekanntes Problem mit Web Server). Habe ich es jetzt richtig verstanden dass die Verbesserungen beim Ladecontroller in der 1.2.4 eigentlich schon drin wären (zumindest für die VW ID)? Wird es dann so sein dass mit 1.2.5 sowohl der neue Web Server als auch die Verbesserung beim Ladecontroller inkludiert wären? Danke, Thomas

Hallo zusammen, nur als kurzes Feedback, mit V1.2.90-60f6c347 ist MQTT wesentlich stabiler! Es kommt 1-2x am Tag vor dass er zwei oder drei Updates verschluckt, das ist (zumindest bei mir) nicht weiter schlimm. Gruss, Thomas

Hallo zusammen, ich wollte noch mitgeben dass ich das gleiche Problem bei meinem ID.4 an der Warp zu haben scheine (3-Phasig). Einwandfreies und unterbrechungsfreies Laden startet hier tatsächlich erst ab 11A ;-( Firmware ist V1.2.90-60f6c347 (mit der 1.2.3 hat MQTT per Wifi Probleme gemacht).

Moin, das werde ich gerne machen. Ich habe gestern mit MQTT Explorer weiter debugged und für mich sieht es auch so aus als würde die WARP zu bestimmten Zeiten einfach keine updates senden, was dann ja für ein Problem mit einem der laufenden Prozesse sprechen würde. Ich werde das Login deaktivieren, das Update einspielen und dann weiter beobachten. Danke Dir.

Hallo zusammen, meine WARP 1 verliert mehrmals am Tag Ihre MQTT-Kommunikation und ich brauche Hilfe bei der weiteren Fehlersuche. IST-Stand: WARP-1 Smart mit FW: V1.2.4-60f17413 und MQTT konfiguriert Raspi mit Mosquitto MQTT Broker der mit zig anderen Komponenten seit Jahren zuverlässig funktioniert UniFi U6 Lite Wifi Bisherige Erkentnisse: Auf der WARP sehe ich: 55987456 Disconnected from MQTT: TCP_DISCONNECTED (0) 55989101 Connecting to MQTT broker 55989121 Connected to MQTT session=0 max payload size=14330 Im Mosquitto-Log sehe ich: 1631520569: Client warp-U7X has exceeded timeout, disconnecting. 1631520569: Socket error on client warp-U7X, disconnecting. 1631520572: New connection from 192.168.28.30 on port 1883.1631520572: New client connected from 192.168.28.30 as warp-U7X (c1, k30). Diskussion: Mein erster Verdacht viel natürlich aufs WLAN, das UniFi Dashboard zeigt allerdings eine Wifi-Experience von 100%, die Signalstärke ist mit -76db vollkommen ausreichend, Paketverluste sind sehr gering (2%, für WLAN einandfrei). Dazu kommt die Tatsache dass MQTT über TCP ja eigentlich extrem robust ist was einzelne Aussetzer angehen würde. Für mich sieht es so aus, als würde die WARP keine Updates senden, der Broker erkennt sie dann als stale und beendet die Verbindung. Im Fehlerfall hatte ich auch schon auf den Broker gelauscht und habe keine MQTT-Messages gesehen. Meine Frage wäre jetzt, was kann ich auf der WARP tun, um den Fehler evtl. weiter einzugrenzen bzw. zu prüfen ob der MQTT-Prozess ok ist und ob die WARP die Pakete im Fehlerfall wirklich nicht sendet? Danke für eure Hilfe! Thomas