Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.391
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

rtrbt hat zuletzt am 8. Februar gewonnen

rtrbt hat die beliebtesten Inhalte erstellt!

Über rtrbt

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

rtrbt's Achievements

Experienced

Experienced (11/14)

  • Dedicated Rare
  • Reacting Well Rare
  • Very Popular Rare
  • Conversation Starter
  • First Post

Recent Badges

194

Reputation in der Community

  1. It seems like kernel 6.6 changed the GPIO numbers again. https://github.com/raspberrypi/linux/issues/6037 We have to update Brick Daemon for the new GPIO numbers, probably next week.
  2. Wir haben hier ein paar von denen https://www.meatpi.com/products/wican rumliegen. Leider hatte bisher noch keiner Zeit, die Anbindung dafür zu implementieren.
  3. Der Charge Tracker benutzt die nicht zurücksetzbaren Werte. D.h. du brauchst die 209 wenn du seit Firmware 2.2.0 mindestens einmal die aufgezeichneten Ladevorgänge gelöscht hast. Falls du noch ältere Ladevorgänge hast, benutzt der Charge Tracker den Wert 213 Energy Active LSum ImExSum statt ... Import, also die Summe aus Import und Export. Das hatten wir in 2.2.0 geändert, aber damit in den Ladelogdateien kein Sprung entsteht, passiert der Wechsel erst wenn die Ladevorgänge einmal geleert werden. Siehe hier: https://www.tinkerforge.com/de/blog/new-features-in-warp2-221-and-wem-202/ (ganz unten) Wichtig, weil du das so geschrieben hast: 209 usw. sind nicht direkt Indices in meters/0/values, sondern am Index an dem in meters/0/value_ids die 209 steht, steht in /values der entsprechende Wert.
  4. Direkt geht das nicht. Du kannst aber über MQTT ein NFC-Tag vortäuschen: https://www.warp-charger.com/api.html#nfc_inject_tag Wenn OCPP dieses Tag kennt, sollte dann ein Ladevorgang beginnen.
  5. Im Moment geht das nicht so einfach. Wir haben aber vor zukünftig das Format der aufgezeichneten Ladevorgänge nochmal zu ändern. Dabei würde ich pro Ladevorgang ein Flag vorsehen, dass angibt, dass er gelöscht ist. Siehe hier: https://github.com/Tinkerforge/esp32-firmware/issues/329
  6. Teste mal diese WARP2-Firmware: Wenn das Auto nach der 4-Sekunden-Trennung nicht aufwacht, trennen wir jetzt nochmal für 30 Sekunden. Damit sollte es nicht mehr notwendig sein, dass du die Trennung des WEMs verlängerst. Hier hat jemand ein ähnliches Problem:https://github.com/evcc-io/evcc/issues/12480 warp2_firmware-NIGHTLY_2_2_1_65dca55f_2aa5b51ad4b2067_merged.bin
  7. Das ist sehr seltsam. Kannst du das nochmal machen und dabei ein Ladeprotokoll ziehen? (Also Auto normal laden lassen, dann Protokoll starten, dann Auto abziehen und warten, dass auf 2, aber nicht auf 0 gewechselt wird)
  8. This won't work. Android smartphones periodically change the NFC tag ID. The only way to change this (as far as I know) is to use some kind of NFC card emulation app that (depending on your smartphone) will only work if you root your phone. See for example here: https://stackoverflow.com/questions/19764476/host-based-card-emulation-with-fixed-card-id We've thought about not using a tag's ID but instead the first payload page (see here: https://github.com/Tinkerforge/esp32-firmware/issues/90) but nobody had the time to implement this yet.
  9. Sorry, ich hatte überlesen, dass du ein selbst-signiertes Zertifikat hast. Wenn du die Firmware mit dem Certs Back- und Frontend-Modul kompilierst, dann kannst du auf dem Webinterface das selbst-signierte Zertifikat hochladen und für die MQTT-Verbindung auswählen. Ohne das Certs-Modul wird nur das eingebettete Zertifikatsbundle verwendet. Das ist eine Sammlung von Root-Zertifikaten, mit denen der ESP Verbindungen zu Servern mit "echten" (also nicht selbst-signierten) Zertifikaten aufbauen kann: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_crt_bundle.html
  10. @Makee Da du ja eine eigene Firmware baust: Ich habe den MQTTS-Support gerade gepusht. Sollte jetzt einfach funktionieren.
  11. Du hast zwei Möglichkeiten: 1. Kannst du die ganze Standardfirmware ignorieren und dir einen "normalen" Arduino-Sketch schreiben. Dokumentation dafür findest du hier: https://www.tinkerforge.com/de/doc/Software/API_Bindings_uC_HAL_Arduino_ESP32_Brick.html bzw. für den ESP32 Ethernet Brick hier:https://www.tinkerforge.com/de/doc/Software/API_Bindings_uC_HAL_Arduino_ESP32_Ethernet_Brick.html Das ist für den Anfang einfacher, du musst aber die Netzwerk- und MQTT-verbindungen von Hand aufbauen oder dir eine MQTT-Bibliothek suchen. 2. Kannst du dir die ESP-Firmware erweitern, dafür haben wir hier: https://www.tinkerforge.com/de/doc/Tutorials/Tutorial_ESP32_Firmware/Tutorial.html#tutorial-esp32-firmware ein Tutorial. Du müsstest im Endeffekt das Mqtt-Modul reinkompilieren (bei den custom_backend_modules und custom_frontend_modules jeweils zu der Liste hinzufügen) und dir ein eigenes Modul schreiben, dass die Sensoren ausliest und die Daten in eine API schreibt. Das ist im Tutorial Phase 2. APIs werden sowohl für die Kommunikation mit dem Webinterface über HTTP, als auch für MQTT verwendet. Das sollte also automatisch funktionieren. Der restliche Teil der Implementierung ist dann relativ ähnlich zu dem Arduino-Sketch den du dir in Variante 1 geschrieben hättest. In beiden Fällen benutzt du die C/C++-Bindings für Mikrocontroller für die Kommunikation mit den Bricklets (wir haben für jedes Bricklet Beispiele!), der Teil sollte also mehr oder weniger identisch aussehen.
  12. Das geht prinzipiell, indem du dir mehrere Regeln mit der selben Bedingung erstellst. Ist nicht super-hübsch, funktioniert aber. Das wiederum geht mit der aktuellen Implementierung nicht. Wir haben das erstmal einfach gehalten, für Use-Cases wie eine Zeitschaltung o.Ä. Prinzipiell immer, ich kann aber nicht versprechen, dass wir die dann auch umsetzen ;)
  13. rtrbt

    Veröffentlichungen

    Firmwares: WARP 2.2.1, WARP2 2.2.1 und WARP Energy Manager 2.0.2 HTTP-API-Fehler bei schlechter Verbindungsqualität behoben Zeitzonen-Datenbank aktualisiert (nur WARP2) Repariert, dass DC-Fehler sporadisch auslöste (durch Update auf Ladecontroller-Firmware 2.2.2) SunSpec: Herstellerspezifische Modelle werden nicht mehr als unbekannt angezeigt SunSpec: Hängenden Scan unter spezifischen Fehlerbedingungen behoben SunSpec: Hinzugefügt, dass Scan abgebrochen wird, wenn Browser-Tab geschlossen wird (nur WARP Energy Manager) Hinzugefügt, dass externe Phasensteuerungsanforderungen über Neustarts hinweg erhalten bleiben (nur WARP2) OCPP: LED-Steuerung hinzugefügt (nur WARP2) OCPP: Antworten auf Server-Anfragen repariert (nur WARP2) OCPP: Anzeige abgelehnter NFC-Tags zum Status hinzugefügt (nur WARP2) OCPP: Wiederherstellung von Transaktionsnachrichten über Neustarts hinweg repariert (nur WARP2) OCPP: Meldung falscher Zählerstände bei Transaktionsende über Neustarts hinweg repariert Download: WARP 2.2.1 bzw. WARP2 2.2.1 bzw. WARP Energy Manager 2.0.2
×
×
  • Neu erstellen...