How to bit test mqtt switch state_topic payload

Hi,

Can anyone tell me is if it possible to bit test the received payload of a state_topic in an MQTT switch?

I have an IoT device (Arduino uno with Ethernet shield) which controls three LED strip lights. The lights are turned on by publishing a payload of 1/0 to the three separate topics respectively;

  • command_topic: “/EthernetDevice/Study/SwanLight”
  • command_topic: “/EthernetDevice/Study/TopShelfLight”
  • command_topic: “/EthernetDevice/Study/UnderDeskLight”

Confirmation of a successful switch on is signaled by a publish from the IoT device on the following topic;

state_topic: “/EthernetDevice/Study/LightConfirm”

For successful turn on of;

  • SwanLight bit 0=1
  • TopShelfLight bit 1=1
  • UnderDeskLight bit 2=1

So for all lights off the published topic /EthernetDevice/Study/LightConfirm has a payload of 0 and for all lights on it is 7.

Try as I might I have not been able to successfully parse the state_topic and hence set the state of the switch.

For SwanLight I have used the following, but have got nowhere;

  • state_template: ‘{%- if ((value == “1”) or (value == “3”) or (value == “5”) or (value == “7”)) -%} on {%- else -%} off {%- endif -%}’
  • state_template: ‘{%- if value in [“1”, “3”, “5”, “7”] -%} on {%- else -%} off {%- endif -%}’

As I’m new to Home Assistant I’m not sure I’m on the right track.

Any help would be greatly appreciated.

I’m not sure if it will work but you can try:

state_value_template: '{%- if ((value == "1") or (value == "3") or (value == "5") or (value == "7")) -%} on {%- else -%} off {%- endif -%}'

I’m not really sure if you need the inner quotes around the values, tho. Try it both ways to see if either way works.

I have a fan that returns a json formatted payload for the state and using “state_value_template” works for me to extract the payload as a template.

Here is my full state code for reference if it helps:

    state_value_template: >
      {% if value_json.FanSpeed is defined %}
        {% if value_json.FanSpeed == 0 -%}0{%- elif value_json.FanSpeed > 0 -%}4{%- endif %}
      {% else %}
        {% if states.fan.master_bedroom_fan.state == 'off' -%}0{%- elif states.fan.master_bedroom_fan.state == 'on' -%}4{%- endif %}
      {% endif %}

Also as an FYI be careful about using “fancy” quote marks in your code. I’m not sure if it is an artifact of just my copying your improperly formatted from the forum or if your code actually contained those types of quotes but I needed to edit those out & insert the proper ones above. You need to make sure you are using plaintext quotes in your actual code.

If you have an Arduino doing the hard work, why not program it to work better, ie post the statuses in separate topics?

Hi nickrout,
Yes modifying the arduino code as a one off would be one possible solution, though wholly impractical where many (none OTA programmable) devices are present, needing RTB for re-programming.
It also raises other issues. Such as on a constrained device using up flash or ram unnecessarily is not an option. The Uno only has 27KB flash (less bootloader) and 2KB of RAM. You’ll soon burn through that if you don’t keep an eye on memory usage.
Home automation (HA) software must be flexible and rich enough to deal with just this scenario.
For my part I have a series of HA projects I document primarily for STEM and those makers who are not necessarily completely software development savvie https://www.instructables.com/id/Home-Automation-12/ and have used OpenHAB for some time now. Incidentally, which handles this issue trivially. As OpenHAB2 is reaching maturity and so is Home Assistant, I wanted to try both with a view to moving over to the most optimal solution.

The arduino subscribes to three separate MQTT topics but publishes to just one state topic? In retrospect, that’s a regrettable design decision.

I disagree with the so-called memory limitations. The strings for all three topics are already taking up space in flash memory:
topic = "/EthernetDevice/Study/"
device1 = "SwanLight"
device2 = "TopShelfLight"
device3 = "UnderDeskLight"

It only takes the extra word state to transform all the existing command topics into state topics. The MQTT pubsub library is already loaded so just use the publish function. Extra space to accomplish all of this is trivial.

BTW, it’s not a recommended practice to prepend a slash to an MQTT topic.
Don’t do this: /EthernetDevice/Study/SwanLight
Do this: EthernetDevice/Study/SwanLight

The leading slash needlessly creates an empty first level of the topic.

https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/

Pretty sure rlkoshak would’ve also pointed out the asymmetry of your design … and suggested a symmetric handling of command and state topics would be the “cleanest solution”.

Just like with openHAB, there’s no official technical support here, so responses to questions will be as varied as the questions themselves. For example, just look at your last post. Your choice of metaphors for this technical discussion is curious, to say the least. Nevertheless, “I also concede the point about the asymmetric nature of the 3 to 1 topics” is all we were looking for, so there’s progress.

For this specific requirement, probably openHAB.

PS
Use an MQTT client to check the message being reported by the device. There’s an assumption being made that it looks like 1, 3, 5, 7 but it might actually be different.

Seeing that this is your very first topic in this community, your sunny disposition has not gone unnoticed.

SteveQuinn

That’s nice.

And now veiled threats. Really?

A threat? No. This is an international community so perhaps there’s a language barrier involved that has led to this mistaken conclusion?

My comment simply pointed out that your demeanour, as documented in your posts above (that you’ve now deleted), is in stark contrast to what one normally sees in this community (especially for a newcomer). So much so, that’s it’s hard to not notice it.

@SteveQuinn the design makes it more difficult to achieve your aim, but it shouldn’t be impossible. Keep trying. By the way are you aware of the dev-template feature of home-assistant?