MatzeTF

Bisher leider nicht.

Dann brauchen wir bei Gelegenheit mal einen entsprechenden Teil deiner Aufzeichnungen und einen Debug-Report, der Logeinträge aus dem gleichen Zeitraum enthält. Aktuell sind uns keine generellen Probleme mit PV-Überschussladen bekannt, die dazu führen könnten, dass einfach weitergeladen wird. Es kommt nur manchmal vor, dass Nutzer versehentlich auf Min+PV schalten, was absichtlich dazu führt, dass weitergeladen wird.

Anhand der Logmeldungen sieht es für mich so aus, als würden aktuell noch weitere Daten ankommen. Die Lesefehler waren anscheinend nur temporär. Ein Ladevorgang wird nicht sofort gestoppt, wenn die Sonne hinter Wolken verschwindet. Es könnte schließlich auch eine kleine, vorbeiziehende Wolke sein. Ständig die Ladung zu starten und zu stoppen schadet der Ladeelektronik des Autos, weshalb die Wallbox einen Ladevorgang erst stoppt, wenn die PV-Leistung fünf Minuten am Stück nicht ausreicht. Wenn bei aufziehender Bewölkung die Sonne noch manchmal kurz zwischen den Wolken durchscheint, reicht das, um den Ladevorgang aufrecht zu erhalten. Deine Annahme zur Ladefreigabe mit NFC ist korrekt, allerdings ist die NFC-Freigabe laut deinem Debug-Report gar nicht aktiviert. Schau mal auf der Seite der Benutzerverwaltung, ob die Nutzerfreigabe aktiviert ist und aktiviere sie gegebenenfalls. Logs kann man leider nicht so einfach auf einem anderen Gerät anlegen, allerdings kannst du die Webseite der Wallbox in einem Browsertab offenlassen, sodass dort das Log aufgesammelt wird. Das klappt natürlich nur, wenn das Tab weiter aktiv ist und das entsprechende Gerät nicht schlafen geht. Wahrscheinlich brauchst du dafür einen permanent aktiven PC oder Laptop. Je nach dem wie deine IT-Kenntnisse sind, kannst du auch von irgendeinem laufenden Gerät eine Websocketverbindung zu /ws aufbauen und alles in eine Datei schreiben. Unter Linux gibt es dafür z. B. websocat.

Sieht bis 7:10 gut aus, aber warum geht danach mehr in den Speicher statt ins Auto? War dein Auto schon fast voll, als du den Test gestartet hast?

Das bedeutet üblicherweise, dass evcc keinen Strom freigibt sondern den Ladevorgang blockiert. Was passiert, wenn du nicht den „Zurücksetzen“-Button verwendest, sondern stattdessen in evcc auf „Min+PV“ oder „Schnell“ wechselst?

Ja: Du hast keinen Debug-Report runtergeladen. 😉 Das nächste Mal in diesem Zustand – also Limit abgelaufen aber lädt weiter – einen Debug-Report runterladen und hier anhängen. Da steht nämlich mehr drin als im Ereignislog.

Du hast dann zwar unnötig teuer geladen, aber immerhin ist der Strom nicht weg, sondern halt im Auto. 😉

Sowas in der Richtung is angedacht, allerdings können wir aktuell nicht „mal schnell“ einen Hack bauen, da selbst der nicht trivial ist und auch ausgiebig getestet werden muss, bevor wir ihn veröffentlichen können. Wenn du ein bischen Programmieren möchtest, entweder weil das auch deine Hausautomatisierung kann oder sonst einfach in Python oder so, kannst du dir etwas basteln, was beide bekannten Leistungswerte nach deinen Vorstellungen verrechnet und das Ergebnis per API-Zähler in die Wallbox schiebt.

Die Standardgeschwindigkeit für Modbus ist 9600 Baud, was für relativ hochfrequente Abfragen oft zu langsam ist. Versuch mal wie till die Baudrate hochzustellen.

Ich wollte gerade fragen, wo im Log die halbe Stunde ist, da die Verbindung der Wallbox innerhalb weniger Millisekunden getrennt wird, aber du meinst den Zeitunterschied zwischen evcc-Trennung und Wallbox-Trennung. Wenn natürlich sowohl Wallbox als auch evcc rausfliegen und beide melden, dass die Verbindung von der anderen Seite getrennt wurde, dann sieht das sehr nach einem Broker-Problem aus.

Den Fix können wir leider aktuell noch nicht nutzen, da wir noch auf einer alten Framework-Version festhängen. Hoffentlich können wir Bald™ auf eine neuere Version umsteigen und uns das dann ansehen. Ansonsten bleibt leider noch dieses Problem, nämlich die extrem lahme AP-Performance. „Lahm“ im Sinne von „Analogmodem“. Keine Ahnung, wann da irgendein Fortschritt zu erwarten ist.

Anscheinend wirft dein MQTT-Broker die Wallbox immer wieder raus. Dadurch kann evcc natürlich auch nicht mit ihr kommunizieren. Schau mal in die Logs des Brokers und versuche herauszufinden, warum immer die Verbindung getrennt wird.

Bei NFC-Token für die Zugangskontrolle werden üblicherweise irgendwelche Daten verschlüsselt auf dem Token abgelegt, die dann von einem Lesegerät entschlüsselt werden. So kompliziert machen wir uns das aktuell nicht, sondern lesen einfach nur die Tag-ID aus. Wir entschlüsseln keine Daten vom Token. Wenn sich die Tag-ID nicht ändert hat das den Vorteil, dass man beliebige NFC-Token verwenden kann, da die Daten auf dem Token nicht geändert werden müssen. Der Nachteil ist halt, dass Token mit Zufalls-IDs nicht verwendet werden können, was anscheinend auf DESFire-Token zutrifft.

Die eID vom Personalausweis können wir aktuell nicht auslesen. Ich weiß auch nicht, ob man da einfach so drankommt. Aktuell lesen wir nur die Tag-ID aus, was mit dem Perso nicht funktioniert, da der auch zufällig generierte IDs verwendet. Wenn du einfach nur irgendwas anderes als eine NFC-Karte verwenden willst, haben wir auch NFC-Schlüsselanhänger und NFC-Aufkleber. Die Aufkleber kann man z. B. innen ins Batteriefach von Autoschlüssel oder Keycard kleben. 😉 Ansonsten kannst du mal alle möglichen andere NFC-Dinge an die Wallbox halten und schauen, ob und welche ID dann ausgelesen wird. Wird eine ID ausgelesen und jedes Mal die selbe, kannst du das Ding zum Freigeben einer Ladung nutzen. Schlüsselanhänger von Plugsurfing funktionieren beispielsweise.

Wenn du keinen Händler findest, kannst du die Hilfskontakte auch bei uns bestellen. Frag bei Interesse mal bei sales@tinkerforge an. Wir verzeihen dir dann auch, dass du die Schütze anscheinend nicht bei uns gekauft hast. 😉

I’m only getting an error when trying to view those photos, but I see no reason why the IO-4 Bricklet 2.0 shouldn’t be able to read a rotary encoder’s signals. The bricklet’s API has a function to read all four inputs at the same time, so you shouldn’t have a problem with signals changing while reading them.

Ja, der Wert muss bei Einspeisung negativ sein, damit ein Ladevorgang gestartet wird. Die meisten Stromzähler zeigen Bezug (Strom vom Energieversorger zum Kunden) mit positiven Werten an und Einspeisung (Strom vom Kunden zum Energieversorger) mit negativen Werten, was in einem allgemeinen Standard für Stromzähler auch so vorgesehen ist. Deswegen erwarten wir auch entsprechende Zählerwerte am Hausanschluss. Manchmal kommt es da allerdings zu Verwirrung, da leider manche Hersteller von Solaranlagen lieber positive Werte für Einspeisung anzeigen wollen. Vielleicht glauben sie, dass positive Werte für Einspeisung einen positiveren Eindruck hinterlassen.

Ja. Einer der Werte ist der fortlaufende Kilowattstunden-Zähler. Dokumentation zur Zähler-API findest du hier.

Ich vermute, dass sich das irgendwo zwischen „sehr ungenau“ und „unbrauchbar“ bewegen wird. Spontan fallen mir drei grundsätzliche Probleme ein: Keines der bisher von uns getesteten Fahrzeuge lädt tatsächlich mit dem Strom, den die Wallbox freigibt. Die meisten Fahrzeuge halten einen gewissen „Angstabstand“ ein. Gibt eine 22 kW-Wallbox 32 A frei, lädt ein Fahrzeug z.B. nur mit 31 A. Wäre das immer gleich, könnte man das einfach abziehen, aber einige Fahrzeuge können nicht jeden beliebigen Ladestrom einstellen, sondern springen von einer Stufe zur nächsten. So könnte z.B. bei freigegebenen 31,8 A immer noch mit 31 A geladen werden, bei 31,7 A dann plötzlich nur noch mit 30,5 A. Ein (alter?) Tesla Model 3 rundet einfach auf ganze Ampere und lädt dann nicht nur bei freigegebenen 30,4 A mit 30 A, sondern auch bei 30,5 A einfach mal mit 31 A, also mehr als die Wallbox erlaubt. Wenn sich der Akku füllt, reduziert das Fahrzeug die Ladeleistung, wovon die Wallbox nichts mitbekommt. Selbst wenn 32 A freigegeben sind, wird von 99 bis 100 % z.B. nur noch mit 8 A geladen. Ein ähnliches Problem tritt auf, wenn die Wallbox 32 A freigibt, aber das Fahrzeug generell nur mit maximal 16 A laden kann. Der von der Wallbox freigegebene Strom muss als Scheinstrom interpretiert werden, schließt also Blindleistung mit ein. Produziert ein Fahrzeug beim Laden viel Blindleistung, liegt die Schätzung also auch weit daneben. Am schlimmsten ist da ein Renault Zoe (neue Generation), der unter 7 A nur noch Blindleistung produziert und somit gar nicht mehr lädt. Hast du ein Fahrzeug, von dem du weißt, dass es sich in allen drei Kategorien kooperativ verhält, was gerade bei Punkt 2 schwierig wird, kann eine Abschätzung ohne Zähler halbwegs brauchbar sein. Andernfalls würde ich das als nutzlos einstufen.

Falls das Problem nochmal auftritt, bitte vor einem Neustart einen Debug-Report runterladen und hier anhängen. Vielleicht steht nichts hilfreiches drin, aber ohne Debug-Report haben wir noch schlechtere Chancen, eine mögliche Ursache rauszufinden.

Dein Mosquitto läuft auf localhost und nimmt deswegen nur Verbindungen vom RPi selbst an. Du musst die Mosquitto-Config anpassen und auf allen Interfaces lauschen. Wahrscheinlich musst du einfach /etc/mosquitto/conf.d/listener.conf editieren und „listener 1883“ reinschreiben. Dann noch „sudo systemctl restart mosquitto“ und schon sollte Mosquitto die Verbindung der Wallbox annehmen. Anschließend sollte das Kommando aus meinem vorigen Post in der Mitte *:1883 anzeigen.

Lade hier mal einen Debug-Report hoch. Den findest du unter System → Ereignis-Log. Der typische Anfängerfehler ist, beim MQTT-Server die IP der Wallbox einzutragen, aber das hast du ja anscheinend schon überprüft. Ansonsten kannst du mal auf dem RPi nachsehen, auf welcher IP Mosquitto lauscht: (ss -ntpl || netstat -ntpl) | grep 1883

Die Wallbox bekommt keine Zeitsynchronisation weil für die Ethernet-Verbindung eine statische IP eingetragen ist aber kein DNS-Server. Ohne DNS-Server kann die Wallbox den Zeitserver nicht erreichen. Überprüfe mal die Ethernet-Einstellungen und trage da den gleichen DNS-Server wie bei der anderen Wallbox ein.

1.) Aktuell werden mehrere Zähler leider noch nicht unterstützt. Da weder Zähler-ID noch Seriennummer beachtet werden, werden einfach sämtliche ankommende Pakete zusammengeworfen, was höchstwahrscheinlich nicht zum gewünschten Erfolg führt. Wir wollen das noch ausbauen und mehrere Zähler unterstützen, sind bisher aber leider noch nicht dazu gekommen. 2.) Was schließt sich aus? Zwei WARP2 im Lastmanagement mit SMA Speedwire oder generell zwei WARP2 zusammen mit PV-Überschussladen?

Bitte lade von der Wallbox ohne Zeitangaben einen Debug-Report runter (System → Ereignis-Log) und lade ihn hier hoch.