MatzeTF

1) Ja. 2) Korrekt. 3) Je kürzer, desto besser. Bedenke, dass du nicht nur zwei Adern für die Ansteuerung mit 230 V brauchst, sondern auch zwei Adern für die Schützüberwachung. Eine genaue Maximallänge kann ich dir nicht sagen, aber bei einer zu langen Leitung kann es sein, dass die Schützüberwachung fälschlicherweise auslöst. Normalerweise werden Energy Manager und Schütz in die selbe Unterverteilung gebaut, sodass die Kabel eigentlich nicht länger als 1 m werden. Wie weit auseinander willst du sie denn verbauen?

Eigentlich muss ein Bus an beiden Enden terminiert werden. Ist dein Bus ausreichend kurz, geht das auch mit nur einer Terminierung. Wenn die Übertragung mit beiden Terminierungen unzuverlässig wird, ist das eigentlich ein Zeichen, dass der Bus überlastet ist. Wenn’s aber so funktioniert, ignorier es einfach. Wenn ich die Modbus-Spezifikation gerade richtig im Kopf habe, muss ein Gerät innerhalb von 50 ms auf eine Leseanfrage antworten. Wenn du ein Delay von 60 ms brauchst, ist das daher nicht ungewöhnlich. Die Baudrate ist dabei unerheblich, da das angesprochene Gerät halt eine gewisse Zeit braucht, um die Anfrage zu verarbeiten und eine Antwort zu generieren. Da du aber drei unabhängige Busse hast, parallelisiere das Ganze doch einfach. Du sprichst immer drei Geräte gleichzeitig an, eins pro Bus. Dann brauchst du nur noch ca. 3 Sekunden pro Schleife. Noch besser wird es dann, wenn du die Geräte in 2 x 33 und 1 x 32 auf die Busse aufteilst.

Wenn du PV-Überschussladen mit Phasenumschaltung machen möchtest, müssen prinzipiell beide Wallboxen am selben Schütz angeschlossen sein, weil ein WEM die Kontrolle über alle Wallboxen haben muss. Mit zwei WEM, die PV-Überschussladen machen, würden beide gegeneinander arbeiten. Wenn du nun wegen der Absicherung lieber zwei Schütze nutzen möchtest, ist es auch möglich, zwei Schütze an einen WEM anzuschließen. Dabei musst du darauf achten, dass die Versorgungsspannung der Schütze parallel angeschlossen ist, die Hilfskontakte für die Schützüberwachung aber unbedingt in Serie! Anders sieht es aus, wenn du evcc im Einsatz hast. In dem Fall übernimmt evcc das PV-Überschussladen und du kannst für jede Wallbox ein Schütz und einen WEM installieren, die dann von evcc gesteuert werden.

Einen Debug-Report kannst du über die Weboberfläche unter „System“ herunterladen. Versuch aber bitte vor einem Neustart des EM, ob du das Ereignisprotokoll händisch herunterladen kannst, da es durch einen Neustart gelöscht wird. Hänge dazu "/event_log" an die Adresse des EM an, also z.B. "http://wem-ABCD.local/event_log". Nach einem Neustart dann noch einen Debug-Report runterladen und beides hier anhängen.

Ich bin dazu geneigt, die Schuld auf ioBroker zu schieben, und zwar auf dem einfachen Grund, dass bisher praktisch immer, wenn jemand MQTT-Probleme gemeldet hat, ioBroker im Spiel war. Wir verwenden Mosquitto, was ein standardkonformer MQTT-Broker ist, und haben nie Probleme damit. Wäre es für dich eine Option, Mosquitto einzurichten und zu testen, ob damit die Probleme weg sind? Wenn das Problem „seit ein paar Wochen“ besteht, hast du zu dem Zeitpunkt ein Firmwareupdate der Warp2 oder ein Update von ioBroker durchgeführt? Alternativ: Läuft ioBroker auf einem alten Raspberry Pi oder ähnlich langsamen Gerät und ist möglicherweise einfach überlastet? Hast du ansonsten die Möglichkeit, auf dem Gerät, auf dem ioBroker läuft, per tcpdump oder Wireshark den Netzwerkverkehr zwischen Warp2 und ioBroker zu analysieren?

You have to call "set_status_led_config(2)" on the IMU object you created before. You probably have something like this in your code: imu = BrickletIMUV3(UID, ipcon) Afterwards, set the LED config like this: imu.set_status_led_config(2) Have a look at one of the IMU examples and note how "get_quaternion()" is used on the "imu" object.

I would count in days, not weeks. 😉

Ja, das ist genau der richtige Wert und somit ausreichend. Ich war nur neugierig, wie du dazu gekommen bist, weil das ganze noch gar nicht vollständig dokumentiert ist. Die IDs kannst du per MQTT-Nachricht an meters/n/config_update einstellen. Das muss man aber nur einmal machen, weshalb das übers Webinterface sowieso einfacher ist. Verwendest du eigentlich meters/n/update zum Setzen des Zählerwertes oder benutzt du die Legacy-API?

OCPP mit evcc kann ich nicht empfehlen, da beide erwarten, die Steuerungshoheit über die Wallbox zu haben. Theoretisch kann das funktionieren, aber ich befürchte, dass das in den meisten Fällen nicht zum gewünschten Ergebnis führt. Wenn OCPP aktiviert ist, sollte die Ladefreigabe per NFC deaktiviert sein, weil OCPP das übernimmt.

Kannst du das etwas konkretisieren? Wie hast du den ersten Ladevorgang unterbrochen? (evcc, Wallbox, Auto? Wie genau?) An welcher Stelle werden „Ladebereit“ und „Getrennt“ angezeigt? Wallbox-Webseite oder evcc? Unabhängig von evcc darf die Wallbox nicht ladebereit sein, wenn deren Kabel gar nicht in ein Fahrzeug eingesteckt ist.

Du musst den Kondensator gar nicht ablöten. Du kannst einfach einen zusätzlichen Kondensator in der Zuleitung platzieren, möglichst nah am Stecker am Bricklet. Theoretisch kannst du ihn auch kreativ mit in die Klemmen vom Stecker stecken. Ein überdimensionierter Kondensator führt zu einem sehr langsamen Spannungsanstieg nach dem Einschalten. Das solltest du, falls es zutrifft, auch mit einem Multimeter messen können. Ansonsten kann ich da nur auf das oben verlinkte Dokument verweisen: Je nach dem, wie flink dein Multimeter sich aktualisiert und wie lange der Bremsprozess dauert, kannst du den Spannungsanstieg auch mit dem Multimeter messen. Zu Testzwecken kannst du ja mal die Versorgungsspannung reduzieren und messen, wie stark sie beim Bremsen ansteigt. Die dadurch entstehenden Schrittfehler sind beim Testen hoffentlich zu verschmerzen.

Das hört sich doch schon mal super an. Wegen dem Ladestart kannst du mal einen Blick auf die Debug-Seite des WEM werfen (System → Debug). Dort gibt es „power at meter filtered“ und „overall min power“. Ersteres muss über letzterem liegen, damit ausreichend Sonne angenommen wird. Je nach Bewölkung kann es bis zu 4 Minuten dauern, bis der gefilterte Wert der Sonne nachgelaufen ist. Außerdem gibt es dort „on state change blocked“ und „on state change delay“, die dich ggf. darüber informieren, ob sich die Sonneneinstrahlung zu kürzlich geändert hat und noch mit dem Einschalten gewartet wird. Die Einschaltverzögerung nach Erreichen der Einschaltgrenze liegt bei 5 Minuten, IIRC. Sinn und Zweck des Filters und der Verzögerung ist, dass bei wechselnd bewölktem Wetter das Auto nicht dauert ein- und ausgeschaltet wird, was die Ladeelektronik schädigen könnte. Mal so aus Neugierde: Wie bist du darauf gekommen, dass du den Wert mit ID 74 brauchst?

ABB-Zähler oder andere Zähler, die nicht auf der Liste stehen, werden nicht unterstützt und es gibt auch keine Bestrebungen dazu. Wir unterstützen nur Zähler, die wir in den Wallboxen verbauen bzw. dafür evaluiert haben. Unterstützung für andere Zähler müsstest du bei Bedarf selbst implementieren, entweder als Erweiterung der EVSEv2-Firmware oder per RS485 Bricklet. Code für Ersteres findest du im bricklib2 git, Code für Zweiteres im „meters rs485 bricklet“ Modul im esp32-firmware git.

Aktuell ist es nicht möglich, beim WEM den maximalen Ladestrom vorzugeben. Du kannst allerdings auf der Energy Manager Einstellungsseite das Regelverhalten anpassen und so verschieben, dass zuerst das Auto geladen wird. Dann wird allerdings auch die Energie aus dem Batteriespeicher genutzt, um das Auto zu laden. Wenn du den Ladestrom extern vorgeben willst, kannst du sowohl Wallbox als auch WEM auf „Externe Steuerung“ stellen. Dann Kannst du den Ladestrom an die Wallbox schicken und die Phasenanforderungen an den WEM.

Please let the NFC reader read the tag from the smartphone and then download a debug log from the Warp2 and upload it here.

No, this is not possible by design with version 1.3 of the Step-Down Power Supply. It has diodes included to prevent feeding the 5 V output from the USB port of the Master. If you happen to already have a version 1.2, it is possible because it doesn’t have the diodes yet. What the documentation means is that you can have both in a stack and either of them will power the stack if the other one loses input power. There are, however, a few bricklets that have 5 V outputs that are fed from any 5 V source in the stack, including the Ethernet PoE Extension. Have a look at the IO-16, Analog In and Analog Out bricklets. If you only need a 5 V output and don’t actually need the input and power supply of the Step-Down Power Supply, using one of the bricklets will also be the cheaper option. The only drawback of the bricklets is that you might not be able to draw higher currents from their outputs, depending on your cabling. The Analog In and Analog Out bricklets have 350 mA fuses for their 5 V outputs, the IO-16 has no fuse and will output whatever you can get across the cables. Another option would be to just get a 7-pin bricklet cable and cut off the data and 3.3 V wires and only use it to draw 5 V from one of the Master’s bricklet ports.

Das bedeutet, dass brickd bereits läuft, wahrscheinlich als Systemdienst. Versuch es mal mit „journalctl -u brickd“, um dir das Protokoll vom Systemdienst anzuzeigen.

Wenn du die manuelle Ladefreigabe verwendest, kannst du über eine Automatisierungsregel das Laden freigeben. Das ist allerdings eine zusätzliche Beschränkung, was heißt, wenn evcc aktiv ist, kannst du zusätzlich eine manuelle Ladefreigabe notwendig machen, auch wenn evcc schon Strom freigegeben hat. Du kannst mit der manuellen Ladefreigabe aber nicht evcc übergehen. Logisch ausgedrückt ist das ein „A und B“, nicht „A oder B“. Ich vermute mal, dass sich borg42 auf den zweiten Teil deiner Anfrage mit der Checkbox bezogen hat, nicht auf die Sache mit evcc.

Verstehe ich das richtig, dass du versuchst, die DC-Spannung zwischen Performace-DC Bricklet und Motor zu messen? Das wird wegen dem PWM-Signal nicht funktionieren. Durch das PWM schwankt die Spannung zwischen 0 und Vin. Wenn du das versuchst zu messen, erwarte ich da in der Tat nur stark schwankende Werte. Warum misst du nicht Spannung und Strom am Eingang vom Performance-DC Bricklet? Das, was an Leistung zum Motor rausgeht, muss ja vorne rein.

Das Problem ist, dass evcc, wenn es aktiviert ist, die Steuerungshoheit beansprucht. evcc bei Bedarf zu ignorieren ist aktuell nicht vorgesehen. Dementsprechend kann die Wallbox nur zusätzlich das Laden verbieten, aber nicht erlauben wenn evcc es verbietet. Kann man evcc vielleicht einfach seinen Wunsch per MQTT mitteilen? MQTT-Nachrichten auf Knopfdruck kannst du ja schon jetzt einrichten.

Ich habe gerade noch mal etwas recherchiert und wenn ich das richtig sehe, kann gerade beim Bremsen von Systemen mit hoher Trägheit das Problem auftreten, dass die Betriebsspannung des Motorcontrollers überschritten wird. Beim Bremsen muss die kinetische Energie des Systems irgendwo hin. Der kleine Motorcontroller wird sie nicht als Verlustwärme abgeben können. Stattdessen ist es wohl so, dass die Energie durch der Motorcontroller zurück in den Zwischenkreis gespeist wird, also der Bereich zwischen Netzteil und Motorcontroller. Dort muss sie entweder in einem entsprechend großen Ladekondensator zwischengespeichert oder per Brems-Chopper abgebaut werden. Für Systeme mit hoher Trägheit ist der auf der Bricklet vorhandene 330 μF-Kondensator möglicherweise zu klein. Da du mit 44 V schon nah an der maximalen Versorgungsspannung bist, ist es möglich, dass beim Bremsen die Spannung im Zwischenkreis auf über 50 V steigt und der Motorcontroller Schaden nimmt. Wenn du ein Oszilloskop hast, miss doch mal an den Klemmen für die Versorgungsspannung von einem der noch funktionierenden Bricklets die Zwischenkreisspannung bei einem Bremsvorgang. Steigt die Spannung verdächtig hoch an, brauchst du vielleicht einfach einen größeren Ladekondensator. Dieses Dokument empfiehlt als Faustregel 1000 μF pro 1 A Motorstrom. Alternativ reicht es vielleicht auch einfach, die Versorgungsspannung zu reduzieren, damit du beim Bremsen nicht an die kritischen 50 V kommst. Vielleicht bin ich auch komplett auf dem Holzweg, da die Leitungen zum Netzteil hinreichend kurz sind und die Ausgangskondensatoren vom Netzteil die Bremsenergie problemlos aufnehmen können. Ich bin leider kein Experte für Schrittmotoren. Ich interessiere mich nur für die Technik. 😉

Ich glaube nicht, dass die Endschalter das Problem waren, sondern vielleicht eher die „relativ massive Spindel“. Kann es sein, dass deine Konstruktion einfach zu schwer ist, und beim Bremsen den Motortreiber überlastet hat? Welchen Motorstrom hattest du eingestellt? Du könntest versuchen, die Bremsbeschleunigung zu reduzieren. Das klappt natürlich nur, wenn du hinter dem Endschalter noch genug Spielraum hast. Ansonsten musst du auch die maximale Fahrgeschwindigkeit und somit den Bremsweg zu reduzieren.

Aktuell nicht so einfach. Du hast zwei Möglichkeiten: Du compilierst die Firmware für den EM selbst und nimmst dabei das Modul „Meters Mqtt Mirror“ mit rein, das wir intern zum Testen benutzen und das einfach die Zählerwerte eines anderen Gerätes über MQTT empfängt. Zusätzlich musst du dir noch einen MQTT-Server einrichten, falls du nicht schon einen hast. Alternativ richtest du im EM einen API-Zähler ein und schreibst dir ein kleines Programm, das die Zählerwerte aus der Wallbox ausliest und an den EM schickt. Ansonsten kannst du Leistung und Verbrauch deiner Wallbox bereits jetzt schon im EM unter „Energiebilanz“ sehen. Andere Zählerwerte der Wallbox gibt es da allerdings nicht.

Wahrscheinlich, weil du bei deinem vorigen Versuch durch eine manuelle Phasenumschaltung evcc dazu gebracht hast, eine Phasenanforderung an den EM zu schicken. Wenn du den EM zwischenzeitlich nicht neugestartet hast, ist die Phasenanforderung weiterhin aktiv und in diesem Zustand sollte es auch weiterhin funktionieren.

Der ESP32 Brick unterstützt aktuell leider noch kein MQTT über TLS, sondern nur unverschlüsselte Verbindungen. MQTTS steht auf unserer Todo-Liste, aber zugegebenermaßen nicht sehr weit oben.