rtrbt

I see how you can interpret the docs this way: The section about the manual driver installation says

Quote

Windows 8, 8.1 and 10

Since Windows 8 no driver for Bricks is needed anymore. Windows 8 and later recognizes Bricks automatically.

However this only means, that you don't have to install the driver, you still have to install Brick Daemon itself. I've clarified this in the documentation.

10 hours ago, saarnet said:

Könnte man dann prinzipiell nur zwei Phasen anschließen wenn man nur maximal 2-phasig laden möchte?

48 minutes ago, batti said:

Der Box ist prinzipiell egal welche Phasen sie zum Auto "durchschaltet".

Da musst du aber aufpassen: Der Stromzähler in der Pro muss an allen drei Phasen angeschlossen sein, sonst funktioniert er nicht.

Das hängt davon ab, ob die SMA EV 22 OCPP versteht. Prinzipiell wäre der WARP Charger dann aber auch nur ein OCPP Charge Point (lies: ein Client), also selbst wenn die andere Box das auch kann, muss irgendwo noch eine OCPP Central Station (lies: der Server dazu) laufen.

On 6/26/2021 at 11:16 PM, Schobi said:

Ich wollte mal fragen ob es inzwischen ein Update/Zeitplan für das Lastmanagement gibt?

Der aktuelle Zeitplan ist, dass ich Ende der Woche eine Beta-Version davon veröffentliche, mir damit Feedback einhole und dann ein paar Wochen später die fertige Version rausgeht. Der Plan hatte sich ein paar Wochen verschoben, weil wir bei den internen Tests festgestellt haben, dass der Webserver, der auch die HTTP-API für das Lastmanagement hostet, instabil ist. Deshalb musste ich den erst austauschen. Damit liege ich in den letzten Zügen, danach will ich das Lastmanagement noch ein paar Tage laufen lassen und durchtesten, aber ich bin optimistisch, dass das diese Woche noch fertig werden müsste.

Wenn das Lastmanagement läuft, geht es dann an OCPP, damit unsere Charger auch mit anderen Wallboxen zusammenarbeiten können.

Per Knopf heißt in dem Fall "Button im Webinterface" ;)

Schreib am besten eine E-Mail an nicolai@tinkerforge.com und erwähne diesen Thread, dann klärt er alles weitere.

Ich glaube nicht, dass das so einfach funktioniert, theoretisch solltest du zwar durch die Rotation einen systematischen Fehler bekommen, aber da der mehrere Größenordnungen unter dem Rauschen liegt, und du auch gegen den Gyro-Drift kämpfen müsstest. Du kannst dir mal https://stkwans.blogspot.com/2012/11/detection-of-rotation-of-earth.html ansehen, er hat mit einem (scheinbar, habe nicht beide Datenblätter gelesen) vergleichbaren Sensor auf eine andere Weise versucht die Erdrotation zu messen, und schlussendlich hat er es hinbekommen.

Hier übrigens das Datenblatt für das Gyroskop der IMU 1: https://raw.githubusercontent.com/Tinkerforge/imu-brick/master/datasheets/ITG3200.pdf

Moin,

Eventuell hast du einem Defekt an einem der Stapelstecker. Sieh dir die oberen und unteren Stecker beider Bricks mal genau an, sind da irgendwelche Unregelmäßigkeiten? (zum Vergleich, so sollte es aussehen: https://www.tinkerforge.com/de/doc/_images/Bricks/brick_master21_top_800.jpg https://www.tinkerforge.com/de/doc/_images/Bricks/brick_master21_bottom_800.jpg )

Falls du nichts findest, fotografier die Stecker möglichst nah und hochauflösend, eventuell sehen wir dann etwas.

Noch eine Frage zu dem Fehler: Es funktioniert auch nicht, wenn du beide Bricks ohne Bricklets zusammensteckst und anschließt?

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.

16 hours ago, Jhonny said:

Bin gespannt, was eure Tests mit den corsas ergeben und hoffe, dass sich eine Software Lösung finden lässt.

Die Corsas bekommen wir übernächste Woche, ein Ende des im Nebel stocherns ist also in Sicht :)

16 hours ago, Jhonny said:

Vorklimatisieren und zeitversetztes Laden klappen nur, wenn der IEC Status im warp auf "verbunden" steht, aber keine Ladung läuft. Das erreicht man zum Beispiel, indem man das Auto einschlafen lässt (siehe oben) und dann in warp auf Start drückt. Alternativ Automatischen Ladestart aktiviert und den corsa auf zeitversetztes Laden stellt. Stop der automatischen Ladung aus webinterface oder per Taster trennt den IEC, der corsa kann das von sich aus nicht herstellen.

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.

16 hours ago, Jhonny said:

Bei manuellem Ladestart erkennt der corsa nicht, dass er laden könnte, zeitversetztes Laden ist so nicht möglich.

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,

20 hours ago, mhspecial said:

Ich sende die Stromwerte in mA  an "warp/WB1/evse/max_charging_current" im json-Format. 

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.

3 hours ago, duaw said:

Beobachtung: Man kann zu einem Zeitpunkt nur nur einen Listener haben. Wenn unterschiedliche Programm auf das Bricklet zugreifen (z.B. ein parallel geöffneter Brick Viewer), dann ist das Ergebnis erratisch ... 

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.

3 hours ago, duaw said:

C: Ich vermisse in der Doku int led_strip_v2_set_frame_started_callback_configuration(LEDStripV2 *led_strip_v2, bool enable) 

Diese Funktion (und int led_strip_v2_get_frame_started_callback_configuration(LEDStripV2 *led_strip_v2, bool *ret_enable)) ist ja definiert. 

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.