Automation trigger on MQTT message with JSON payload not triggering

I am attempting to trigger an automation on an MQTT message which happens to contain a JSON-formatted payload.

My goal is to trigger on a specific JSON string being sent on a topic. MQTT triggers allow you to define the topic, and optionally, the payload.

  • If I create an automation which listens on a topic, set the expected payload to a valid JSON string, and then publish a message which matches the expected payload, the automation does not trigger.

  • If I create an automation which listens on a topic, set the expected payload to string which is not a valid JSON object, and then publish a message which matches the expected payload, the automation will trigger.

I have created a blueprint which demonstrates the situation which you can find here (this only works in the March beta to make it easier to demonstrate. Replace all templates with string literals and the behavior persists).

What appears to be happening is that Home Assistant is parsing the JSON, but doesn’t allow you to use the parsed version in the trigger, nor does it seem to allow you to use the non-parsed version either.

A common solution here would be to catch everything published on that topic, and then use a condition later, but that’s a problem because this is being used in the context of a blueprint with several triggers which each have their own path selected via choose in the main automation. So, conditions are no good because they will break all of the other functions of the blueprint. The approach being used today is to catch everything published, then use choose to filter it out later, but that creates a huge number of pointless automation triggers and is negatively impacting performance.

There are several enhancements in the pipeline including the ability to template the payload of an MQTT Trigger.

Whenever these enhancements become available (perhaps as soon as the March release) I believe they’ll help to simply the challenge you are facing.

Sadly, this behavior is also observed in the March beta. The blueprint above is utilizing the limited templates and trigger_variables which are part of the features you mention above.

That’s an implementation detail of the blueprint which makes it easier to demonstrate here. If you remove the templates and test in a normal automation, using only string literals in all fields, the behavior persists.

I’ve edited the OP to make note of this.

Allright, this appears to be related to this regression in the beta that I’m testing with.

Incoming MQTT messages are being cast to things which aren’t strings. In the bug above, it’s demonstrating a numeric payload being cast to an int instead of a string. What I appear to be running into is the same behavior, but the payload is cast to an object instead of a string, and thus cannot be matched against a string.