Mqtt Sensor with different modes?!


im trying to add an a function to change my Loading Mode for my Wallbox in Home Assistant. I can change it via mqtt but have 0 clue how to add it in my config.

  - platform: mqtt
    state_topic: "openWB/evu/W"
    name: OpenWB EVU Watt
  - platform: mqtt
    state_topic: "openWB/pv/W"
    name: OpenWB PV Watt
  - platform: mqtt
    state_topic: "openWB/global/ChargeMode"
    name: OpenWB Lademodus
  - platform: mqtt
    state_topic: "openWB/lp/1/%Soc"
    name: OpenWB SoC LP1
  - platform: mqtt
    state_topic: "openWB/lp/1/W"
    name: OpenWB Loading LP1 Watt
  - platform: mqtt
    state_topic: "openWB/lp/1/kWhActualCharged"
    name: OpenWB Loaded kWh
  - platform: mqtt
    state_topic: "openWB/global/WHouseConsumption"
    name: Energieverbrauch
  - platform: template
        friendly_name: "OpenWB Status"
        value_template: >-
          {% if states('sensor.openwb_lademodus') == '0' %}
            Sofort Laden
          {% elif states('sensor.openwb_lademodus') == '1' %}
            Min und PV
          {% elif states('sensor.openwb_lademodus') == '2' %}
            Nur PV
          {% elif states('sensor.openwb_lademodus') == '3' %}
          {% elif states('sensor.openwb_lademodus') == '4' %}
          {% else %}
            {% endif %}

Are we supposed to know how it works “via mqtt”?

1 Like

my Bad.

If i Publish 0-4 to this “openWB/lp/1/ChargeStatus” it will change between my 4 modes.
0 Instant Charge
1 Min+PV
2 PV
3 Stop
4 Standby

So what im looking for is kinda a switch? between all modes.

I don’t think a MQTT select would help here, because your options would have to be 0,1,2,3,4. I don’t see a way to map them to their text representation.
I guess you’ll have to use an input_select helper and an automation to do the job.

1 Like

Okay but how? :slight_smile:

    name: OpenWB state
      - Sofort
      - PV+Min
      - PV
      - Stop
      - Standby
    icon: mdi:car-electric

and now a automation with mqtt publish but I have 0 clue.

service: mqtt.publish
  topic: openWB/global/ChargeMode
  payload: '2'
- alias: example 999
  - platform: state
    entity_id: input_select.whatever
  - service: mqtt.publish
      topic: openWB/global/ChargeMode
      payload: >
        {% set options = {'Sofort': 0, 'PV+Min': 1, 'PV': 2, 'Stop': 3, 'Standby': 4 } %}
        {{ options[trigger.to_state.state] if trigger.to_state.state in options.keys() else '3' }}

If the input_select reports a value that doesn’t exist in the variable named options, the template will publish 3 which represents Stop. Feel free to change that to whatever you think is appropriate.

1 Like

Thanks alot!

You could do the reverse as well by making an automation with MQTT triggers.

alias: New Automation
description: ''
mode: single
  - platform: mqtt
    topic: openWB/global/ChargeMode
condition: []
  - service: input_select.select_option
      entity_id: input_select.whatever
      option: >
        {% set options = {0: 'Sofort', 1: 'PV+Min', 2: 'PV', 3: 'Stop', 4: 'Standby' } %}
        {{ options[trigger.payload] if trigger.payload in options.keys() else 'Stop' }}
1 Like

awesome… I learned so much today <3

One hopes that the combination of the two automations doesn’t establish an endless loop.

For example:

  1. Manually changing the input_select triggers the first automation and it publishes the new value.
  2. The receiving device responds by publishing the received new value.
  3. That causes the second automation to set the input_select’s value.

Theoretically, it should stop there because the input_select’s value remains unchanged and so it won’t re-trigger the first automation.

1 Like

Indeed it should not. Otherwise, just put both in a single automation, use trigger id to select the right task. Mode to single en max_exeed to silent. Add a small delay at the bottom.

1 Like

As explained, the likelihood of looping is low because the reply from the device won’t change the input_select’s state. Without a state-change, it can’t serve to re-trigger the first automation (and initiate another iteration). So says the theory of how State Triggers work.

Now if hypothetically there was looping, your suggestion to user a consolidated automation with mode: single (the default) would indeed work but only under specific conditions, namely rapid communications between Home Assistant and the device.

In all probability, that would be the case. However, if there is delay in the communications (and it doesn’t have to be very much, merely a second or so), the consolidated automation would be given sufficient time to complete its execution before the device’s response served to re-trigger it. Therefore mode: single would not protect it from being re-triggered.

Anyway, this is all hypothetical because the input_select shouldn’t undergo a state-change if the received state is identical to its existing state.

It doesn’t if you also do what I say in my last sentence :smiley:

But yeah, it should not cause a second state change and thus not loop.

1 Like

True but clearly a kludge that employs impaired performance to satisfy the use of single mode (to protect against re-triggering). An efficient way to break the loop (to be clear, we’re still talking about a hypothetical situation; this is merely a thought experiment) is to use a Template Condition to confirm the input_select’s from_state and to_state are different (to allow executing the action). If the two states are identical then it instantly ends there.

I totally agree it’s a kludge and I find your solution interesting as well.

But this does make me wonder how HA would react on a loop. In this case for example, if you make an error in the states published for each input_select it’s possible to have a loop in which the from_state-to_state check also would not help. Or if you simply mess up other automations that react on each other.

Do you mean a user-error like creating identically named options?

BTW, this discussion is becoming rather esoteric because not only are we considering a hypothetical situation that doesn’t actually occur, we are now considering how it would behave when subjected to a user’s errors! :thinking:

Yeah, for example.

And sorry, just a brain fart. Loops could wreck HA pretty good I think.

I recall on one occasion I created an endless loop (with no delay between iterations). I was experimenting with repeat and using persistent_notifications to observe its behavior. A simple error in my code allowed it to rapidly churn out notifications.

I think all I had to do was stop Core (can’t recall if I did it via the UI or CLI), fix the defective repeat I had created, and restart Core. However, it had more than enough time to crank out a boatload of notifications before I scrambled to stop Core. :slightly_smiling_face:

1 Like

For future reference:
“command_template” was later added to “MQTT select”, making this much easier to implement: