rtrbt

Tut mir leid, das wird noch etwas dauern. Ich bin noch voll ausgelastet mit der Wallbox-Firmware. Das Lastmanagement ist aber fast fertig, es geht also etwas voran.

Der Typo ist gefixt, sollte bald in der Dokumentation behoben sein. Du solltest prinzipiell mehrere Programme ausführen können, die sich auf das selbe Callback/den selben Listener registrieren. Probleme gibt es erst, wenn mehrere Programme das Callback umkonfigurieren, also z.B. set_frame_duration auf unterschiedliche Werte setzen. Das ist aber prinzipiell erwartet, das LED Strip Bricklet kann ja nur einen Bildstrom auf einmal zeichen. Diese hier?

In die Richtung gibt es tatsächlich Pläne. Wir benutzen für die Wallboxen bereits den ESP32-Brick, den wir bald auch einzeln verkaufen. Mit dem Brick und den C/C++-Bindings für Mikrocontroller (die Beta gibt es hier) kannst du Bricklets steuern. Wenn das beides veröffentlicht ist, steht noch auf meiner Liste, mich mit MicroPython zu befassen, um zu sehen ob man Bindings dafür schreibt. Eventuell einfach als Wrapper der C/C++-Bindings für Mikrocontroller. Die Python-Bindings haben kein eigenes Repo, da sie von unserem (auch in Python geschriebenen) Bindings-Generator erzeugt werden. Den Generator findest du hier: https://github.com/Tinkerforge/generators. Du wirst dir aber aus den "normalen" Python-Bindings nicht trivial MicroPython-Bindings bauen können, da sie immer über eine TCP/IP-Verbindung mit einem Brick Daemon kommunizieren.

Hi, Da geht einiges durcheinander: Du musst die Konstanten wie MODE_READER usw nicht neu definieren, das hat keinen Effekt. Das NFC-Bricklet funktioniert wie ein Zustandsautomat. Du musst also die Zustandsübergänge auslösen bzw. abwarten. An der jeweiligen Funktion, ist dokumentiert, welche Zustände du durchlaufen musst. Vergleiche am besten mal die Dokumentation von z.B. reader_write_page und dem Write Read Type2-Beispiel. Folgender Abschnitt der Hardware-Doku erklärt das auch nochmal. Die Beispiele benutzen alle das state_changed-Callback als Signal, dass sich der Zustand des NFC-Bricklets geändert hat. Das würde ich dir auch empfehlen. Wenn deine Programmstruktur das nicht zulässt, kannst du auch (blockierend) den Zustand immer wieder abfragen, bis er sich ändert. (dann mit nfc.get_state() in einer Schleife) Du versuchst die GPS-Koordinaten als Text als NDEF-Record zu schreiben, NDEF-Nachrichten haben aber ein spezifisches Format, vermutlich musst du stattdessen eine Page direkt schreiben. Das wird bei Typ-2-Tags aber knapp, wenn ich unsere Hardware-Doku richtig verstehe, hast du pro Page 4 Byte Platz, du müsstest also für Breiten- und Längengrad (binär, nicht als Zeichenkette) jeweils eine Page verwenden und noch eine für die Vorzeichen von beidem.

The Isolator Bricklet is compatible with the HAT Zero. The docs are a bit outdated in this case, as they often assume, that all Bricks come with the 10p connector.

Hi, Zeige am besten mal, wie du das Beispiel verändert hast, sowas sieht man "am Objekt" am besten.

Maybe. As a simple test, you could build a minimal setup with only the bricklet and the probe (attached to the HAT and Pi or, if you have one, a Master Brick) without an enclosure, connect to the Brick or Pi with Brick Viewer and see if the bricklet gets stuck again. Of course this depends on how often the errors happen.

Hi, Do you see any activity on the error state callback while the value is stuck? The firmware does not update the temperature value while the open circuit error is set.

Du kannst dir unsere "geheime" EVCC-Anleitung ansehen, die sollte in den nächsten Tagen öffentlich werden: https://www.warp-charger.com/evcc.html

Mit den Einstellungen sollte es klappen, ja. Ja sollte sie. Die Wallbox unterscheidet (inzwischen) zwischen nicht empfangenen Werten und 0 W. Du kannst dann entweder die Graphen ansehen, oder unter [wallbox-ip]/meter/state und /meter/live die Rohdaten auslesen.

Moin Gustav, Ich habe in der Anleitung die Herstellerangaben für Kabeldurchmesser (11-21mm) und Anzugsdrehmoment (10 Nm) eingefügt, danke nochmal für den Hinweis. Warum in deinem Fall die Kabel nicht gehalten wurden ist uns aber unklar.

Hast du bei beiden Extensions das kurze schwarze Kabel? Ich habe hier erst mit einer älteren getestet, die hatte das längere graue Kabel, wie es oben abgebildet ist. Bei denen die wir noch im Lager haben ist aber auch das kürzere schwarze verbaut. Damit funktioniert es bei mir auf dem Tisch aber trotzdem. Die AP-Geschichte habe ich auch getestet, das klappt mit deiner Konfiguration manchmal, manchmal kann ich den Startup Error aber auch erzeugen. Falls du nicht dringend auf die Möglichkeit eine externe Antenne anzuschließen angewiesen bist, würden wir dir beide Extensions gegen die 2.0-Variante umtauschen. Damit scheint dein Setup ja zu funktionieren. Schreibe dazu mal eine Mail an sales@tinkerforge.com, mein Kollege klärt dann alles weitere.

Moin, Ich habe hier gerade mit einer 1.0 und einer 2.0 getestet und hatte mit beiden vergleichbaren Empfang. Es gibt auch keine Erfahrungswerte, dass die alte Extension deutlich schlechteren Empfang hätte. Deshalb erstmal folgende Fragen: Steckt der UFL-Stecker auf dem Bricklet richtig? Hast du die Probleme auch mit anderen APs? Du könntest z.B. eine der alten Extensions als Access Point betreiben und dann mit der anderen btw. der 2.0 testen.

Mit einer Bluetooth-Freischaltung habe ich tatsächlich schon experimentiert, bin dabei aber über zwei Probleme gestolpert: Ist es nicht so einfach eine Bluetooth-Profil zu finden, zu dem sich die Smartphones automagisch verbinden. Ich habe dafür erstmal ein HID genommen, dann ist die Wallbox aus Sicht des Handys ein Controller mit einem Button. Das ist aus Anwendersicht etwas unschön bis verwirrend aber eventuell gut genug. Was ich genau für ein Profil nehme ist aus Wallbox-Sicht egal, da ich außer dem Verbindungsaufbau keine Daten austauschen will. Der Bluetooth-Stack frisst ziemlich viel Arbeitsspeicher auf dem ESP. Das ist das Hauptproblem, weswegen ich das ganze erstmal nach hinten verschoben habe. NFC zu untersuchen ist noch auf der TODO-Liste, sowohl bezüglich Software, als auch der Hardware-Platzierung. Wenn sich das jemand von euch selbst bauen will, sollte das mit dem NFC-Bricklet relativ einfach möglich sein, man muss halt ein Firmware-Modul dafür schreiben, das im Endeffekt den Auto-Start (de)aktiviert. Ob und wenn ja wann es da etwas offizielles gibt kann ich aber noch nicht sagen, nicht wegen Geheimniskrämerei, sondern weil wir das auch noch nicht genau wissen.

Moin, Da sind die Beispiele in der API-Dokumentation schlecht. Unter Windows funktioniert das nur, wenn du alle einfachen Anführungszeichen durch doppelte ersetzt und die "verschachtelten" (also die im JSON-Payload) mit \ escapst, zum Beispiel so: curl -H "Content-Type: application/json" -X PUT -d "{\"current\": 8000}" 192.168.0.62/evse/current_limit

Der Unterschied zwischen vehicle_state und iec61851_state ist nur, dass, wenn du auto_start deaktiviert hast, der iec_state 0 meldet (also "A" bzw. "nicht verbunden"), weil das aus Sicht des Autos so ist. Der vehicle_state sagt aber trotzdem 1 (also "verbunden"), das ist gewissermaßen die Sicht der Wallbox. Damit kannst du detektieren, ob ein Auto da ist, ohne dass du das Laden freigibst.

Coole Sache :) Zwei Fragen dazu: Hast du die Stromverbrauchswerte irgendwo vertauscht oder einen komischen Zähler? Mich wundert gerade, dass der zurücksetzbare Stromverbrauch (lies: energy_rel btw. Register 389) höher ist als der nicht zurücksetzbare (lies: energy_abs bzw. Register 73). Das bringt keinen um, ist mir nur aufgefallen. Das die Live-Ansicht so "lang" ist liegt daran, dass du weniger oft abfragst? Oder hast du dir mehr Live-Historie gegönnt?

Moin, Die Fehlerbehandlung übernimmt die Wallbox, ja. Einen Reset solltest du nicht brauchen. Es sollte reichen, wenn du: Die Ladung beendest (falls eine lief), Sicherheitshalber auto-start ausmachst (das solltest du sowieso deaktivieren, wenn du abhängig von deiner PV-Leistung selbst steuern willst wann geladen wird) Wartest bis du iec_state 0 (also A) siehst Dann die Phasen ab/zuschaltest Wartest dass dein Schütz geschaltet hat Dann das Laden wieder startest Das musst du mit deinem Aufbau ausprobieren. Je nach Trägheit des Autos würde ich eher schätzen, dass der Bereich 5 bis 10 Sekunden sinnvoll ist. Du kannst natürlich öfter den Ladestrom nachjustieren, aber wenn das Auto da nicht hinterher kommt hast du nicht viel davon, weil es praktisch deine Reglung glättet.

Stimmt.

Moin, Testet mal bitte diese Version. Wir hatten das Zertifikat für den Download-Server gewechselt, der Brick Viewer hat aber noch die alte Zertifikatskette mitgeliefert. Deshalb konnte er keine TLS-Verbindung aufbauen.

Grundlegend ist der Vorteil des ESP32-Bricks, dass du kein Linux darauf hast, sondern direkt mit der Hardware reden kannst, z.B im Arduino-Stil. Da verwechselst du Dinge. Der ESP32 Brick hat einen Proxy-Modus, was aber nicht über MQTT läuft, sondern das normale Tinkerforge-Protokoll. D.h. du kannst ihn genau wie alle anderen Bricks verwenden und z.b. dich mit dem Brick Viewer darauf verbinden. Deshalb funktionieren dann auch die MQTT-Bindings damit. Aktiv macht der Brick aber nichts über MQTT, es sei denn man schreibt eine entsprechende Firmware.

Moin, Stand jetzt kannst du das nicht einstellen. Die Wallbox schickt MQTT-Nachrichten nur bei Änderung der Werte, prüft aber jede Sekunde auf Änderungen, auch damit das Webinterface nicht extrem langsam ist (das Webinterface benutzt bis auf MQTT selbst die selben Mechanismen). evse/state und ein paar andere Topics beinhalten Werte, die sich praktisch immer ändern (z.B. die Uptime), deshalb bekommst du jede Sekunde eine Nachricht. Ich habe noch auf der TODO-Liste mir zu überlegen ob und wenn ja wie man das limitieren kann.

Moin, Sorry für die späte Antwort, war im Urlaub. Benötigt wird die Verbindung garnicht. Wenn das RS485-Bricklet nicht gefunden wird, deaktiviert das Webinterface den entsprechenden Teil der Oberfläche. Prinzipiell sollte dein Plan funktionieren. Die eModbus-Bibliothek sollte sich gut in die Firmware einfügen, PlatformIO und AsyncTCP benutzen wir auch. Wenn du dir das sdm72dm-Modul aus der Firmware umschreibst und die API einhältst (also sowohl die des Moduls, als auch die "nach außen", meter/state und so) sollte das funktionieren. Die interne API zwischen den Modulen ist Stand jetzt nicht stabil, aber ich erwarte da keine größeren Änderungen.

Moin, Der Zähler gibt einen Messwert mit bis zu 3 Nachkommastellen aus (also 0,001 kWh = 1 Wattstunde). "Bis zu " weil es ein float ist, Nullen hinten werden also abgeschnitten. Die Wallbox reicht die Messwerte des Zählers unverändert weiter.

Hi Gustav, Ich habe deine Anmerkungen mal in die Anleitung eingepflegt. Die aktuelle Version findest du hier: https://www.warp-charger.com/documents/WARP_Betriebsanleitung.pdf