rtrbt

Moin, Prinzipiell hat die IMU neben dem Gyroskop auch ein Magnetometer und Accelerometer und lässt dessen Messungen mit einfließen. Das kannst du über set_sensor_fusion_mode deaktivieren, hast dann aber das Problem, dass die IMU dir nicht mehr die praktischen Euler-Winkel ausgibt, sondern nur noch die Rohwerte Acceleration (vom Accelerometer), Magnetic Field (vom Magnetometer) und Angular Velocity (vom Gyroskop, das wäre dann was dich interessiert). Das Sensorrauschen scheint (experimentell, d.h. ermittelt durch draufsehen im Brick Viewer ;) ) bei ~ +- 0,12°/s zu liegen, du versuchst aber etwas zu messen, was im Bereich von 360°/24h, also ~ 0,004°/s liegt, damit wirst du nicht weit kommen. Für den Bias-Fehler kannst du mal ins Datenblatt des Sensors einen Blick werfen eventuell findest du da die Angabe die du suchst. Ansonsten kann ich nur Psiram empfehlen ;) https://www.psiram.com/de/index.php/Hohlwelt

Moin, debounce ist die Zeit (in ms), die das Bricklet nach einer Flanke weitere Flanken ignoriert. Das ist vor allem wichtig, wenn du prellende Buttons o.Ä. angeschlossen hast. Für den EdgeCount gibt es tatsächlich kein Callback, da musst du den getter benutzen.

Die Corsas bekommen wir übernächste Woche, ein Ende des im Nebel stocherns ist also in Sicht :) Das ergibt alles soweit Sinn. IEC verbunden heißt, dass die Wallbox dem Auto signalisiert, dass Strom verfügbar ist. Das Auto kann dann den Strom anfordern, (z.b. durch das zeitversetzte Laden), dann schaltet die Box das Schütz und lädt. Damit meinst du, dass der Corsa nicht einen Ladestart erzwingen kann, wenn Auto-Start aus ist? (Also der IEC-Statedie ganze Zeit auf A bleibt?) Das ist soweit auch korrekt, weil die Box dem Auto nicht signalisiert, dass Strom verfügbar ist, solange du nicht auf Start drückst.

Außerdem eventuell hilfreich: https://www.warp-charger.com/evcc.html

Moin, Wir verwenden den ESP32 von Espressif, der leider nur die 2,4 GHz-Frequenzen unterstützt. Ist in deiner Umgebung Kanal 13 schon belegt? Viele Geräte können oder benutzen nur 1 bis 11 weil in den USA 12 und 13 nicht zugelassen sind. Eventuell ist deshalb bei dir Kanal 13 noch frei. Der ESP kommt damit zurecht.

Hm ich bin mir unsicher, ob einfach die Detektion dass die Verbindung verloren gegangen ist nicht funktioniert, oder ob der ESP, der das Webinterface hostet, wirklich aus dem WLAN fliegt oder sogar neustartet. Was mich wundert ist, dass du es über den Neustart-Button wiederbeleben kannst, das spräche ja eher dafür, dass der ESP erreichbar ist, aber aus irgendeinem Grund das Javascript denkt, das er das nicht ist. Schick mal bitte einen Debug-Report und ein Ereignis-Log (beides unter System->Ereignis-Log oder http://192.168.2.172/debug_report bzw. http://192.168.2.172/event_log falls das Webinterface hängt) wenn du das Problem gerade erzeugt hast und noch nicht den Neustart-Knopf gedrückt hast.

Hm das sieht soweit gut aus. Ich versuche gerade, das Problem hier zu reproduzieren, aber es funktioniert soweit alles. Kannst du mir einen Minimal-Flow für Node-RED bauen, der das Problem erzeugt? Der angehangene Flow reicht scheinbar nicht. Außerdem helfen eventuell Debug-Report und Ereignis-Log. Funktioniert es über MQTT sinnvoll? Welche Version von Node-RED hast du laufen? flows.json

Moin Michael, Das sieht echt gut aus :) Bezüglich der Graphen kannst du dir die Funktionen set_gui_graph_configuration bzw. set_gui_graph_data ansehen. Damit solltest du die Daten deutlich einfacher anzeigen können, als wenn du mit write_pixels händisch zeichnest. Das GUI-Beispiel legt einen der Graphen an.

Moin, Du musst den Stromwert an warp/WB1/evse/current_limit schicken. evse/max_charging_current kann nur gelesen werden. Prinzipiell sind die Topics, auf die die Wallbox publisht und die, auf denen sie subscribt ist, immer getrennt. Ansonsten würde die Box permanent Nachrichten an sich selbst schicken. Das erklärt aber noch nicht dein Problem mit der HTTP-API/dem Webinterface. Setzt du den Strom per API oder direkt über das Webinterface? und wenn ersteres: Welcher Payload mit welcher Methode (PUT/POST/...) an welche URL? Ich würde das hier gerne mal gegentesten, abschmieren sollte die Box nämlich auf keinen Fall. Funktionieren sollte es, wenn du den Payload {"current":8000} an [dein host]/evse/current_limit mit PUT oder POST schickst und den Content-Type-Header setzt: "Content-Type: application/json"

Cool, danke für den Hinweis :) Habe ich mal im Büro verteilt.

Kurze Frage dazu: Welchen IEC-Zustand (auf der Ladecontroller-Unterseite) hast du, wenn der Corsa angeschlossen ist und nicht lädt? Ist die Box dann schon auf C, oder passiert das erst, wenn du mit dem Schlüssel das Laden anfängst? Zwei Kollegen bekommen voraussichtlich in KW 25 Corsas, wir werden damit auf jeden Fall das Verhalten durchtesten.

Hi Stefan, Sorry dein Post ist bei mir total untergegangen. Ich schreibe die Tage nochmal eine Config zusammen, die alte, die ich mal getestet hatte, finde ich ad-hoc nicht wieder.

Hi, To use any Brick over USB, you have to install Brick Daemon on the connected PC. You can then connect to the daemon over TCP/IP (i.e. use localhost if you run your Python script on the same PC).

Alles was ich bisher dazu sagen kann ist, dass wir das auf dem Schirm haben und warten, was Espressif dazu sagt. Bisher scheint es aber nur folgendes zu geben: https://github.com/espressif/esp-idf/issues/7019

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.