Status change and MQTT publication

Configuration
22

What are you receiving ?

Could be your topic :

Best practices

Never use a leading forward slash

A leading forward slash is permitted in MQTT. For example, /myhome/groundfloor/livingroom. However, the leading forward slash introduces an unnecessary topic level with a zero character at the front. The zero does not provide any benefit and often leads to confusion.

Never use spaces in a topic

A space is the natural enemy of every programmer. When things are not going the way they should, spaces make it much harder to read and debug topics. As with leading forward slashes, just because something is allowed, doesnā€™t mean it should be used. UTF-8 has many different white space types, such uncommon characters should be avoided.

Keep the topic short and concise

Each topic is included in every message in which it is used. Make your topics as short and concise as possible. When it comes to small devices, every byte counts and topic length has a big impact.

Use only ASCII characters, avoid non printable characters

Because non-ASCII UTF-8 characters often display incorrectly, it is very difficult to find typos or issues related to the character set. Unless it is absolutely necessary, we recommend avoiding the use of non-ASCII characters in a topic.

Embed a unique identifier or the Client Id into the topic

It can be very helpful to include the unique identifier of the publishing client in the topic. The unique identifier in the topic helps you identify who sent the message. The embedded ID can be used to enforce authorization. Only a client that has the same client ID as the ID in the topic is allowed to publish to that topic. For example, a client with the client1 ID is allowed to publish to client1/status, but not permitted to publish to client2/status.

Donā€™t subscribe to

Sometimes, it is necessary to subscribe to all messages that are transferred over the broker. For example, to persist all messages into a database. Do not subscribe to all messages on a broker by using an MQTT client and subscribing to a multi-level wildcard. Frequently, the subscribing client is not able to process the load of messages that results from this method (especially if you have a massive throughput). Our recommendation is to implement an extension in the MQTT broker. For example, with the plugin system of HiveMQ you can hook into the behavior of HiveMQ and add an asynchronous routine to process each incoming message and persist it to a database.

Donā€™t forget extensibility

Topics are a flexible concept and there is no need to preallocate them in any way. However, both the publisher and the subscriber need to be aware of the topic. It is important to think about how topics can be extended to allow for new features or products. For example, if your smart-home solution adds new sensors, it should be possible to add these to your topic tree without changing the whole topic hierarchy.

Use specific topics, not general ones

When you name topics, donā€™t use them in the same way as in a queue. Differentiate your topics as much as possible. For example, if you have three sensors in your living room, create topics for myhome/livingroom/temperature, myhome/livingroom/brightness and myhome/livingroom/humidity. Do not send all values over myhome/livingroom. Use of a single topic for all messages is a anti pattern. Specific naming also makes it possible for you to use other MQTT features such as retained messages.

23

If I wanted to take lessons I wouldnā€™t come to a forum ā€¦
Or is my mistake please?

24

what are you receiving. You can easily see that in Mqtt-explorer

25

Jā€™ai modifiĆ© comme cela et ca marche

- id: '1630600986202'
  alias: Fan Clin
  description: ''
  trigger:
  - platform: state
    entity_id: climate.chambre_parents
  condition: []
  action:
  - service: mqtt.publish
    data:
      topic: homeassistant/climatisation.parents_hvac_action
      payload_template: '{{ state_attr("climate.chambre_parents", "hvac_action") }}'
      qos: '1'
  - service: mqtt.publish
    data:
      topic: homeassistant/climatisation.parents_fan_mode
      payload_template: '{{ state_attr("climate.chambre_parents", "fan_mode") }}'
      qos: '1'
  mode: single

image

26

is this the best way to write the code?

27

Yes it is.

28

Hello, bonjour
is it possible to send a name for the data?
to avoid receiving
image