MQTT Automation: trigger.payload

Configuration
, ,
1

I’m at a loss…

Given:
HA MQTT is configured and can successfully subscribe and receives published messages. See output below.
The HA automation below cannot parse message variables correctly

A program publishes a topic e.g.:

mosquitto_pub -h elerpi4 -u ele -P xxxxx -p 1883 -t mochad/status -m '{"dt":"1770037776"}, {id":"light.erics_lamp"}, "st":"off"}'

This HA Automation correctly fires when an MQTT message is received e.g.:

- id: mochad_mqtt_state_sync
  alias: Mochad MQTT HA State Sync
  mode: queued
  trigger:
    - platform: mqtt
      topic: "mochad/status"

  variables:
    payload: "{{ trigger.payload_json }}"
    x10_id: "{{ payload.id | lower }}"
    new_state: "{{ payload.st | lower }}"
    entity_id: "light.{{ payload.id | lower | replace(' ', '_') }}"

  condition:
    - condition: template
      value_template: "{{ states(entity_id) != new_state }}"

  action:
    - service: python_script.set_state
      data:
        entity_id: "{{ entity_id }}"
        state: "{{ new_state }}"

MQTT Debugging is enable, and after a MQTT publish, HA MQTT cannot parse “trigger.payload_json variables” which it clearly receives…

2026-02-05 11:13:35.250 DEBUG (MainThread) [homeassistant.components.mqtt.client] Received message on mochad/status (qos=0): b’{“dt”:“1770037776”}, {id":“light.erics_lamp”}, “st”:“off”}’
2026-02-05 11:13:35.254 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: ‘dict object’ has no attribute ‘payload_json’ when rendering ‘{{ trigger.payload_json }}’
2026-02-05 11:13:35.254 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: ‘str object’ has no attribute ‘id’ when rendering ‘{{ payload.id | lower }}’
2026-02-05 11:13:35.254 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: ‘str object’ has no attribute ‘st’ when rendering ‘{{ payload.st | lower }}’
2026-02-05 11:13:35.255 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: ‘str object’ has no attribute ‘id’ when rendering ‘light.{{ payload.id | lower | replace(’ ‘, ‘_’) }}’
2026-02-05 11:13:35.256 INFO (MainThread) [homeassistant.components.automation.mochad_mqtt_ha_state_sync] Mochad MQTT HA State Sync: Running automation actions
2026-02-05 11:13:35.257 INFO (MainThread) [homeassistant.components.automation.mochad_mqtt_ha_state_sync] Mochad MQTT HA State Sync: Executing step call service
2026-02-05 11:13:35.267 INFO (SyncWorker_0) [homeassistant.components.python_script] Executing set_state.py: {‘entity_id’: ‘light.’, ‘state’: ‘’}

I’ve tried for a while to debug why and am asking for assistance…

I have many HA MOCHAD X10 “light.xxxx” entries and wish to update light state based on what Mochad X10 values really are (note: I do not want to execute turn_on or turn_off).

I wish programming HA and add-ons were better documented…

Thanks,

Eric L. Edberg

2

Missing a curly? {

3

missing opening double-quote character

I suggest using some online json parser to validate the source json

4

Might I suggest that you take a different path to solve your issue. Specifically you appear to be trying to parse raw MQTT messages inside home assistant.

Instead I would recommend you look into using MQTT entities that model the behavior you are looking for:

  • MQTT Switches - Show up in the UI as switches can be switched remotely or from the UI.
  • MQTT Triggers - Allow you to send events from external devices into HA.
  • MQTT Buttons - Allow you to have a button in the UI that you can press to send an event to an external device.

If you use those MQTT entities you will need separate topics for each Mochad ID (A2, B3) - If you want you can map them to more meaningful names, however the payloads can be much simpler - just ON or OFF

You will have to do more upfront work - likely you will need to use MQTT AutoDiscovery, but once you have done the work future automations will be much easier since you will probably expose everything as a switch initially so all the standard switch automations just work.

You may find the MQTT auto-discovery documentation challenging, so if you do decide to go down that path you may want to also check out this thread:

5

Thanks for the 2 posts pointing out the missing opening curly brace in the mosquitto_pub command. I swear that I had at one time used a json validator on that payload a couple days ago…

MQTT immediately fired, called the action: python_script.set_state, and the state of Mochad light.erics_light immediately changed state.

Alas, after 5 seconds or so it changed back to the original value e.g.: if the state was off, it updated per the mqtt topic state, and then automatically reverted to it’s previous state e.g.: off after a few seconds. Added the --retain flag and it did the same thing.

Will have to now debug why after calling: HASS.STATES.SET(entity_id, state) , the light reverts back to it’s previous value.

Thanks for the obvious and embarrassing feedback. I should have caught that, dohhh.

6

Thanks for the reply about using MQTT lights. I have read about that capability and also mqtt autodiscover. After reading and not comprehending how to defined autodiscovery for my 20+ lights, it seemed like a difficult task.

Currently, I have an existing mochad light configuration which allows me to automate legacy x10 light schedules fine. It works well and I’ve been using it for a year now. I hesitate to change from using mochad lights to mqtt lights.

What was lacking was when native X10 commands/buttons/controllers executed the new light status was not transmitted to HA.

The plan is to MQTT publish retained X10 light status state (as it occurs in real time) and have HA track that change across reboots and also update automatically.

I could define MQTT lights/switches, but would need to write yet another interface to perform changes on the X10 CM15 controller.

I’m almost there with X10 publishing state messages to HA (except for the recent nit when the state reverts back to it’s previous value). See previous post).

Thanks for your comment/suggestion !

Eric L. Edberg

7

Because it can only change the entity’s state temporarily (a known limitation). It just overwrites a value in the state-machine but that value is managed by something else (an integration).

The integration used for light.erics_lamp (Mochad) has ultimate control over its state.

8

> The integration used for light.erics_lamp (Mochad) has ultimate control over its state.

That’s what I assumed at this point and wish there was a supported mochad “set state” method.

One article I read stated “set state” was/is not supported and “user beware”…

As a workaound: if HA mochad.my_light state does not match the actual state of an X10 light (state obtained from the remote modchad x10 server process) the next best thing would be for the HA automation to just call mochad.my_light.turn_on/off.

This would trigger an actual remote action to turn_on/off the x10 light on it’s controller (but it’s already in the on/off state so no-harm-no-foul?).

The tool I wrote currently would then mqtt _pub that state change request back to MQTT, but since HA actually initiated the light state change nothing would happen/trigger on HA.

Convoluted a tad and possibly open to recursion on error, but I could design around that with a timing/transaction flag or 2 which I currently have implemented to avoid identical x10 button presses in close sequence.

It would have been nice if HA mochad supported a “poll” feature to request the state of X10 devices using the native mochad “st” option and correct/mirror ha mochad.lights.

I’ll dig around ha.mochad and report back if I find anything way to poll and or push X10 controller light status back to HA…

9

It may be time to think about retiring devices using a very old technology like X10. I replaced most of my X10 devices (approximately 14) many years ago.

I still have two X10 devices (a 120V outlet and a 240V plug module). They still run reliably (both are over 15 years old) but will be replaced eventually.

The two X10 devices are controlled by a separate, and very old, home automation system (Premise Home Control) via a CM11A controller. Premise communicates with Home Assistant via MQTT using software I created about 8 years ago.

10

IMO, there is no need to retire my perfectly working 20+ year old X10 devices. In fact, with friends deprecating their X10 HW, I now have numerous brand-new external light and device switches, and internal light switches as spares, and a spare CM15 controller.

I did find a good deal for Z-wave devices (~$12/each) when Lowes was discontinuing switches 2 years ago and converted 1 location to use about 8 light ZW light switches. It’s been very reliable for a few years and solved the limitation of being able to query for existing state. If the expense was lower I may have bought more; but they are mostly expensive.

In retrospect, I wish I would have converted to Zigbee as there is better support and it’s slightly cheaper.

When I can upgrade for cheap I probably will. Until that time X10 it is :flushed:

11

Realistically X10 is almost free at this point, in that a lot of people have boxes full of X10 gear so you can pick up second hand devices for (almost) nothing.

The main issue with X10 is that the controllers / PC interfaces go bad - in that if a regular plug or dimmer module goes bad most of us have plenty of spares, however, if the controllers go bad typically we don’t have many spares (I had two CM11A’s and both have now died).

I could have purchased a CM15A to replace it and knowing what I know now, using Mochad it would have been possible to maintain the integration regardless of what PC I wanted to run Home Assistant on.

However I took the death of my last CM11A as the reason to bite the bullet and switch to a Zigbee network.

Powerline Protocol

The main advantages of newer tech over the Powerline protocol are:

  • Most X10 devices have no way to remotely query their status (**).
    • Their status can get out of sync if they are switched locally by power cycling the attached device.
  • Most US residences have two 120V circuits and the X10 signal can have difficulties crossing between circuits.
  • PL has low bandwidth:
    • If you are switching a single device (or multiple devices on the same code) you probably won’t notice it, but if you have to turn on multiple devices it can take time.***
    • Devices have to wait for a gap in the transmission to send messages.
  • Dimming is very poorly implemented:
    • The more expensive modules have preset levels.
    • However the cheaper ones require repeated dim commands to be sent - which don’t work predictably, if there is noise on the electrical system.
    • The lights come on a full brightness then you have to dim them.

** - The controllers (at least the CM11A) have the capability to monitor one house code and remember the state of every device based on the packets they have sent/seen.

*** - I am aware that at the lowest level it’s possible to send a compressed PL packet to switch multiple X10 devices with different codes simultaneously.

Radio Frequency Protocol

The RF protocol is a mixed bag:

  • Latency and bandwidth is comparable to newer tech - you probably won’t have an issue.
  • The lower frequency 310 MHz (US) typically penetrates walls pretty well.
  • It’s a hub and spoke model, rather than a mesh network.
  • Only a limited number of devices use the RF protocol typically battery powered sensors and buttons.

TL;DR - If like me you consider X10 to be free, there will never be a time when it makes financial sense to switch.

It becomes a question of whether you want the additional functionality provided by newer tech.