Taster und ext. Steuerung in Kombi funktioniert nicht

[rediculum]

Seit dem FW Upgrade auf die 2er Version, funktioniert eine gleichzeitige Nutzung des Tasters und die ext. Steuerung (z.b. MQTT oder evcc) nicht mehr. Folgendes im UI unter Ladecontroller konfiguriert:

• Lastmanagement: Aus
• Benutzerauth: Aus
• Externe Steuerung: Ein
• Tastereinstellung: Start und Stop

Mit dieser Einstellung ist der Taster inaktiv. Erst wenn ich "Ext. Steuerung" deaktiviere, kann ich mit dem Taster ein und ausschalten., aber dann gehen MQTT Befehle nicht mehr. Ist dies bewusst so oder ein Bug? Mit der 1er Firmware konnte ich noch beides (Taster & MQTT) gleichzeitig benutzen.

Im Usermanagement habe ich nichts angefasst. Die 3 NFC Tags wurden in User übernommen, aber Logins sind keine definiert.

Gruss Roland

[rtrbt]

Moin Roland,

Was heißt für dich gleichzeitig? Was funktionieren sollte (dazu gleich mehr) ist, dass du Ladevorgänge sowohl über den Taster, als auch über die externe Steuerung starten und stoppen kannst. Du kannst aber nicht (und das ist vollkommen beabsichtigt) mit der externen Steuerung den Taster überschreiben oder andersrum. Lies: Wenn eins von beidem blockiert, kann nicht geladen werden.

Die externe Steuerung kann natürlich auch auf Tastendrücke reagieren, (evse/button_state) d.h. du kannst damit, falls du das brauchst, mit der externen Steuerung die Vorgaben des Tasters überschreiben, indem du evse/start_charging bzw. evse/stop_charging benutzt.

Zu dem "sollte" von oben: Ich habe das hier kurz ausprobiert und bin über einen Bug gestolpert: Wenn du den Taster auf Start und Stop konfigurierst, dann funktioniert das Stoppen nur einmal. D.h. wenn du ein Auto anschließt und Auto-Start aktiviert ist, es also sofort anfängt zu laden, dann wird bei Tasterdruck gestoppt, dann beim nächsten Druck wieder gestartet, aber danach funktioniert das Stoppen nicht mehr. Das Verhalten ist unabhängig davon, ob die externe Steuerung an oder aus ist. Ein Fix dafür ist in Arbeit.

[rediculum]

Ich meinte natürlich nicht gleichzeitig, aber in Kombination. Das heisst z.B. mittels Taster einschalten und später via MQTT stoppen oder umgekehrt.

Das mit dem einmaligen Stoppen hab ich auch festgestellt. Das ganze Szenario verhält sich aber generell merkwürdiger.

Szenario 1: Ich habe Auto-Start deaktiviert, Ext. Steurung an, Taster auf Start/Stop gestellt und den Typ2 Stecker aus dem EV ausgesteckt. Interessant ist jetzt was im Status Menü passiert wenn man folgende Schritte macht:

• Ausgesteckt:

• Nach dem einstecken des Typ2 Stecks in das EV:

• Nach dem drücken des Tasters:

• Nach erneutem drücken des Tasters:

Weiteres Drücken des Tasters bleibt der Status unverändert. Die Tasten LED ist ständig im schnellen Breathe Modus und die Ladung fängt nie an. Sobald ich jetzt "Ext. Steuerung" deaktiviere, startet der Ladevorgang von alleine. Stoppen via Taster geht aber nicht. Wenn ich "Ext. Steuerung" wieder aktivere, stopp der Ladevorgang unverzüglich. Evcc ist übrigens gestoppt, daran liegts also nicht. Kannst du das reproduzieren?

Szenario 2: Wenn "Ext. Steuerung" deaktiviert ist und ich erst dann den Typ2 einstecke, fängt die WARP sofort an zu laden. Übrigens ungeachtet davon, ob Auto-Start an oder aus ist. Ich kann dann mittels Taster die Ladung stoppen und dann mit erneutem Druck wieder starten. Jetzt tritt dein Bug auf, die Ladung lässt sich jetzt nicht mehr per Taster stoppen, nur noch im UI.

Hier ist meines Erachtens ein mächtiger Wurm drin :)

[rediculum]

Update: Ich hab herausgefunden, dass sobald "Ext. Steuerung" aktiviert ist, der "Erlaubte Ladestrom" auf 0.00A gesetzt wird. Sobald ich "Ext. Steuerung" deaktiviere, ist im Ladecontroller der "Erlaubte Ladestrom" wieder auf 16.00A gesetzt. Sehe dies im MQTT auch:

warp2/evse/state {"iec61851_state":0,"charger_state":0,"contactor_state":1,"contactor_error":0,"allowed_charging_current":16000,"error_state":0,"lock_state":0,"dc_fault_current_state":0}
warp2/evse/state {"iec61851_state":0,"charger_state":0,"contactor_state":1,"contactor_error":0,"allowed_charging_current":0,"error_state":0,"lock_state":0,"dc_fault_current_state":0}

Ist das gewollt so, dass die ext. Steuerung ALLES übernehmen soll und die im UI voreingestellten Ladeströme ignoriert, resp. auf 0.00A gesetzt werden? Wenn ja, wunderts mich nicht, dass der Ladevorgang nicht gestartet wird in Szenario 1

Noch was: stop_charging und start_charging haben keine Wirkung mehr.

[rediculum]

Last Update: So nach weiteren 2h debuggen habe ich es nun begriffen. Da EVCC neu den Ladestart und -stopp mittels dem Ladestrom steuert, ist mir klar geworden, dass wenn EVCC beim Stop den external_current auf 0 setzt, auch der Taster nichts bewirken kann um zu starten. Da ich u.A. auch OpenHAB (noch 2.5) verwende und von dort aus stoppen und starten möchte, habe ich jetzt meine Rule angepasst und alles läuft wie ich es möchte.

Danke für den Tipp mit dem evse/button_state. Jetzt steuert OpenHAB einfach EVCC zum starten und stoppen der Ladung (via MQTT). Wenn der Button state sich ändert (also Taste gedrückt wurde), frage ich den iec61851_state ab und je nach dem ob geladen wird oder nicht, schicke ich per MQTT den Start- oder Stoppvorgang an EVCC.

Sharing is caring. Hier die OpenHAB Rule:

rule "WARP Charge OH UI"
when
  Item WARP_Charge changed
then
  var key = WARP_Charge.state.toString
  switch (key) {
    case "1": {
      logInfo("WARP_Charge","Stop charging")
      publish("broker","evcc/loadpoints/1/mode/set","off")
    }
    case "2": {
      logInfo("WARP_Charge","Start charging from grid")
      publish("broker","evcc/loadpoints/1/mode/set","now")
    }
    case "3": {
      logInfo("WARP_Charge","Start charging from solar")
      publish("broker","evcc/loadpoints/1/mode/set","pv")
    }
  }
end

rule "WARP Charge Wallbox Button"
when
  Item MQTTGeneric_WARPButton changed
then
  var status = MQTTGeneric_WARPChargeState.state
  var button = MQTTGeneric_WARPButton.state.toString
  if (button == "true") {
    switch (status) {
      case status >= 2: {
        logInfo("WARP_Charge","Stop charging over Wallbox")
        publish("broker","evcc/loadpoints/1/mode/set","off")
        WARP_Charge.postUpdate(1)
      }
      case status == 1: {
        logInfo("WARP_Charge","Start charging over Wallbox")
        publish("broker","evcc/loadpoints/1/mode/set","now")
        WARP_Charge.postUpdate(2)
      }
    }
  }
end

ich geh mich jetzt hinlegen

[rtrbt]

Ah, ja wenn EVCC auch im Spiel ist wird es interessant :D Die evse/external_...-APIs werden von EVCC benutzt. D.h. dein Ansatz statt der Wallbox direkt EVCC zu steuern ist auf jeden Fall der sinnvollste.

Ist das gewollt so, dass die ext. Steuerung ALLES übernehmen soll und die im UI voreingestellten Ladeströme ignoriert, resp. auf 0.00A gesetzt werden?

Das ist Absicht, ja. Prinzipiell ist die Logik, dass erst dann geladen werden darf, wenn alle Steuerungsmöglichkeiten, die aktiviert sind (lies Ladeslots, also z.B. Taster/Webinterface, externe Steuerung, Lastmanagement, Benutzerautorisierung), das erlauben und dass dann auch nur mit dem Minimum der Ladestromgrenzen geladen werden kann. Das heißt dann natürlich auch, dass jede einzelne Steuerungsmöglichkeit das Laden komplett lahmlegen kann. Das muss aber so sein, da ja z.B. das Lastmanagement hart verbieten können muss, dass geladen werden kann.

Bezüglich des Taster-Bugs: Der Fix für die Ladecontroller-Firmware ist hier: https://github.com/Tinkerforge/evse-v2-bricklet/commit/bdeb88ee2ebb944d9a99914762d492e0677700ec Mit der nächsten Wallbox-Firmware wird das also gefixt sein.

[rtrbt]

Bezüglich des Taster-Bugs: Der Fix für die Ladecontroller-Firmware ist hier: Tinkerforge/evse-v2-bricklet@bdeb88e Mit der nächsten Wallbox-Firmware wird das also gefixt sein.

Ist in Firmware 2.0.5.