[work around] Setting up a custom mqtt device/component (switch/light) that doesn't fit with built in components

Configuration
1

I have a custom device that uses json packets over a tcp socket but I also built a module to interface with an mqtt client/broker allowing HA(and others) to control/monitor my device. It does do by converting a json cmd key to the topic and all the rest to a json payload. Going the other way the topic gets converted to value of ‘cmd’ key and payload to a data key if it’s a string or a json if it’s json (and vice versa).

So for example to turn on a light it would the tcp socket packet would look like this.

{ cmd:'swtich/on', id:'id_of_swtich_in_db' }

so in an mqtt client like mqtt box I have a topic of 'switch/on' and a payload of {"id":"id_of_swtich_in_db"} and that works fine.

The other direction if an mqtt client is subscribed to status/switch for example a json packet sent of
{ cmd:'status/switch', id:'someid', state:'on', anotherkey:'some stuff'} will arrive as the json payload

But the built in generic HA mqtt swtich/light component puts the action in the payload and the identification in the topic.

That is backward of my device. There is only a single topic command not a topic on command and a topic off command in the built in component.

Can I modify an exciting (swtich/light) component to work? Is there maybe another component listed that works the way mine does that I can use? Ill have the same issue with state as they will be a json payload with switch id and state therein.

So some tips/suggestions appreciated including how to send a payload that’s json.

2

Another idea might be to bypass mqtt just talk with the tcp socket directly? Sending TCP packets to a device

Seems more involved though because that packet is serialized and sent as a buffer stream and vice versa at the other end. I wrote both tcp socket client and server modules to do that and I’d have to write special HA component (in python?) to do that and I’m a nodejs coder. That’s why I wrote a mqtt module to avoid that.

3

One might be able to use the mqtt.publish service. So my question is still unsolved using just HA as is.

But as a work around I changed my code so that the topic is just the avenue for sending a json payload with all the right props/keys.

so

topic switch

with on payload { \"cmd\": \"switch\/on\", \"id\": \"blue36-JPZg\" }
off payload { \"cmd\": \"switch\/off\", \"id\": \"blue36-JPZg\" }

so the only “irritating thing” is having to come up with escaped json. Wouldn’t it be cool if that component (and others) could accept yaml string in place of escaped json for payload. In the meantime I’ll just use these two websites to make this the process easier and put the yaml payload in a comment above for easy view/change

https://www.json2yaml.com/
https://www.freeformatter.com/json-escape.html#ad-output

4

Have you looked at the documentation? The template version of this covers what you are looking for

examples of json payloads

5

Probably because your device works backward to 90% of all devices that use MQTT.

  • The topic is typically used to define the device and/or a property of a device.
  • The payload is typically used to define the device’s value or action.

See:

For example:

Topic: sensor/outdoor/temperature
Payload: 18

Topic: sensor/indoor/humidity
Payload: 36

Topic: home/kitchen/light/state
Payload: on

Topic: home/kitchen/light/brightness
Payload: 85

You have it working the other way around.
Topic: light/on
Payload: kitchen

Given that you created the TCP to MQTT interface, you can change it so the topic identifies the device and the payload contains the value/action. So if the TCP socket packet is this:

{ cmd:'switch/on', id:'id_of_switch_in_db' }

your converter transforms it into this:

Topic: switch/id_of_switch_in_db
Payload: ON

If you want the payload to contain more than one parameter then use JSON format. For example, if your TCP socket packet is this:

{ cmd:'status/switch', id:'someid', state:'on', anotherkey:'some stuff'}

your converter transforms it into this:

Topic: switch/someid
Payload: {"state":"ON", "anotherkey":"some stuff"}
6

There are very good reasons to use the convention I did. It has to to with calling functions in nodejs code on remote devices/process that get passed a packet. Supporting mqtt/HA was just a bonus. So yea MQTT/HA has it’s convention. Rather than battle this I wrote today into my code the ability to hook into the packet sending (include mqtt bound packets) which allows one to rewrite them for HA use. So I had already done what you suggest @123 moving the id to the topic and the state to the payload . Now my question is all moot. I just thought there might be a way other than hooking and modifying packets but obviously that was just swimming upstream.