MatzeTF

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.

Die Anleitung ist für ein 32 Bit RPi OS. Wenn du libusb-1.0-0, libudev1 und procps installierst, werden die für 64 Bit installiert (was sie bei dir aber auch schon waren). Das armhf-Paket ist für 32 Bit, aber die 32 Bit-Abhängigkeiten waren nicht installiert, weshalb das dann fehlgeschlagen ist. --fix-broken-install hat dann die fehlenden 32 Bit-Abhängigkeiten nachinstalliert. Wenn du auf 64 Bit unterwegs bist, solttest du den brickd auch in 64 Bit installieren. Noch mehr empfehle ich dir allerdings, einfach unser Repository einzubinden. Dann bekommst du auch automatisch die richtige Version und alle Updates.

Aber Achtung: Das funktioniert nur bei einem einfachen Neustart. Nach einem Firmware-Update oder Stromausfall startet der WEM jetzt im einphasigen Modus. Dann kann man zwar erstmal laden, aber wenn EVCC davon ausgeht, dass gerade dreiphasig geladen wird, wird nie eine Phasenumschaltung auf dreiphasig durchgeführt. Das ist von unserer Seite auch nicht besser zu retten.

Da lässt sich leider nichts löten, da das Problem das Timing der Messungen ist. Bei WARP2 und WARP3 wird immer am Ende der High-Phase des PWM-Signals gemessen, da dann die Störungen am geringsten sind. Bei der WARP1 ist die Synchronisation zwischen PWM und Messzeitpunkt leider nicht möglich.

Das sieht so aus, als ob du evcc dazu motivieren konntest, eine Phasenanforderung an den Energy Manager zu schicken. Ich vermute, dass du ab jetzt wieder problemlos einphasig laden kannst. Zumindest, bis der Energy Manager das nächste Mal neugestartet werden muss und dann wieder auf eine Nachricht von evcc wartet.

Eine sichere Phasenumschaltung, wie sie die WARP2 macht, kannst du mit jedem Fahrzeug machen. Aus Sicht des Fahrzeuges ist das nichts anderes als Stecker raus, Stecker rein. Falls du damit meinst, dass dein Fahrzeug nur einphasig laden kann: Dem Fahrzeug ist es egal, ob da noch zwei weitere Phasen sind, die es nicht nutzen möchte. Wenn man zu schnell hintereinander Phasenumschaltungen macht, kann es aber passieren, dass ein Fahrzeug nicht mehr laden will, weil es die Wallbox für defekt hält. In dem Fall hilft ausstecken und ein paar Minuten warten, bis man es wieder einsteckt. Ich empfehle mindestens 30 Sekunden Wartezeit zwischen zwei Phasenumschaltungen.

In den Debug-Logs von Andy und dem Bauch steht, dass evcc keine Phasen beim Energy Manager angefordert hat. Dementsprechend wird auch kein Strom freigegeben. Wir haben das mit evcc jetzt bei uns nachgestellt und die Phasenumschaltung funktioniert. Es gibt aber weiterhin das Problem, dass evcc nur dann eine Phasenanforderung an den Energy Manager schickt, wenn eine Phasenumschaltung durchgeführt werden soll, was dazu führt, dass der Energy Manager nach einem Neustart auf eine Phasenumschaltung von evcc wartet, die möglicherweise nie kommt, weil evcc keine Phasenumschaltung durchführen möchte. Das dürfte insbesondere für Andy ein Problem sein, da er immer nur einphasig laden möchte und deswegen nie eine Phasenumschaltung durchgeführt wird. Kontrolliert bitte Folgendes: In eurer evcc.yaml muss beim Load Point "phases: 0" stehen. Wenn das fehlt oder da eine andere Zahl steht, wird nie eine Nachricht an den Energy Manager geschickt. Auf der Statusseite von evcc gibt es rechts neben dem „Schnell“-Button Wallboxeinstellungen. Dort muss „automatischer Wechsel“ verfügbar sein. Wenn das der Fall ist, klickt bei angeschlossenem Fahrzeug mal auf 3-phasig oder 1-phasig, bzw. schaltet mit etwas Wartezeit einmal das eine und dann das andere ein. Dann sollte der Energy Manager auf die entsprechende Anzahl Phasen umschalten und Strom freigeben. Wenn das funktioniert, dann funktioniert die Phasenumschaltung. Das Problem, in das ihr lauft, ist dann das schon seit Anfang an bestehende Problem, dass evcc nicht den Zustand vom Energy Manager abfragt und dessen Neustart nicht mitbekommt. Das dürfte dann auch der Grund sein, warum es bei Andy monatelang funktioniert hat und seit dem Firmware-Update nicht mehr: während der Einrichtung vor einiger Zeit hat evcc irgendwann mal eine Phasenanforderung gesendet, seitdem aber nicht mehr. Wegen dem Update musste neugestartet werden und der Energy Manager wartet jetzt auf eine Phasenanforderung, was evcc ignoriert.

No. Any Config you create and store on the ESP’s flash is local to the ESP only. You can tie the Config to a URL on the ESP’s webserver, which makes it available via HTTP and MQTT, though.

Bitte Lade Debug-Logs von WEM und WARP2 hoch, wenn sie gerade in dem festhängenden Zustand sind, damit ich überprüfen kann, ob die fehlende Phasenumschaltung tatsächlich das Problem ist.

Hier erstmal die Antworten auf deine Fragen aus dem anderen Thread: Bei MQTT müssen Updates immer an _update gesendet werden, aber gelesen wird immer ohne _update. Vielleicht wird das deswegen ohne _update angezeigt, obwohl es intern verwendet wird. Schau mal in die API-Doku: external_control auf 0 beim state bedeutet, dass die Phasenumschaltung verfügbar ist und aktuell keine Anfrage bearbeitet wird und auch kein Fehler vorliegt. Als nächstes: Hast du schon versucht, eine Phasenumschaltung durch EVCC zu veranlassen? Nach einem Neustart des Energy Managers wartet der immer auf eine Anforderung von EVCC, aber EVCC schickt nur Nachrichten, wenn eine Phasenumschaltung durchgeführt werden soll. Lade mal Debug-Logs von WEM und WARP2 runter und häng sie hier an, wenn du gerade in dem festhängenden Zustand bist.

Wäre nett, wenn du das weiter im Blick behalten könntest. Wenn ein Fahrzeug angeschlossen wurde, bekommt es erst mehr zugewiesen, aber wenn es ein paar Minuten nicht (mehr) laden wollte, sollte der zugewiesene Strom auf 6 A reduziert werden und der Rest an die andere Wallbox gehen, sofern dort auch ein Fahrzeug angeschlossen ist. Wenn das nicht passiert, ist das ein Bug.

Dafür kann unser Config-System benutzt werden. Du kannst einfach eine Config mit deinem float oder uint32 drin anlegen und nach Änderungen im Flash des ESP32 ablegen lassen. Schau mal im Uptime Tracker Modul (uptime_tracke.cpp), wie die Variable "uptimes" benutzt wird.

Eigentlich sollte es so sein, dass die Wallbox mit dem nicht ladenden Fahrzeug nur 4140 W bekommt, die andere 6900 W. 6 A ist das Minimum, was dreiphasig 4140 W ergibt. Passiert das oder bekommen beide Wallboxen immer genau die Hälfte zugeteilt? Weniger als 6 A kann man leider nicht zuteilen, da eine Wallbox nicht weiß, ob ein Fahrzeug laden möchte, wenn kein Strom freigegeben ist.

Das Problem ist, dass du nur default_mode setzt und alles andere fehlt. Wenn du Einstellungen über die API änderst, müssen immer alle Einträge einer Config vorhanden sein. Wenn du dir die anderen Einträge nicht von Hand zusammenbauen willst, kannst du dir die aktuellen Einstellungen ansehen, wenn du einfach die URL, die du ändern willst, runterlädst oder im Browser ansiehst (gegebenenfalls auf Raw/Rohansicht umstellen). http://192.168.5.90/power_manager/config sieht z. B. so aus: {"phase_switching_mode":3,"excess_charging_enable":false,"default_mode":0,"meter_slot_grid_power":0,"target_power_from_grid":0,"guaranteed_power":1380,"cloud_filter_mode":1} Kopiere das einfach komplett und ändere die Werte, die du ändern möchtest. Alles andere lässt du unverändert. Wenn du Linux nutzt, kannst du übrigens auch einfache Anführungszeichen (') darum setzen, dann brauchst du nicht alle doppelten Anführungszeichen (") innen drin escapen. Unter Windows kannst du es in Notepad kopieren und alle " durch \" ersetzen lassen.

Aktuell wird das noch nicht unterstützt, steht aber auf unserer ToDo-Liste. Zugegebenermaßen allerdings nicht sehr weit oben.

Die Umstellung von 100er auf 700er-Modelle wird dir aber auch nicht helfen, wenn sich die Leistungsangaben im Modell 701 weiterhin nur auf den Hybrid-WR beziehen und du den Netzbezug am Hausanschluss nicht aus dem Ding rausbekommst. Dazu bräuchtest du eine Erweiterung, die z.B. die Zählerwerte am Hausanschluss oder den Eigenverbrauch vom Haus entweder als weiteres Modell oder unter einer anderen Modbus-Adresse bereitstellt. Entweder Hausanschluss oder Eigenverbrauch muss dem WR bekannt sein, da er einen dieser Werte zum Regeln seiner Leistungsaufnahme oder -abgabe benötigt.