Hallo zusammen,

ich bin neu in der Runde, daher erstmal ein Hallo an Alle! 👋

Ich abe mir vor rd. 3 Monaten eine Tinkerforge Warp3 Pro gekauft, die ich bisher in Verbindung mit EVCC (Ladesteuerung für einen Mokka-E, da der sonst bis 10% lädt) sowie NFC Freigabe nutze (wegen Carport).

Jetzt möchte ich es mir in Verbindung mit Home Assistant etwas bequemer machen: Wenn ich ein bekanntes Fahrzeug (aus EVCC) anschließe, dann möchte ich kein NFC mehr nutzen, sondern dass Home Assistant das Laden freigibt. NFC soll aber eine zweite Option zur Freigabe der Tinkerforge bleiben, falls z.B. ein Gast bei uns laden möchte, auch wenn ich nicht daheim bin.

Was ich in Home Assistant per Automation hinbekomme ist, über mqtt den Eintrag in external_control zu übergeben.

alias: Wallbox Freigabe via MQTT
description: Sendet alle 30 Sekunden die Freigabe an die Tinkerforge Wallbox
triggers:
  - seconds: /30
    trigger: time_pattern
conditions:
  - condition: or
    conditions:
      - condition: state
        entity_id: input_boolean.wallbox_automatik_schalter
        state: "on"
      - condition: state
        entity_id: select.evcc_carport_vehicle_name
        state:
          - ev1
        enabled: true
actions:
  - data:
      topic: warp3/power_manager/external_control
      payload: |
        {
          "phases_wanted":3,
          "charge_release": true,
          "current_limit": 11000,
          "time_to_live": 45000
        }
    action: mqtt.publish

Die Tinkerforge wartet aber trotzdem noch auf eine NFC Freigabe.

Wie bekomme ich das priorisiert, dass ein Eintrag in external_control die NFC Freigabe "übersteuert"?

Vielen Dank an die jenigen, die mir bestimmt schnell helfen können 😊

Andy

Zusatzinfo

Wenn ich das Auto abstecke, wird per Automation die mqtt Freigabe wieder zurückgesetzt (binary_sensor.wallbox_verbunden liest den Wert aus mqtt aus):

alias: Wallbox Freigabe über MQTT deaktivieren
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.wallbox_verbunden
    to:
      - "off"
conditions: []
actions:
  - data:
      topic: warp3/power_manager/external_control
      payload: |
        {"charge_release": false}
    action: mqtt.publish
mode: single

On 2/6/2026 at 2:37 PM, AndyMu said:

      topic: warp3/power_manager/external_control
      payload: |
        {
          "phases_wanted":3,
          "charge_release": true,
          "current_limit": 11000,
          "time_to_live": 45000
        }

      topic: warp3/power_manager/external_control
      payload: |
        {"charge_release": false}
    action: mqtt.publish

Wo hast du die APIs her? power_manager/external_control hat nur phases_wanted und ist nur für die Phasenumschaltung zuständig (ein- oder dreiphasig). charge_release und time_to_live gibt es, soweit ich weiß, nirgends, weder auf diesem noch auf einem anderen API-Endpoint.

Abgesehen davon müssen Kommandos per MQTT immer an _update geschickt werden, also in diesem Fall an power_manager/external_control_update. Dann würde unter System → Ereignis Log auch ein passender Fehler ausgegeben werden:

On power_manager/external_control_update: Failed to deserialize: JSON payload was longer than expected and possibly contained unknown keys. Payload length was 87.

Wenn du NFC aktiviert hast und eine Ladung ohne Karte freigeben möchtest, musst du eine Karte mit ausgedachter ID anlegen und die dann vortäuschen. Dafür gibt es die APIs nfc/inject_tag bzw. nfc/inject_tag_start.

Hallo @MatzeTF

danke Dir für die Antwort. Oh je, da scheine ich ja doch ordentlich daneben zu liegen. Da hat mir die KI einfach was vorgelogen ☹️
Dann grabe ich mich mal tiefer in die Dokumentation der API ein und lass das chatten mit Gemini bleiben. Hat in anderen Zusammenhängen aber super geklappt, hier eben gar nicht mehr.

Das mit dem inject schaue ich mir näher an, danke für den Hinweis!

Wir müssen echt irgendwo einen großen, roten Banner platzieren, dass wir keinen Support für KI-generierten Code bieten. ☠️