[Q] Control current charge policy via MQTT-Control?

[curlyel]

Hi Nathan, hi Mike, in the Control_MQTT.md it look like the control options are limited to chargeNow-feature:

MQTT Topic | Value | Description -- | -- | -- prefix/control/chargeNow | AA,SS | Starts charging at AA amps for SS seconds immediately. e.g. 8,3600 = 8 Amps for 1 hour prefix/control/chargeNowEnd | None | Stops immediate charging. prefix/control/stop | None | Stops TWCManager.

Is it possible to set/change the intended policy via MQTT-control too? If so, mind sharing an example?

Many thanks, Curlyel

[MikeBishop]

Currently, I don't believe so; the policies respond to things which can be evaluated, and there's no generic way to set a value it would act on by MQTT. An outside system can direct how much and how long to charge using this interface, and when it stops, it goes back to "normal" behavior (which might be "don't charge").

Are you looking to have the decision about whether Track Green Energy or other policies kick in depend on some event that TWCManager isn't otherwise aware of?

[curlyel]

Hi Mike,

whether Track Green Energy or other policies kick in depend on some event that TWCManager isn't otherwise aware of?

... exactly that's the idea ;-)

My use case includes a house battery system and a (freely accessible) second TWC in front of my garage.

Case #1:

• keep "Don't Charge" policy until house battery's SoC is at least 80% (first charge house battery before fuelling the cars)
• if above 80% start "Track Green Energy" if a known car is connected (solar surplus per openHAB EMS includes house battery charging current, so that TWC manager can consider this amperage for car charging too)
• house battery may provide additional energy if clouds passing and pv surplus is temporarily dropping below 6 Amps.
• though, if SoC drops below 60% revert from "Track Green Energy" back to "Don't Charge"

Case #2:

• if the "outside" slave TWC gets into state other than 0 AND no known ("no own") car is parked in front of the garage -> enter "Don't Charge" policy (proximity of own cars are detected by BLE beacon proximity for non-Tesla)

Other option than controlling the intended charge policy by a "third party" directly (openHAB in my case) would be making TWC manager aware of the SoC of an optional house battery in the supported EMS's (e.g. at least for "generic" EMS like MQTT EMS and/or openHAB EMS) and adopt something like the above SoC-rule in the TWC's policies directly ...

[MikeBishop]

The latter is what I do for case 1; I'm using an EMS module that can see the battery, so it just requires this:

  "restrictions": {
    "Track Green Energy": {
      "match": [
        "modules.TeslaPowerwall2.batteryLevel"
      ],
      "condition": [
        "gte"
      ],
      "value": [
        "modules.TeslaPowerwall2.reservePercent"
      ]
    }
  },

Seems like the simplest route to that is exposing your battery level through the EMS; I don't know whether it's already in the module you're using.

For the second, if the outside TWC reports the VIN of the charging vehicle, you might consider simply using the allow-list of authorized vehicles to deny charging to anyone else.

[curlyel]

Re case 1:

I'm using an EMS module that can see the battery

That's almost what I'm after 👍 I've just checked the three EMS-modules which I could consider: Fronius, openHAB and MQTT. Unfortunately, none of them knows a 'batteryLevel'. Fronius EMS at least has a kind of generic 'getInverterData' which might be used for digging out the SoC from the inverters API.

Not sure how much effort it would be to extend one of the above candidates by an 'batteryLevel' topic/item.

Re case 2:

if the outside TWC reports the VIN

I thought this would work with Tesla vehicles only. Does is provide the VIN for other cars too? Haven't tried yet. We only had Tesla BEVs so far ... If so, it would be perfect and solve the need 👍

[MikeBishop]

No, the VIN is only for Tesla. But if you only have Teslas and put their VINs as the only ones allowed to charge, then getting a non-Tesla vehicle (VIN is all-zeroes) should still get blocked. (I don't use the blocking feature, so I don't remember how aggressively it cuts them off.)