MatzeTF

An dieser Stelle noch mal der schon fast obligatorische Hinweis, dass sich demnächst die API ändern wird. Die Sache mit meters/values_update ist aktuell ein offiziell nicht unterstützter Hack. In absehbarer Zeit wird es eine offizielle API geben, für die die Werte anders formatiert werden müssen. Wenn es soweit ist, kündigen wir das aber nochmal an und es wird auch eine automatische Migration geben, die die meisten Anwendungsfälle abdeckt. Der Stromzähler-Typ muss auf „Benutzerdefinierter Zähler“ gestellt sein, damit die API-Migration bei euch durchgeführt wird.

Ich bin mir nicht ganz sicher, was du damit erreichen möchtest. Die Step-Down Power Supply erzeugt 5 V für den Stapel und schleift die Eingangsspannung (z.B. 24 V) nur durch. Du möchtest nicht den Motor mit 5 V betreiben, oder? Dann musst du doch nur eine Verbindung zwischen dem Eingang der Step-Down Power Supply und dem Eingang des DC Bricklets herstelle, damit die 24 V bei beiden ankommen. Wolltest du dir einfach diese Verbindung sparen? In dem Fall hast du recht, das geht nicht mehr. Das siehst du richtig. Wenn es Stepper im Namen hat, ist es für Stepper-Motoren ausgelegt. Für „normale“ Motoren sind die DC-Varianten gedacht.

Zoes haben leider die Eigenschaft, dass sie „einschlafen“, wenn nach dem Einstecken nicht innerhalb weniger Minuten Strom aus der Wallbox kommt. Die WARP2-Wallboxen haben eine Aufweckfunktion, die dem Ladestandard für Wallboxen mit Typ 2-Stecker entspricht. Leider zeigt sich eine eingeschlafene Zoe davon gänzlich unbeeindruckt und wacht nicht auf. Wir haben schon alles ausprobiert, was von Seiten der Wallbox möglich ist, aber nichts davon weckt eine Zoe aus dem Koma auf. Das Einzige, was hilft, ist, eine Taste auf der Keycard zu drücken, was die Wallbox natürlich nicht kann. Wenn die Zoe dagegen nach dem Einstecken einmal Strom „gesehen“ hat und das Ladekabel verbunden bleibt, lässt sie sich auch nach einer langen Ladepause problemlos wieder aufwecken. Zeitgesteuertes Laden klappt also wahrscheinlich nur, wenn du nach dem Einstecken kurz Strom freigibst und danach wieder abbrichst, damit sich die Zoe zum gewünschten Ladestart aufwecken lässt.

Die fertige, nutzbare API gibt es nicht in einem Repository, da sie mit einem Code-Generator erzeugt wird. Das generators-git findest du hier. Einfach auschecken reicht aber nicht, da nach jeder Änderung am Generator der Generator einmal ausgeführt werden muss, um die API-Dateien zu aktualisieren. Du müsstest dir selbst irgendwas scripten, das überprüft, ob es nach einem git pull einen Commit gibt, der neuer ist als deine API-Dateien, und in dem Fall den entsprechenden Generator ausführt.

Ich glaube nicht, dass das etwas verbessert, da die Implementierung von MQTT in ioBroker nicht standardkonform ist. Statt einem nicht standardkonformen Server mehrere nicht standardkonforme Server laufen zu lassen, macht meiner Meinung nach keinen Sinn. Was hilft, ist, den MQTT-Broker von ioBroker komplett zu deaktivieren und einen standardkonformen MQTT-Broker wie z. B. Mosquitto zu verwenden. Die Optionen „nur bei Änderungen publizieren“, „eigene States beim Verbinden publizieren“ und „States bei subscribe publizieren“ sollte es genauso wenig geben wie „Standard-QoS“ und „Retain-Flag setzen“, da das MQTT-Protokoll exakt vorgibt, wie diese Fälle behandelt werden müssen. Dass es diese Optionen gibt, legt nahe, dass die ioBroker-Entwickler das MQTT-Protokoll anscheinend nicht richtig verstanden haben.

Ich habe EVCC noch nicht benutzt, deswegen weiß ich nicht, was da ein guter Wert ist. Wenn du kein EVCC verwendest, verteilt der EM alle 5 Sekunden die Energie neu. Der EM möchte sekündlich frische Werte, damit er nicht mit zu alten Daten arbeitet. Würdest du im 5-Sekunden-Takt Werte reinschieben, könnte es passieren, dass die Werte immer kurz nach einem Verteilungsdurchlauf reinkommen und der EM somit auf 4 Sekunden alte Werte regelt, wodurch der Regelzyklus bei 9 Sekunden liegt, statt nahe bei 5.

Was meinst du mit „Kompatibilität“? Du musst irgendwie den Messwert für den Leistungsbezug am Hausanschluss in den Energy Manager bekommen. Wir arbeiten aktuell an einer Unterstützung für SunSpec. Falls eines deiner beiden Geräte das unterstützt, kannst du die Zählerwerte von dort abfragen. Ansonsten kannst du den Energy Manager auch per HTTP oder MQTT mit Messwerten füttern. Ist das auch keine Option, brauchst du einen zusätzlichen Zähler am Hausanschluss, der die Werte liefert.

Kann er, allerdings müssen beide hinter dem selben Schütz hängen.

Wenn du Überschussladen mit Home Assistant betreiben möchtest, musst du die Logik selbst implementieren. Bei der Wallbox kannst du über die API die Leistung begrenzen. Erreichen kannst du sie über HTTP oder MQTT. Standardmäßig werden in Home Assistant nur Infos angezeigt und es gibt Buttons und Zahlenfelder, mit denen du die Wallbox steuern kannst. Soll die Leistung automatisch angepasst werden, müsstest du das selbst implementieren. Möchtest du Überschussladen nicht selbst implementieren, brauchst du den Energy Manager. Phasenumschaltung ist aktuell nur mit dem Energy Manager möglich, da der das Schütz zum Abschalten der zweiten und dritten Phase ansteuert. Das kann die Wallbox noch nicht selbst.

Also eigentlich kann das nur auftreten, wenn die Versorgungsspannung verpolt ist. Bitte kontrolliere nochmal, ob GND tatsächlich an - angeschlossen ist und VCC and +.

Sorry, das hatte ich schlecht erklärt. Ich hätte gleich ein Bild malen sollen. Bitte einmal das Blaue messen.

In deinem zweiten Post hattest du geschrieben, dass du an dem von dir rot markierten Pin an der Ecke immer VCC gemessen hast. Kannst du das nochmal verifizieren und anschließend bei angeschlossener Spannungsversorgung die Spannung zwischen GND und dem von mir rot markierten Pin an der Diode messen?

Miss mal zwischen blau und gelb sowie zwischen blau und grün. Blau-gelb sollte immer 3,3 V sein. Blau-grün sollte bei Channel 0 GND 3,3 V sein und bei Channel 0 VCC 2,2 V. Trenne dann mal alle Verbindungen und miss zwischen diesen Kontakten den Widerstand: Orange-rot: Widerstand sollte 0 sein. Rot-türkis: Widerstand sollte 104 kΩ sein. Türkis-lila: (- an lila, + an türkis) Widerstand sollte über 20 MΩ sein.

Du könntest mal einen Blick auf den Schaltplan werfen und die Signale zwischen Optokoppler und OP-Amp messen. Beachte dabei, dass die Reihenfolge der Pins am Optokoppler andersrum laufen als die Ausgangspins. Das Zwischensignal für Channel 0 befindet sich auf der Seite mit dem TF-Logo. Das Beinchen direkt neben dem SMD-Bauteil mit „103“-Beschriftung kannst du mal gegen GND messen. Das Signal sollte invertiert zum Channel 0 Ausgang sein und entweder bei ca. 0,1 V oder 3/4 VCC liegen.

In den Fall wäre deine Frau davon abhängig, was EVCC als letztes eingestellt hat. Ich habe allerdings noch nicht gehört, das EVCC häufig ausfällt. Das sollte also eigentlich kein Problem sein.

I assume you’re talking about - 350 μT (micro Tesla) and not - 350 mT (milli Tesla). According to the datasheet, the sensor has a quiescent output tolerance of about ± 16 % (*note). That means that the zero point of a ± 7 mT sensor can deviate by as much as ± 1.12 mT. A baseline of - 300 μT is therefore well within the specs of the sensor. If such a deviation is unacceptable for your application, you have to implement some kind of zeroing yourself. Large offsets are a common issue with hall effect sensors, which is why every hall-based DC current clamp meter has a “Zero” button. *note: (V_Q_MAX - V_Q_TYP) / (V_OUT_MAX - V_Q_TYP) = 0.13 / 0.78 = 0.166666666667

Das steht leider immer noch auf unserer langen Liste unerledigter Dinge. Wenn du noch Fragen hast, kannst du sie aber auch jetzt schon hier im Forum stellen.

Dafür brauchst du auch die Pro. Ohne Zähler hat die Smart hat keine Ahnung, wie viel Leistung dein Fahrzeug tatsächlich zieht.

Wenn es unbedenklich wäre, würden wir es offiziell veröffentlichen. 😉 Falls deine Frage darauf abzielt, ob etwas kaputtgehen kann: Nein. Durch die OCPP-Firmware werden weder dein Fahrzeug, noch deine Wallbox Schaden nehmen. Es könnte nur halt passieren, dass du nicht laden kannst, wenn irgendwas nicht richtig funktioniert. Meine Empfehlung wäre daher, ungenutzte Funktionen beim Bauen der Firmware zu deaktivieren. Dann sollten genug Ressourcen frei sein, damit deine Warp1 auch mit OCPP zuverlässig funktioniert. In der offiziell veröffentlichten Firmware können wir das nicht machen, weil dann ja manch anderen Nutzern eine Funktion fehlt.

@deepflyer911 Nur zur Sicherheit: Der MQTT-Server, zu dem sich deine Wallbox verbindet, ist nicht zufällig ioBroker? Edit: Ich habe gerade in einem deiner alten Posts gefunden, dass du ioBroker benutzt. Edit 2: Das Problem ist, dass sich ioBroker nicht standardkonform verhält und in der Default-Konfiguration Nachrichten per MQTT sendet, die bei der Wallbox verschiedene Probleme verursachen. Mit 2.1.4 ist es prinzipiell möglich, dass die Wallbox endlos von ioBroker neugestartet wird. Ich vermute stark, dass du genau auf dieses Problem gestoßen bist. Mit der noch nicht veröffentlichten Version 2.1.5, die mattsches netterweise bereits für dich gebaut hat, haben wir die häufigste unsinnige Nachricht von ioBroker rausgefiltert und das Problem sollte nicht mehr so leicht auftreten. Unabhängig davon empfehlen wir, ioBrokers MQTT-Option „Publish own states on connect“ immer zu deaktivieren.

Dann passt da wirklich etwas nicht, was du nur per USB rausfindest. Die USB-Schnittstelle habe ich dir unten im Bild markiert. Unter Linux kannst du ein Terminalprogramm deiner Wahl benutzen oder einfach unser „ff“-Script aus dem esp32-firmware git. Was man heutzutage unter Windows empfehlen kann, weiß ich nicht. Putty sollte auch serielle Schnittstellen können. Bitrate ist 115200, alles andere auf Default (8bit, ein Stopbit, keine Parität).

Daran kann man leider nichts Hilfreiches erkennen. Als du das zweite Debug Log runtergeladen hast, lief die Box seit mehr als 2 Minuten. Hattest du sie vorher selbst neugestartet? Angeblich wurde sie die letzten Male immer per Software neugestartet. Falls du keine Neustarts manuell ausführst, fürchte ich, dass man nur über den USB-Port in der Wallbox an irgendwelche hilfreichen Informationen zu den Neustarts kommt. Speicher sieht okay aus. 47 KiB frei ist für eine WARP1 nicht ungewöhnlich. Das Log davor mit weniger Uptime sagt allerdings was von 62 KiB frei. Könnte also auch ein Speicherleck sein. In dem Fall gibt es auch nur über USB irgendwas Hilfreiches.

Wie aktuell ist deine Codebasis? Wir haben am 14.9. etwas Speicher freigeschaulfelt. Wenn du glaubst, nah am Speicherlimit zu sein, nimm mal das „Debug“ Front- und Backendmodul mit rein. Das liefert dir jetzt mehr Informationen zum Speicherverbrauch.

@deepflyer911 Kannst du mal versuchen, ein Debug-Log runterzuladen und hier anzuhängen? Außerdem könntest du versuchen, MQTT-Server und was du sonst noch an Hostnamen irgendwo eingetragen hast, durch statische IPs zu ersetzen. Möglicherweise gibt es ein Problem beim Auflösen von Hostnamen, wenn der ESP gerade am Limit läuft.

Technisch wäre das möglich, aber es wird aktuell nicht unterstützt und es gibt auch keine Pläne dazu. Mit etwas Programmierkenntnissen kannst du dir aber die Warp1-OCPP-Firmware bauen. Die unterstützen wir nicht offiziell, weil du damit entweder den integrierten ESP32-Prozessor hart am Limit fährst oder auf einige der anderen Funktionen verzichten musst, wofür du die Modulliste auf deine Bedürfnisse abstimmen musst. Mit „etwas Programmierkenntnissen“ ist gemeint, dass du nach Anleitung die Entwicklungsumgebung nach einrichten und die Firmware kompilieren musst. Dazu musst du nur die Modulliste anpassen aber keine Zeile Code programmieren.