Jump to content

rtrbt

Administrators
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    1.401

  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

 Inhaltstyp 

Posts erstellt von rtrbt

    Anmeldung an Warp1 nach FW Update 1.3.0 nicht mehr möglich

    in WARP Charger

    Geschrieben

    Okay, ich kann das Problem hier nachstellen: Das Update von 1.2.4 auf 1.3.0 wechselt ja unter anderem den ganzen Webserver aus. Der neue Webserver hatte keinen Support für die Login-Variante die wir benutzen, deshalb hatte ich das nachimplementiert. Dabei habe ich aber die Realm von asyncesp auf esp32-lib geändert. Firefox versteht jetzt nicht, dass er sich auf die neue Realm einloggen muss. Interessanterweise hat Firefox die neue Realm bei mir aber akzeptiert, als ich ihn neugestartet habe.

    Wenn du über Edge noch das Webinterface erreichst, kannst du den Login deaktivieren, neustarten, dann einmal mit Firefox draufgehen (damit er vergisst, dass man sich einloggen muss), dann Firefox neustarten und den Login wieder aktivieren. Ich würde erwarten, dass das dann wieder funktioniert.

    Unabhängig davon kommt in Version 1.3.1 ein Fix dafür: Der Webserver akzeptiert dann einfach sowohl die alte, als auch die neue realm.

    Danke für's melden!

    Anmeldung an Warp1 nach FW Update 1.3.0 nicht mehr möglich

    in WARP Charger

    Geschrieben

    Das sollte natürlich nicht passieren. Mit welchem Browser (und welcher Version) hast du das getestet? Von welcher Firmware-Version bist du auf die 1.3.0 gegangen? Ich würde das gerne hier reproduzieren, damit ich einen eventuellen Bug fixen kann.

    Notfalls retten kannst du das ohne Reset, indem du per MQTT den Login deaktivierst: https://www.warp-charger.com/api.html#reference-authentication

    Warp2: Externer RFID-Leser

    in WARP Charger

    Geschrieben

    11 hours ago, Gunner said:

    Ich hätte aber gerne den RFID-Reader extern. Kann das Bricket in ein externes Gehäuse und durch ein Kabel verlängert werden? Wie lang darf eine solche Verlängerung sein?

    Prinzipiell kannst du das NFC-Bricklet extern verbauen, musst dann aber selber eine Kabeldurchführung in das Wallbox-Gehäuse bohren. Die maximale Kabellänge sind 2 Meter, du kannst aber ein Isolator-Bricklet dazwischenhängen, das frischt u.A. das Signal wieder auf, dann kommst du auf 4 Meter.

    Wichtig: Isolator-Bricklets kannst du nicht hintereinander schalten, d.h. mehr als 4 Meter werden es nicht. Außerdem funktioniert der Isolator-Hack nicht mit der aktuellen Wallbox-Firmware, weil der Code noch einen Bug hat, den ich gerade gefixt habe. Du müsstest dann auf das nächste Firmware-Release warten, bevor du das Bricklet einbaust.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Moin,

    Das Hauptproblem ist tatsächlich, dass

    On 11/5/2021 at 11:00 AM, StefanOHAN said:

    So wie ich das in Erinnerung habe, ist da nicht mehr soviel zu tun (z.B Einbau der Soft-Reset-Funktion der Bricklets ...)

    nicht 100%ig stimmt. Ich bin mal die noch offenen Punkte durchgegangen, folgendes wäre noch zutun:

    • Features
      • Allgemein
        • Deutsche Dokumentation
        • Advanced-Mode: Device führt dann keine Channels mehr raus, aber den kompletten Satz Java-API als Actions.
        • Konfiguration per Textdatei
        • Reset als Action rausführen
      • Device-Spezifisch
        • Thermal-Imaging: Neue Config-Parameter
        • LED Strip: ColorCommands akzeptieren, den Rest per Rule
        • Ambient Light v2/v3: Auto-Modus der Sättigung/Integrationszeit einstellt
        • Neu hinzugefügte API einfügen, z.B. Barometer I²C-Mode
      • Device-Gruppen-Spezifisch
        • Motorbricks wie DC-Brick bauen
        • Default-Werte des Update-Intervals kleiner machen wenn value_has_to_change verwendet wird, 1000ms sind gerade für IO-16 recht lang
        • Things mit Error-LEDs: Trigger-Channel hinzufügen, der nur im Show-Error-Modus der LED erzeugt wird, der Channel resettet die LED, indem setErrorLEDConfiguration(ShowErrors) nochmal aufgerufen wird.
        • Switch->Contact beim IO4/16 usw. Problem: Braucht Generatoränderungen
      • Dokumentation
        • Allgemeines Tutorial: Installation, Konfiguration von: Outdoor Weather Station, Remote Switch, LCD 128x64, irgendein normales Bricklet. Damit zeigen wie die "speziellen" Bricklets funktionieren, wie man sinnvoll Rules schreibt usw.
        • Outdoor Weather Station: relative rain fall example (https://www.tinkerunity.org/topic/5092-outdoor-wetter-station/?tab=comments#comment-28855)
        • in der API-Doku explizit erklären wie man einen Brick Daemon hinzufügt nach "You can then connect the bindings by adding a Brick Daemon thing in openHAB's Paper UI."
    • Bugfixes
      • Prüfen ob alle Callbacks deaktiviert werden
      • https://github.com/openhab/openhab-core/issues/1265 (Actions sind nach Binding-Neustart kaputt)
      • https://github.com/openhab/openhab-core/issues/1233 (Uneindeutige Actions, wird von openhab-core nicht gefixt, heißt die Bricklet-Prefixe sind für die Ewigkeit)
      • dispose-Code dauert ewig/timeouts wenn Device ab ist
      • Display Bricklets zeigen auf der Übersichtsseite, solange noch kein Text gesendet wurde, '-' als Text an, wenn darauf geklickt wird NULL.
      • Read-Only Flags in den Channel-Typen setzen. Auto-Deduce?
      • Zip so bauen dass das zip-diff script funktioniert, also nicht nur unterorder einpacken
      • Reachabilitycheck doch single-threaden? Im Moment funktionierts, aber wenn jemand >= 5 Brick Daemons benutzt kann es doch passieren, dass die Threads lahmgelegt werden. Alternativ: Nicht blocken auf "sind die futures alle fertig" sondern pollen und yielden. Dann kann der Thread selbst die Tasks abarbeiten. Außerdem die "Burstigkeit" des ganzen verringern.

    Dinge die durchgestrichen sind, würde ich jetzt droppen, damit man zu einem sinnvollen Abschluss kommt und das nicht noch Monatelang Vollzeitentwicklung ist. Dinge die kursiv sind, kommen vielleicht, das hängt konkret davon ab, wie viel Arbeit ich reinstecken muss/kann/will.

    Ich werde dann jetzt voraussichtlich immer ~ einen Tag die Woche in die Bindings stecken, da die Liste so zusammengestrichen ist, sollte das dann nicht Monate dauern, bis eine "fertige" Version dabei rausfällt.

    • Like 2

    Ablauf bei Änderungen an EVSE-Bricklet

    in WARP Charger

    Geschrieben

    Damit ich das kurz eingeworfen habe: Wir haben letzte Woche die Struktur der Firmware vereinfacht. Du findest den aktuellen Kram jetzt nicht mehr im warp-charger-Git sondern hier: https://github.com/Tinkerforge/esp32-firmware

    Das ist in Endeffekt der Inhalt der esp32-lib, und der software-Verzeichnisse von esp32-brick und warp-charger zusammengelegt. Im Idealfall kannst du deine Änderungen darauf übernehmen und alles funktioniert wie bisher weiter, nur mit weniger Verrenkungen, weil nicht mehr der Zustand von 3 Git-Repos auseinanderlaufen kann.

    WARP in Home Assistant via MQTT und HTTP-API

    in WARP Charger

    Geschrieben

    On 11/13/2021 at 8:02 AM, floho said:

    Mein Vorschlag: Auch wenn das eher eine niedrige Priorität hat, vielleicht lässt sich in Zukunft auf der MQTT Seite eine erweiterte Konfig vornehmen:

    • Sendeintervall
      • abhängig vom Zustand der Wallbox. Z.B. im Idle jede Minute, während des Ladevorgangs weiter sekündlich
      • abhängig von der Variable. Z.B. aktuelle Ladeleistung sekündlich, erkannte Tags eher langsamer.
      • ... 
    • Zusammensetzung des Topic
      • An- und Abwählen der einzelnen Bestandteile
      • verschiedenen Formate
      • ...

    So oder so ähnlich habe ich es auf die TODO-Liste gegossen ;) https://github.com/Tinkerforge/esp32-firmware/issues/36

    Ablauf bei Änderungen an EVSE-Bricklet

    in WARP Charger

    Geschrieben

    Moin Matthias,

    Zu Frage 1 und 2:

    Wenn du die Firmware nicht aktualisieren willst, kannst du dir den ganzen DeviceModule-Kram sparen. Das hatte ich so generalisiert, damit die doch recht vielen Firmwares alle gleich eingebettet werden und Devices gleich behandelt werden (EVSE, EVSE 2.0, RS485 und NFC).

    Du musst dann nur händisch das Device initialisieren, so wie das DeviceModule::setup_device() tut, nur ohne den ensure_matching_firmware-Teil. Also UID raussuchen mit find_uid_by_did, dann die create-Funktion, z.B. tf_industrial_quad_relay_v2_create aufrufen.

    Der Großteil der anderen Logik ist nur dafür da, die Firmware zu flashen und eventuell darauf zu reagieren, dass die Firmware gerade geflasht wird (deshalb der loop-Check ob das Device im Bootloader-Modus ist).

    17 hours ago, mattsches said:

    Aus meinem Modul heraus muss ich den Ladevorgang im EVSE starten und stoppen und den Stromsollwert vorgeben. Mache ich das über die API (api.callCommand) oder gibt es dazu einen besseren Weg?

    Mach das am besten über api.callCommand, ja. Du kannst händisch auf dem EVSE arbeiten, das kannst du dir z.B. im NFC-Modul ansehen, aber über die API ist es robuster, für den Fall dass gerade auch andere Teile der Software mit dem EVSE interagieren.

    Grüße,
    Erik

    WARP in Home Assistant via MQTT und HTTP-API

    in WARP Charger

    Geschrieben

    On 11/11/2021 at 2:19 PM, floho said:

    Da ich das ja direkt auswerte würde ich mir wünschen, dass man einstellen könnte dass einfach der letze erkannte Tag gesendet wird, nicht die letzen 8.

    seen_tags sollte immer nach last_seen sortiert sein. D.h. wenn du nur das zuletzt erkannte Tag willst, kannst du einfach immer den ersten Eintrag lesen.

    On 11/11/2021 at 2:19 PM, floho said:

    Außerdem wäre es klasse wenn der Publisher nur nach dem Erkennen (gerne mehrmals) ein Nachricht sendet.

    Dann würde im Webinterface die Anzeige, wann Tags zu letzt gesehen wurden nicht mehr funktionieren. Kannst du in HA darauf reagieren, wenn last_seen kleiner als der Wert aus der letzten Nachricht wird? Falls nicht behalte ich das für die künftige Erweiterung der NFC-API mal im Hinterkopf.

    Uptime u.ä. läuft zu schnell

    in WARP Charger

    Geschrieben

    Moin,

    Die Zeit wird mit dem Takt des Prozessors des Ladecontrollers gemessen, da läuft keine RTC, keine Netzwerkzeitsynchronisierung oder ähnliches. Der Anwendungsfall ist bisher nur Zeitintervalle im Bereich Minuten bis zu ein paar Stunden zu messen (lies: z.B. die Dauer eines Ladevorgangs). Deshalb können wir die 0,4% Drift verschmerzen.

    Falls du das länger beobachtest: Lass dich nicht davon verwirren, dass der Zähler nach ~ 50 Tagen auf 0 zurückspringt. Der ist nur 32 Bit breit ;)

    Wenn wir später Features wie z.B. verschiedene Ladeströme zu verschiedenen Tageszeiten nachlegen, brauchen wir dann natürlich eine bessere Zeitmessung und absolute Zeiten. Voraussichtlich werden wir dann NTP implementieren.

    Edit: Ich habe einen entsprechenden Hinweis in die Dokumentation gepackt.

    WARP in Home Assistant via MQTT und HTTP-API

    in WARP Charger

    Geschrieben

    Du musst, wenn du Einträge nicht verändern willst, diese explizit auf null setzen. Also z.B. 

    {"require_tag_to_start": true, "require_tag_to_stop": null, "authorized_tags": null}

     

    On 11/5/2021 at 1:16 PM, sahni said:

    Allerdings funktioniert eine Aktualisierung von evse/auto_start_charging via evse/auto_start_charging_update auch ohne einen Neustart. Das ein Neustart des Ladecontrollers diesen Wert zurück auf true setzt finde ich etwas unglücklich. Die Änderungen (auto_start_charging: false) wurden ja nicht ohne Grund durchgeführt.

    Dafür wird es voraussichtlich einen konfigurierbaren Default-Wert geben. Der Hintergedanke war an der Stelle mal, dass egal was man an Konfiguration kaputt gespielt hat, nach einem Neustart der Wallbox geladen werden kann. Das ist aber seit dem es das managed-Flag gibt sowieso nicht mehr gegeben.

    • Thanks 1

    Blauer LED-Ring

    in WARP Charger

    Geschrieben

    13 hours ago, sahni said:

    Wann genau wird denn was ("aus, an, blinkt, flackert, atmet") ausgelöst.

    Die aktuelle LED-Logik ist ungefähr wie folgt:

    • Normalerweise leuchtet die LED durchgängig, geht aber nach ein paar Minuten in den Stand-By -> aus
    • Beim Laden atmet die LED
    • Bei Fehlerzuständen blinkt die LED n-mal für Fehlercode n
    • Flackern sollte nur beim Start des Ladecontrollers für ein paar Sekunden auftauchen, das heißt, dass der DC-Fehlerschutz kalibriert wird
    • Die komplizierteren Muster (siehe Anleitung) sind alles NFC-Anzeigen

    Prinzipiell können wir die API der LED-Steuerung rausführen. Intern gibt es das schon für die NFC-Rückmeldungen. Das ist etwas kompliziert wegen der Priorisierung (z.B. Ladecontroller meldet Fehler, NFC hätte gerne das Muster für "Karte gesehen" und die API sagt "LED aus", wer gewinnt), aber ich setze es mal auf die TODO-Liste darüber nachzudenken.

    • Like 1
    • Thanks 1

    WARP2 v WARP1 technische Unterschiede Fragen und Antworten

    in WARP Charger

    Geschrieben

    11 hours ago, alestrix said:

    Ich konnte das NFC Bricklet nicht wie es bei der WARP2 zu sein scheint am rechten Rand platzieren, da dort die Schraubengewinde zu nah am Rand sind. Habe das Bricklet nun unten abgelegt (da braucht's auch keine Fixierung) und dann hat das 15cm Kabel gerade noch so gereicht.

    Ich hatte das hier mal ausprobiert: Was ganz gut klappt ist, das Bricklet oben links (Sicht auf die offene Wallbox) bzw. rechts (Sicht auf den abgeschraubten Deckel) zu kleben, damit es bei einer Pro über dem Zähler ist. NFC funktioniert nicht durch die Frontplatte hindurch, die ist geerdet. Aber Tags, die du oben links auf die Box legst, werden relativ zuverlässig gefunden.

    11 hours ago, alestrix said:

    Was ist ein Spiegelband?

    Starkes doppelseitiges Klebeband.

    11 hours ago, alestrix said:

    sondern möchte das am liebsten komplett via EVCC umsetzen.

    Für die Mitleser siehe hier: https://github.com/evcc-io/evcc/pull/1700

     

    Ladeproblem eGolf 300 bei 6A und 7A

    in WARP Charger

    Geschrieben

    Erstell bitte mal ein Ladelog wie folgt:

    • (bei abgezogenem Auto) Auf dem Webinterface unter Ladecontroller auf Ladeprotokoll erstellen -> Start klicken, den Tab auflassen!
    • Auto anstecken, warten bis du erwarten würdest, dass "grün blitzend" angezeigt wird
    • Dann im Webinterface auf Stop + Download klicken

    Im Idealfall machst du noch ein zweites Log von einer normalen, also nicht zeitversetzten Ladung. Achtung: Die Logs werden recht schnell groß, also erstell keins von der ganzen Ladung, sondern wenn das Auto wirklich Strom ziehst kannst du das Log nach ein paar Sekunden beenden.

×
×
  • Neu erstellen...