rtrbt

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

Hi, I don't think so, sorry. Finishing the binding will take some time, I would estimate about two to four weeks. So it is not really squeezeable. I will continue to work on the binding as soon as the heap of tasks for our charging station is done.

Moin, Gibt es leider nicht. Wenn du nur Pixel zeichnest, kannst du die Koordinaten flippen, bei Text müsstest du auf eine Bitmap-Schrift umsteigen und die selbst zeichnen.

Gemergt. Ich biege die Partitionstabelle noch etwas um, das große SPIFFS brauchen wir Stand jetzt nicht und bei ESPs die man zur Entwicklung nutzt ist es kein Problem die Partitionstabelle noch umzuändern. Andere Frage: Wenn du bei dir die upload_port-Zeilen beide auskommentierst, funktioniert dann die Auto-Detection? Dann würde ich das so in die ini packen, damit man nicht seine seriellen Ports jedes Mal anpassen muss.

Firmware: IMU 2.0 Brick 2.0.15 Fixed response size of the temperature callback Download: IMU 2.0 Brick

Firmware: IMU 2.0 Brick 2.0.15 Größe des Antwortpakets des Temperature-Callbacks repariert Download: IMU 2.0 Brick

Das war ein Firmware-Bug, mit der frisch veröffentlichten 2.0.15 geht es bei mir. Hintergrund war, dass die Größe des Antwortpakets zu groß war (copy-paste-Fehler, es hat die Größe des AngularVelocityCallbacks benutzt). Die Bindings prüfen die Länge von Callback-Paketen und ignorieren zu kurze und zu lange Pakete, deshalb kam bei dir nichts an. Da gibt es tatsächlich Unterschiede: Die Bricks und Bricklets laufen mit einer Tickrate von 1 kHz. Pro Tick kann nur ein Paket erzeugt werden. Wenn du also Werte aus zwei Callbacks brauchst, kannst du jeden Wert nur noch mit 500 Hz auslesen. Aus Brick-Kommunikationssicht ist es also tatsächlich sinnvoller, das AllData-Callback zu benutzen und die Werte wegzuwerfen, die du nicht brauchst. Wenn du über ein Netzwerk gehst kann das natürlich anders aussehen, aber wir reden hier immer noch von sehr kleinen Datenmengen (z.b. beim AllData-Callback 54 kB/s).

Das OLED kann von sich aus nur die eine Textgröße darstellen. Die großen Zahlen für das Beispielvideo werden als Bild gezeichnet: https://github.com/Tinkerforge/oled-128x64-bricklet/blob/master/software/examples/python/example_draw_servo_poti.py Etwas ähnliches müsstest du dann auch machen. Du könntest dir zum Beispiel eine Bitmap-Font suchen oder Text mit einer Graphikbibliothek rastern und dann die Pixel auf das Display schieben.

Moin, Das Voltage/Current kann nur positive Spannungen messen. Du kannst alternativ aber das Industrial Dual Analog In 2.0 Bricklet verwenden, wenn es dir reicht die Spannung zu messen. Wenn du auch den Strom brauchst wird es schwierig.

Hi, You are correct, this is a leftover from the Motion Detector 1.0. Fixed here: https://github.com/Tinkerforge/generators/commit/00d5353862f06851fae593b603d4948fed0c1b5c The change will show up in the documentation when we build it the next time. For the Motion Detector 2.0, you indeed have to control the indicator LEDs yourself.

Ah das ist das Problem. Geh mal in den Ordner ~/warp-charger/software/esp32-brick/software/modules/backend/authentication/login_page_ignored und führe npm install aus. Da die Login-Seite separat vom Rest gebaut wird, braucht sie auch eine eigene Installation des ganzen Javascript-Haufens. Ich teste hier mal, ob es eine gute Idee ist den Befehl über das prepare-Script immer auszuführen oder ob das den Build-Prozess unnötig verlangsamt. Die anderen Typescript-Fehler kannst du ignorieren, da ist die Typprüfung nicht ganz zufrieden, das funktioniert aber.

Hast du davor noch mehr Fehlerausgabe? Das Authentication-Modul im esp32-brick bringt eine eigene Login-Seite mit, die in genau diese Datei gepackt werden sollte. Eventuell ist das bei dir schiefgegangen. Falls du das debuggen willst: Der Prozess ist etwas kompliziert. Ich benutze die pio_hooks.py um mich in den PlatformIO-Buildprozess reinzuhängen und die konfigurierten Module nach src/modules zu kopieren (Sowohl die aus warp_charger/software/modules als auch die aus dem esp32-brick). Wenn in einem Modul eine prepare.py liegt führe ich die davor aus, um damit z.B. die Loginseite zu erstellen.