Hi all,
Since update 2024.8 I have the message that the payload_template parameter of MQTT publish will be deprecated in 2025.2.0.
In most cases it worked to replace payload_template by payload . However, there is one place where it changes the data and breaks the functionality, and thatās when I need to send a binary value to an MQTT to RS485 gateway that will poll a solar controller.
In this case, the data is sent as a string of bytes mixed with characters and hexadecimal sequences.
Here is the script used to reproduce the problem :
data_template:
retain: true
topic: test/sendbin
payload: >
{{ pack(0x0104, ">H") }}
{{ pack(0x3100, ">H") }}
{{ pack(0x0014, ">H") }}
{{ pack(0xFEF9, ">H") }}
action: mqtt.publish
And here are the results in āMQTT Explorerā.
In the first case (payload ) we receive a string of bytes (bā\x01\x041\x00\x14\xfe\xf9ā), in the second case (payload_template ) we receive a string of 8 characters (few of which are printable), which is what I want.
Anyone have any ideas on how I can fix this? Or do I need to open a bug report?
Maybe Iāve done it all wrong and thereās a better way?
Thanks.
jchh
((not John))
August 13, 2024, 2:47pm
2
The payload
one is right though, isnāt it?
The payload I got with payload_template, yes, but not the big string of mixed chars and hex values.
I can live with payload_template for now, but given the deprecation Iāll have to change.
jchh
((not John))
August 13, 2024, 3:48pm
4
I honestly donāt know what you mean by this but, I had (I think) a similar issue whereby I was calling a script (that had mqtt.publish
in it and I used the variable {{ payload }}
for `payload, so it looked like this:
- action: mqtt.publish
data:
topic "..."
payload_template "{{ payload }}"
This worked with payload_template
but not with payload
and some kind soul (thanks, @123 ) suggested changing the variable to something other than payload
ā¦and it worked!
so it now looks like:
- action: mqtt.publish
data:
topic "..."
payload "{{ message }}"
Is this applicable to you?
Thanks for your hint. Unfortunately I donāt use a variable in the payload, so the case is not quite the same.
Iāll try to be clearer.
In both cases the payload is the same:
{{ pack(0x0104, ">H") }}
{{ pack(0x3100, ">H") }}
{{ pack(0x0014, ">H") }}
{{ pack(0xFEF9, ">H") }}
If I use payload_template: , I get this MQTT message:
And if I use payload: , I get this:
In the first case, I have my 8 characters (4x2), but in the second I have 32 characters, which no longer corresponds to the payload at all.
jchh
((not John))
August 14, 2024, 5:33am
6
what should the result look like? (is the payload_template
(below) correct?
Iām wondering whether you need a filter. Appreciating that you are not using a variable, one of the suggestions that @123 gave me was to use:
{{ desc[should] | to_json }}
would that correspond to:
{{ pack(0x0104, ">H") | to_json }}
{{ pack(0x3100, ">H") | to_json }}
{{ pack(0x0014, ">H") | to_json }}
{{ pack(0xFEF9, ">H") | to_json }}
Iām guessing that | to_json
is incorrect for your use case, but perhaps there is another filter for you? Is the payload in a particular format?
ā¦perhaps:
{{ pack(0x0104, ">H") | to_json(ensure_ascii=False) }}
{{ pack(0x3100, ">H") | to_json(ensure_ascii=False) }}
{{ pack(0x0014, ">H") | to_json(ensure_ascii=False) }}
{{ pack(0xFEF9, ">H") | to_json(ensure_ascii=False) }}
The result should be the value 0x010431000014FEF9, which is represented in MQTT explorer by:
Unfortunately, JSON format is not an option, as the controller expects an 8-byte hex command. And I canāt modify it.
Thanks for the advice, Iāve tried it, including other solutions, but nothing conclusive so far.
Iāve opened a bug report:
opened 08:45AM - 14 Aug 24 UTC
integration: mqtt
### The problem
When trying to send raw data via MQTT, if I replace payload_temā¦ plate with payload (as the note on payload_template depreciation in 2025.2.0 advises) the data is transformed.
It is converted into a byte array with escape characters, instead of raw data.
I want to send this `{{ pack(0xDEADBEEF, ">L") }}` :
- with **payload_template** I get `DEADBEEF` (in hex, which is correct and is not representable as a string)
- with **payload** I get `62275C7864655C7861645C7862655C78656627` (in hex) which represents the string `b'\xde\xad\xbe\xef'`
### What version of Home Assistant Core has the issue?
core-2024.8.1
### What was the last working version of Home Assistant Core?
_No response_
### What type of installation are you running?
Home Assistant OS
### Integration causing the issue
MQTT
### Link to integration documentation on our website
https://www.home-assistant.io/integrations/mqtt/
### Diagnostics information
[home-assistant_mqtt_2024-08-14T08-30-24.428Z.log](https://github.com/user-attachments/files/16610007/home-assistant_mqtt_2024-08-14T08-30-24.428Z.log)
### Example YAML snippet
```yaml
data_template:
retain: true
topic: test/bindata
payload: |
{{ pack(0xDEADBEEF, ">L") }}
action: mqtt.publish
```
### Anything in the logs that might be useful for us?
_No response_
### Additional information
To get raw hex content from topic I use :
`mosquitto_sub -h <host> -t 'test/bindata' -F "%0X"`
Weāll see what happens.
jchh
((not John))
August 14, 2024, 9:38am
8
Someone way more capable than me may be able to chime in. Either way, best of luck!
Well it looks like it was an issue, jbouwh made a PR to fix it.
home-assistant:dev
ā home-assistant:mqtt-publish-raw
opened 11:41AM - 14 Aug 24 UTC
<!--
You are amazing! Thanks for contributing to our project!
Please, DO NOTā¦ DELETE ANY TEXT from this template! (unless instructed).
-->
## Proposed change
<!--
Describe the big picture of your changes here to communicate to the
maintainers why we should accept this pull request. If it fixes a bug
or resolves a feature request, be sure to link to that issue in the
additional information section.
-->
With #122098 and #123706 we deprecated the use of the `payload_template` option for the mqtt `publish` action and we expected this to be functionally to be fully equal.
Now it seems that a rendered template is not evaluated like we did with the `payload_template`. This means that if a raw payload was intended, it will send the `utf-8` encode string representation instead of the ray data.
This PR ensures that the rendered template `payload` will be evaluated and if it is raw data, it will publish it as raw data as we did for the deprecated `payload_template` option.
## Type of change
<!--
What type of change does your PR introduce to Home Assistant?
NOTE: Please, check only 1! box!
If your PR requires multiple boxes to be checked, you'll most likely need to
split it into multiple PRs. This makes things easier and faster to code review.
-->
- [ ] Dependency upgrade
- [x] Bugfix (non-breaking change which fixes an issue)
- [ ] New integration (thank you!)
- [ ] New feature (which adds functionality to an existing integration)
- [ ] Deprecation (breaking change to happen in the future)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
## Additional information
<!--
Details are important, and help maintainers processing your PR.
Please be sure to fill out additional details, if applicable.
-->
- This PR fixes or closes issue: fixes #123865
- This PR is related to issue:
- Link to documentation pull request:
## Checklist
<!--
Put an `x` in the boxes that apply. You can also fill these out after
creating the PR. If you're unsure about any of them, don't hesitate to ask.
We're here to help! This is simply a reminder of what we are going to look
for before merging your code.
-->
- [x] The code change is tested and works locally.
- [x] Local tests pass. **Your PR cannot be merged unless tests pass**
- [x] There is no commented out code in this PR.
- [x] I have followed the [development checklist][dev-checklist]
- [x] I have followed the [perfect PR recommendations][perfect-pr]
- [x] The code has been formatted using Ruff (`ruff format homeassistant tests`)
- [x] Tests have been added to verify that the new code works.
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated for [www.home-assistant.io][docs-repository]
If the code communicates with devices, web services, or third-party tools:
- [ ] The [manifest file][manifest-docs] has all fields filled out correctly.
Updated and included derived files by running: `python3 -m script.hassfest`.
- [ ] New or updated dependencies have been added to `requirements_all.txt`.
Updated by running `python3 -m script.gen_requirements_all`.
- [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
<!--
This project is very active and we have a high turnover of pull requests.
Unfortunately, the number of incoming pull requests is higher than what our
reviewers can review and merge so there is a long backlog of pull requests
waiting for review. You can help here!
By reviewing another pull request, you will help raise the code quality of
that pull request and the final review will be faster. This way the general
pace of pull request reviews will go up and your wait time will go down.
When picking a pull request to review, try to choose one that hasn't yet
been reviewed.
Thanks for helping out!
-->
To help with the load of incoming pull requests:
- [ ] I have reviewed two other [open pull requests][prs] in this repository.
[prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone+-status%3Afailure
<!--
Thank you for contributing <3
Below, some useful links you could explore:
-->
[dev-checklist]: https://developers.home-assistant.io/docs/development_checklist/
[manifest-docs]: https://developers.home-assistant.io/docs/creating_integration_manifest/
[quality-scale]: https://developers.home-assistant.io/docs/integration_quality_scale_index/
[docs-repository]: https://github.com/home-assistant/home-assistant.io
[perfect-pr]: https://developers.home-assistant.io/docs/review-process/#creating-the-perfect-pr
Iāll wait until I can test it and then Iāll close this topic.
1 Like
Tested just now with version 2024.9.0, everything works fine