Jump to content

rtrbt

Administrators
  • Content Count

    599
  • Joined

  • Last visited

  • Days Won

    23

Posts posted by rtrbt

  1. Moin,

    On 3/27/2021 at 10:51 AM, Docmac said:

    Daher sollte das ganze sicher sein, da die WB generell noch die Führung im Fehlerfall hat, richtig?

    Die Fehlerbehandlung übernimmt die Wallbox, ja.

    On 3/27/2021 at 10:51 AM, Docmac said:

    Muss ich noch einen WB Reset o.ä. einbauen, wenn ein Umschalten der Phasen erfolgt?

    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
    On 3/27/2021 at 10:51 AM, Docmac said:

    Welche Taktung ist in Hinblick auf WB, Kommunikation mit dem Auto, dem Phasen-Schütz und PV Anlage sinnvoll?

    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.

  2. On 3/27/2021 at 10:14 AM, duaw said:

    Was der ESP32-Brick grundsätzlich anders machen soll als der Red-Brick überblicke ich nicht. 

    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.

    On 3/26/2021 at 2:28 PM, luxor said:

    Ich hoffe das wird sich mit dem ESP32 Brick ändert, dort soll man ja auch eine Art MQTT Proxy laufen lassen können, so das sich die Tinkerforge Bausteine dann Aktiv beim MQTT Sever melden und man nicht mehr das MQTT Binding braucht. Ich hoffe zu mindestens das sich das so verstanden habe

    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.

  3. 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.

  4. Moin,

    Sorry für die späte Antwort, war im Urlaub.

    On 3/28/2021 at 4:19 PM, poohnet said:

    Wenn ich das richtig sehe, dann wird die RS485/ Modbus-Verbindung zum Zähler (zumindest aktuell) ja nur für das Webinterface benötigt, oder?

    Benötigt wird die Verbindung garnicht. Wenn das RS485-Bricklet nicht gefunden wird, deaktiviert das Webinterface den entsprechenden Teil der Oberfläche.

    On 3/28/2021 at 4:19 PM, poohnet said:

    Was haltet ihr davon? Spricht da aus eurer Sicht etwas dagegen (außer vielleicht, dass ich diese Anpassung mit jeder neuen Firmware-Version erneut machen müsste)?

    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.

  5. 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.

     

  6. 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.

  7. 16 hours ago, Tipsy Tinker said:

    Benutze ich cb_all_data wie in den Beispielen gezeigt, kommt der Temperaturwert mit. Möchte ich ihn einzeln haben, so wie hier in meinem Beispiel, bekomme ich ihn nicht aufgerufen.

    Vielleicht hat jemand ne Idee, woran das liegen könnte?!

    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.

    16 hours ago, Tipsy Tinker said:

    Gefühlt gibt es ein Performance-Unterschied zwischen:

    • Alle Werte per Callback erheben, diejenigen die ich benötige loggen

    zu:

    • Nur diejenigen per Callback erheben und loggen, die ich benötige

     

    liege ich da richtig? Und wenn ja, was sind so die gängigen Tricks und Kniffe, um ein möglichst hochfrequentes Loggen von spezifischen Werten zu realisieren ?

    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).

  8. 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.

  9. 17 hours ago, bs. said:

    [16:16:43] Local modules not found in ~/warp-charger/software/esp32-brick/software/modules/backend/authentication/login_page_ignored
    [16:16:43] Try running: npm install

    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.

  10. 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.

  11. Ich meinte damit folgendes: Du kannst die MQTT-Bindings von uns (hier: https://www.tinkerforge.com/de/doc/Software/API_Bindings_MQTT.html) benutzen und die Werte mit der oben verlinkten MQTT-Sensor-Integration von Home Assistant auslesen. Wenn du da etwas runterscrollst kommt eine Erklärung, wie du mit JSON-Daten (das Format benutzen wir für die MQTT-Bindings) umgehen kannst.

    Du musst dann noch die Callbacks der Bricks/Bricklets aktivieren, die du benutzen willst. Dafür kannst du ein init_file schreiben, das ist eine Konfigurationsdatei für die MQTT-Bindings, die initial ausgeführt wird.

    Am besten experimentierst du etwas mit den MQTT-Bindings, Mosquitto mit den mosquitto_pub- und _sub-Befehlen bieten sich da an.

     

    Wenn du wirklich eine native Home Assistent-Anbindung (also ein Binding) schreiben willst: das ist vom Aufwand her vergleichbar mit den openHAB-Bindings in die ich schon ungefähr 9 Monate Arbeit versenkt habe, da würde ich dir eher von abraten.

  12. Ah ja, da bist du gerade auf einem Zwischenzustand, weil ich noch lokale Änderungen rumliegen habe. Die Authentication ist ja gerade in Arbeit. Folgendes sollte immer funktionieren: Ich tagge die Repositories immer (beim esp32-brick habe ich es bei den ersten Versionen vergessen, die Tags trage ich die Tage noch nach) mit der entsprechenden Firmware-Version. D.h. wenn du im esp32-brick-Git

    git checkout warp-1.1.1

    und im warp-Charger git

    git checkout v1.1.1

    ausführst, sollte der Stand zueinander passen.

  13. Moin Thomas,

    Kurz als Überblick: Die WARP-Charger-Firmware ist dreigeteilt in die esp32-lib, die grundlegende Funktionen bietet (und vorkompiliert werden kann), die esp32-brick-Firmware, aus der die WARP-Charger-Firmware einige Module für das Webinterface übernimmt (die aber auch selbst eine eigene Firmware für den Brick ist) und die warp-charger-Firmware selbst, die den ganzen WARP-spezifischen Teil enthält.

    Tatsächlich lässt sich die reine ESP32-Brick-Firmware gerade nicht bauen, weil ich Änderungen in esp32-lib gemacht habe, die in die WARP-Firmware mitgezogen habe, aber die ESP32-Firmware noch nicht aktualisiert habe. Das schleift etwas, weil ich die ESP32-Firmware Stand jetzt fast nie direkt baue, wir verkaufen den Brick ja noch nicht einzeln.

    Wenn du dich spezifisch mit der Wallbox-Software beschäftigen willst, musst du im esp32-brick nichts kompilieren, sondern es reicht, das warp-charger-Git zu klonen, dann in dessen software-Ordner das esp32-brick-Git zu klonen (oder zu symlinken). Die esp32-lib wird von platformio automatisch runtergeladen.

    Grüße,
    Erik

  14. Teste mal bitte die Version im Anhang. Du kannst damit jetzt Strings als Zahlen übergeben (sogar mit z.b "0xCAFE", "0o777" und "0b1001" hexadezimal, oktal und binär).

    Außerdem kannst du den Bindings das Argument "--int64-as-string" mitgeben, dann werden 64-Bit-Zahlen stattdessen als String in das JSON-Objekt eingefügt, damit du immer das JSON parsen kannst (und dann komfortabler damit arbeiten).

    tinkerforge_mqtt_bindings_2_0_14_8f0ac4c1.zip

  15. Den ESP32 Brick gibt es, aber wir verkaufen ihn noch nicht. Stand jetzt werden leider alle, die bereits produziert sind, für die Wallboxen gebraucht.

×
×
  • Create New...