MatzeTF

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.

Die MQTT-API ist praktisch eine Schnittstelle zwischen einem MQTT-Broker und einem PC mit Brick Daemon und angeschlossenem Master Brick. Mit einem ESP kannst du das nicht verwenden. Willst du den ESP benutzen, kannst du entweder die Arduino IDE benutzen, womit du wahrscheinlich einiges selbst machen musst, also z.B. Ethernet aktivieren, MQTT-Verbindung aufbauen und Daten darüber versenden, etc. Alternativ kannst du unsere ESP32 Firmware benutzen. Da ist der Einarbeitungsaufwand wahrscheinlich größer, aber dafür ist einiges schon fertig und es gibt ein Tutorial zum Bauen eigener Module für neue Funktionalität. Ethernet und MQTT sind schon fertig. Wenn du die Module drin hast, kannst du die Einstellungen einfach über das Webinterface des ESP anpassen. Legst du einen neuen „State“ für irgendwelche Daten an, werden die dann automatisch per MQTT bereitgestellt. Hier mal als Beispiel ein Modul, das ich benutze, um einfach die Temperatur von einem Humidity Bricklet per MQTT bereitzustellen: #include "module_dependencies.h" #include "temperature.h" #include "bindings/hal_common.h" extern TF_HAL hal; #include "api.h" #include "event_log.h" void Temperature::pre_setup() { state = Config::Object({ {"temperature", Config::Int(-27316, -27316, 65535)}, // in centicelsius (cC) }); } static void temperature_cb(TF_HumidityV2 * /*device*/, int16_t temperature, void *user_data) { ConfigRoot *state = static_cast<ConfigRoot *>(user_data); state->get("temperature")->updateInt(temperature); } void Temperature::setup() { if (tf_humidity_v2_create(&bricklet_humidity, nullptr, &hal) == TF_E_OK) { tf_humidity_v2_register_temperature_callback(&bricklet_humidity, temperature_cb, &state); tf_humidity_v2_set_temperature_callback_configuration(&bricklet_humidity, 500, false, 'x', 0, 0); initialized = true; } if (initialized) { logger.printfln("Ready"); } else { logger.printfln("No Humidity Bricklet 2.0 found"); } } void Temperature::register_urls() { api.addState("temperature/state", &state); } In pre_setup einen State anlegen, der hier nur einen Temperaturwert enthält. In setup das Bricklet einrichten und den Callback für die Temperatur aktivieren. Der Callback schreibt einfach die Temperaturwerte in den State. In register_urls den State registrieren, damit er automatisch per MQTT bereitgestellt wird. Das Auslesen eines RS485-Zählers ist da natürlich deutlich aufwändiger. Außer, du willst zufällig einen Eastron SDM72DM, SDM72DMv2 oder SDM630 auslesen. Das haben wir schon fertig und wenn du die Module „meters“ und „meters_rs485_bricklet“ einbaust, bist du praktisch fertig. Für andere Zähler kannst du dir letzteres Modul ansehen und etwas Ähnliches für deinen Zähler implementieren oder alternativ das Modul erweitern.

Aktuell ist das die Lösung für dich. Demnächst™ gibt es irgendwann zwar von uns ein neues Lastmanagement, das PV-Überschussladen mit mehreren Wallboxen kann, aber SoC-Auslesen kann es dann noch nicht, sodass du wohl bei evcc bleiben musst.

Du kannst prinzipiell beides gleichzeitig verwenden. Auf jeder Wallbox greift das jeweils niedrigere Limit. evcc kann gerne beiden Wallboxen sagen, dass sie mit 32 A laden sollen, da das Lastmanagement beiden jeweils nur 16 A erlaubt, wenn beide gleichzeitig aktiv sind. Begrenzt evcc den Ladestrom auf 10 A, darf nur mit 10 A geladen werden und die 16 A vom Lastmanagement haben keinen Einfluss. Nachteilig an der Kombination ist allerdings, dass es zu einer zusätzlichen Verzögerung kommt, wenn evcc den Strom erhöht. Die Erhöhung muss nämlich zusätzlich vom Lastmanagement abgesegnet werden, was bei einer aktuellen Firmware fünf Sekunden benötigt, wenn ich mich recht erinnere.

Dann ist die Wallboxseite jetzt das einzige, was du noch nicht getestet hast. Wenn du keinen anderen Switch hast und dir auch keinen leihen kannst, hast du einen Laptop mit LAN-Port? Wenn der halbwegs aktuell ist, sollte der Auto-MDI-X können, sodass du ihn direkt an die Wallbox hängen kannst. Ansonsten kann EEE bei manchen Verbindungen Probleme machen, wenn ein Kabel fälschlicherweise als kurz erkannt wird und das Signal dann zu schwach eingestellt wird. Hast du schon ausprobiert, das zu deaktivieren? Was mir gerade noch einfällt: Wenn du ein „Fabrik-Kabel“ benutzt, wie hast du das mit Stecker durch die Kabeldurchführung bekommen? Eigentlich muss man für den Anschluss der Wallbox mindestens an einer Seite einen Stecker selber crimpen.

Der Ethernet-Brick kann nur 100 MBit. Der Test mit den Switches war nur dafür gedacht, um das Kabel zu testen. Wenn da irgendwas nicht passt, kommt üblicherweise keine Gigabit-Verbindung zustande. Von Link-Problemen beim Ethernet-Brick ist mir nichts bekannt. Es ist eigentlich immer die Verkabelung Schuld. Da ich selbst schon Probleme mit schlecht gecripten Kabeln oder vertauschten Adern hatte, was ich meistens selbst verursacht hatte, halte ich das für die wahrscheinlichere Ursache. Weitere Ideen: Hast du schon einen anderen Port am Switch ausprobiert? Hast du schon versucht, den Switch, an dem die Wallbox hängt, nach draußen zu tragen und die Wallbox direkt anzuschließen? Falls der Switch nicht bewegbar ist, hast du schon versucht, einen anderen Switch draußen direkt an die Wallbox anzuschließen? Falls der Switch, an dem die Wallbox hängen sollte, EEE (Energy-Efficient Ethernet) kann, kannst du das auf dem Port deaktivieren? Da es ein managed Switch ist, kannst du mal die Verbindungsgeschwindigkeit von dem Port fest auf 100 MBit stellen? Wenn es die entsprechende Option gibt, Auto-negotiation an lassen aber Gigabit bei den möglichen Geschwindigkeiten abwählen. Hilft das alles nicht, mal die Geschwindigkeit fest auf 10 MBit Full-Duplex stellen?

In deinem ersten Log, das du auch oben zitiert hast, sieht man, dass es ca. 60 Sekunden gedauert hat, bis nach dem Start der Ethernet-Schnittstelle dann auch tatsächlich ein Link da war. Normalerweise liegen zwischen Start und Connect nur wenige Millisekunden, wenn eine gute Verbindung besteht. Zusammen mit der ansonsten instabilen Verbindung deutet das darauf hin, dass das Netzwerkkabel irgendein Problem hat. Wenn ein anderes Gerät am Kabel Verbindung hat, heißt das nicht, dass das Kabel in Ordnung ist. Wenn die Verbindungsqualität gerade so an der Grenze ist, kann es sein, dass einige Geräte eine Verbindung hinbekommen, andere nicht. Leider ist es oft schwierig, bei Kabelproblemen die tatsächliche Ursache rauszufinden. Bei selbst gecripten Kabeln ist oft die Crimpung nicht ganz richtig oder bei an beiden Enden selbst gecripten Kabeln sind gerne mal zwei Adern vertauscht, so dass die Aderpaare nicht paarig sind. Sind auf der Strecke zwischen Switch und Endgerät auch noch Netzwerkdosen, trifft das da genauso zu. Wenn du noch einen anderen Switch hast, häng den doch mal testweise an der Wallboxseite ans Kabel und die Wallbox dann daran. Wenn beide Switches Gigabit können, achte auch mal darauf, ob der Link mit Gigabit zustande kommt oder nur 100 MBit schafft.

Wenn du „WLAN als Fallback“ aktiviert hast, musst du u.U. das Netzwerkkabel ausstecken, damit sich der Accesspoint nach 10-30 Sekunden aktiviert. Solange die Wallbox glaubt, dass eine LAN-Verbindung besteht, wird der Fallback-Modus nicht aktiviert. Der Aufkleber im Inneren der Wallbox befindet sich üblicherweise auf der Front von einem der Schütze. Würde mich wundern, wenn der da nicht ist, kann aber natürlich versehentlich vergessen worden sein. Den zweiten, identischen Aufkleber auf der Rückseite der Anleitung hast du ja schon gefunden. Was meinst du mit „WLAN-Verbindung aktiviert“? Hast du den AP dauerhaft aktiviert oder die Wallbox in deinem WLAN angemeldet? Letzteres ist zusammen mit einer LAN-Verbindung nicht empfehlenswert, da das paradoxerweise zu Verbindungsabbrüchen führen kann, wenn beide Verbindungen abwechselnd versuchen, die Netzwerkkonfiguration zu setzen. Hast du eine LAN-Verbindung, solltest du die WLAN-Verbindung ausschalten. Der Accesspoint der Wallbox ist davon unabhängig und kann dementsprechend entweder dauerhaft oder im Fallback-Modus aktiviert sein.

4 mA? Ich sehe eine Fußnote mit 3 mA. Aber jetzt wo du’s sagst: Die Temperatur habe ich komplett vergessen. Die Angaben im Datenblatt beziehen sich auf 25 °C Umgebungstemperatur. Die 2 mA und 1,5 V können sich also auf die Grenzen des zulässigen Arbeitsbereiches von -40 °C bis 85 °C beziehen.