Jump to content

floho

Members
  • Gesamte Inhalte

    64
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    4

Posts erstellt von floho

  1. Wenn man das Kabel nicht über die Wallbox selbst führt ist das natürlich kein Problem. Wenn ich und das Wetter Lust haben schau ich nochmal in die Box und suche nach einer besser passenden Stelle. Ist aber tatsächlich sehr voll da drin (habe die PRO). Es funktioniert aber auch so schon relativ gut, der Tag muss eben ein wenig an dem Kabel vorbeigeführt werden. Wirklich schlimm ist das nicht, ich wollte den Gedankengang dennoch an andere Nachrüster weitergegeben haben. 

  2. Stimmt. Dar letzte erkannte Tag ist immer seen_tags[0], danke.

    Aus technischer Sicht habe ich keinerlei Probleme mit der aktuellen Implementierung, alles funktioniert bestens.

    Allerdings "sorge" ich mich ein wenig wegen des Traffics. Die Wallbox sendet im 1s Takt und der Payload wird immer größer. Und sie ist ja nicht der einzige MQTT/HTTP Teilnehmer. Daher dachte ich, dass für meinen Anwendungsfall z.B. die Tag-History nicht wirklich relevant ist, und schon gar nicht sekündlich.

    Die vergangenen Sekunden könnte man durch einen Timestamp ersetzen. Dann könnte man sich den Wert selbst errechnen. Andererseits kann so kein Ist-Zustand abgerufen wenden wenn man das einmalig gesendete Telegramm verpasst oder "vergessen" hat. Also auch keine so gute Lösung. 

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

    Kann man beliebig aufblasen, klar. Wie gesagt, wenn Luft ist wäre das sicher eine nette Option, aber Dinge wie "Nutzer/Tagverwaltung" halte ich für wichtiger. 

    Gruß und Danke, Florian

  3. Ich hab nun in die WARP 1 das NFC Tool nachgerüstet. Dadurch werden per MQTT zyklisch diese Einträge versendet: 

     

    Topic:

    warp/XXX/nfc/seen_tags

    Inhalt:

    [
      {"tag_type":2,"tag_id":[1,2,3,4,5,6,7],"last_seen":1703665},
      {"tag_type":0,"tag_id":[],"last_seen":0},
      {"tag_type":0,"tag_id":[],"last_seen":0},
      {"tag_type":0,"tag_id":[],"last_seen":0},
      {"tag_type":0,"tag_id":[],"last_seen":0},
      {"tag_type":0,"tag_id":[],"last_seen":0},
      {"tag_type":0,"tag_id":[],"last_seen":0},
      {"tag_type":0,"tag_id":[],"last_seen":0}
    ]

    Nun versuche ich das teil sinnvoll in HA zu integrieren. Ich dachte an ein Template mit dem Attributen "ID" und "last seen". Der Type ist eigentlich (für meinen Zweck) egal. Leider habe ich es bisher nicht hinbekommen. 

    Vielleicht ist jemand hier firmer und hat eine Idee. 

    Außerdem noch eine Frage an Tinkerforge: warum zyklisch? Und warum 8 Einträge? Kann es sein dass 8 Tags angelernt werden können und in einer fixen Liste gespeichert werden? Diese 8 Tags werden dann eben zyklisch gesendet? Aktuell habe ich nur einen Tag, daher kann ich es nicht empirisch ermitteln.

    EDIT:

    Nun habe ich einen zweiten NFC Tag gefunden. Offensichtlich werden in dem MQTT Topic einfach die letzen 8 gefundenen NFC - Tags gesendet. 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. Außerdem wäre es klasse wenn der Publisher nur nach dem Erkennen (gerne mehrmals) ein Nachricht sendet. So wird doch sehr viel Traffic erzeugt ....

    Gruß und Danke, Florian

     

     

  4. Kam gerade an. Nach 5 Minuten Montage klappt es auf Anhieb.

    Super Sache ... jetzt also warten auf Tagspezifische Zählerstände ;-)

    Gruß, Florian

     

    p.s. Ein Nachteil bei Anbringen an der Oberseite ist, dass dort immer das Kabel im Weg ist (wenn das Auto sehr nah parkt ist noch eine Schlaufe um die Wallbox). Geht, ist aber nicht sehr komfortabel. Besser doch unten oder seitlich, da steht das Kabel etwas ab. 

  5. Super, funktioniert tadellos. Danke. 

    Eine Anmerkung habe ich. Ich würde die Sensoren wie folgt abändern: 

    sensor:
      - platform: mqtt
        name: "Wallbox Leistung"
        state_topic: "warp/XXX/meter/state"
        value_template: "{{ value_json.power }}"
        device_class: power
        state_class: measurement
        unit_of_measurement: "W"
      - platform: mqtt
        name: "Wallbox Zählerstand"
        state_topic: "warp/XXX/meter/state"
        value_template: "{{ value_json.energy_abs }}"
        device_class: energy
        state_class: total
        unit_of_measurement: "kWh"

    Also die "state_class" Attribute einfügen. Dann wird das neue Energy Feature unterstützt und somit die Langzeitauswertung des Zählers. 

    Gruß, Florian

  6. vor 3 Stunden schrieb eUp123:

    Vielen Dank für die superschnelle Rückmeldung. Werde zunächst zwei andere WARP Charger Pro auf ähnliches Verhalten testen, auch mit unterschiedlichen FI (ABB, Hager und evtl. Siemens). Ich würde es zwar nicht verstehen, aber vielleicht hilft Umstieg von FI B auf A. Wäre ja Dank in der WB verbautem 6V DC Fehlerstromwächter zulässig.

    Laut Anleitung ist doch sogar ein Typ A gefordert. 

×
×
  • Neu erstellen...