MQTT breaking changes RC 2022.6

Configuration
#21

This ADR is interesting…

This is something that really confused me when I built my little integration: it’s a media player (i.e. configured under the media_player section in YAML), but it uses MQTT. So, the integration in this case is the media player, and the platform is MQTT, but originally it wasn’t clear to me which way around this had to be. Now I’m wondering whether I will need to update this at some point to sit under an mqtt: section. I think, the class/type/function of something should be treated differently to how it connects. I’m possibly missing something subtle here, but it seems like the concepts are getting mixed. Personally, I like to think of the domain as the top level concept, with the mechanism (templates, MQTT, REST) as secondary to that. I’ll deal with it either way, but thought I’d bring this up.

1 Like
#22

HA is moving away from YAML to UI configuration to, I assume, become more accessible to new users. It would be madness to set up lights under “Lights”, unless they were MQTT lights, in which case you had to set them up under “MQTT” (or unless they were “Templates”, etc etc). Once it’s all done, you can’t imagine a new screen where you manage all of your lights in one place.

#23

No, its actually neither of those. Your integration is called shairpoint_sync therefore if you are trying to follow that ADR then all config for it should be under the key sharepoint_sync in configuration.yaml. So something like this:

shairpoint_sync:
  name: Shairport Sync Player
  topic: your/mqtt/topic

If your integration supported multiple platforms and each had their own options then it might be more like this:

shairpoint_sync:
  media_player:
    name: Shairport Sync Player
    topic: your/mqtt/topic
  sensor:
    name: Shairport Sync Player sensor
    topic: your/mqtt/topic

The fact that your integration uses mqtt under the hood isn’t relevant. How your integration actually communicates with its external devices/services is an implementation detail. Ideally you hide those kinds of details from the user and simply expose options that make sense without requiring the user to actually know how it works under the hood.

MQTT makes this confusing since its a communication protocol rather then a specific service. But the thing to remember is that the only config that can be under the mqtt key in configuration.yaml is stuff actually handed to the mqtt integration. You need your config to be handed to the shairpoint_sync integration not the mqtt integration so it can’t be under mqtt. It either has to be under a shairpoint_sync key or using the old style with a platform key under media_player.

Also keep in mind that ADRs apply to core integrations. ADRs are enforced by code reviews and no one is reviewing custom integrations but the author(s). If you were thinking of contributing that back to core then yea you’d need to follow the ADRs. But if you just want to leave it in HACS then you can continue doing whichever approach you prefer here.

#25

Yeah, I buggered up my own example…

It’s actually this:

So TIL that it’s the old way – I didn’t know that.

I agree 100% with that statement, but it seems to contradict the main point, which is to put things under a mqtt: key/section. It’s just a comms layer – like HTTP, etc. which I think is your point too:

And the above is what I’m kind of questioning or trying to understand better. I know I’ll probably not get the true answer here unless one of the devs chime in, but it’s good to hear all the explanations regardless.

True, but I personally try to follow best practices and keep the options open. It wasn’t really to talk about my contribution, but it’s an example I understand well, which was the reason I used it.

#26

It’s besides the point. I know this, and I’m fine with that and yes that’s the reason it’s being done. I need to add the config flow to my stuff – but that’s another topic.

I don’t understand why this seems illogical – or mad.

#27

Having a nightmare with this
My configuration.yaml file:

mqtt: !include_dir_merge_named mqtt/
sensor: !include_dir_merge_list sensors

because I have sensors that are not MQTT
I have 2 files in mqtt:
acurite-humidity.yaml

sensor:
- name: "Indoor Humidity"
#'acurite/humidity'
  state_topic: "home/rtl_433"
  unit_of_measurement: '%'
  value_template: >
    {% if value_json is defined and value_json.id == 11794 %}
      {{ value_json.humidity }}
    {% else %}
      {{ states('sensor.indoor_humidity') }}
    {% endif %}

and acurite-temperature.yaml

sensor:
- name: "Indoor Temp"
#'acurite/temp'
  state_topic: "home/rtl_433"
  unit_of_measurement: '°C'
  value_template: >
    {% if value_json is defined and value_json.id == 11794 %}
      {{ value_json.temperature_C }}
    {% else %}
      {{ states('sensor.indoor_temp') }}
    {% endif %}

HA only shows the first sensor.
You can’t put more than 1 sensor in the same file - get an error.
(this was all working before the mqtt change!)

#28

Unfortunately, YAML - Home Assistant documents the old syntax to explain nesting a collection of mappings in a mapping.

sensor:
  - platform: mqtt
    state_topic: "sensor/topic"
  - platform: mqtt
    state_topic: "sensor2/topic"

It will be very confusing for some time to those of us struggling to understand YAML syntax.

1 Like
#29

Because you’re using merge dir named. If you want to use it that way, you have to make separate folders for each domain…

mqtt:
  sensor: !include_dir_merge_list mqtt/sensor/

And then remove sensor: from your files.

Or if you want to use merge_named, then you can only have 1 file per domain.

1 Like
#30

can’t use the keyword ‘sensor’ more than once in configuration.yaml
and I have other non mqtt sensors

#31

got it!
configuration.yaml:

mqtt:
  sensor: !include_dir_merge_list mqtt/
sensor: !include_dir_merge_list sensors

mqtt/humidity.yaml

- name: "Indoor Humidity"
#'acurite/humidity'
  state_topic: "home/rtl_433"
  unit_of_measurement: '%'
  ....
#32

I have a number of MQTT devices and would like to get ahead of 2022.9 and not repeat my debacle of waiting too long to change my Z-Wave stuff.
So, what’s wrong here?

OLD:

switch:
  - platform: mqtt
    name: "steve_Heat"
    command_topic: "cmnd/steve_heat/power"
    state_topic: "stat/steve_heat/POWER"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    retain: false

NEW:

mqtt:
  switch:
    -name: "steve_Heat"
     command_topic: "cmnd/steve_heat/power"
     state_topic: "stat/steve_heat/POWER"
     qos: 1
     payload_on: "ON"
     payload_off: "OFF"
     retain: false

Is there a dictionary or Rosetta stone that helps interpret the error messages?
What is a <block end> and a '<block mapping start>' ?
[Edit to fix forum software munging my question].

#33 
mqtt:
  - switch:
      - name: "steve_Heat"
        command_topic: "cmnd/steve_heat/power"
        state_topic: "stat/steve_heat/POWER"
        qos: 1
        payload_on: "ON"
        payload_off: "OFF"
        retain: false
#34

I didn’t notice that my earlier question was munged by the forum software, so I’ll ask again in code tags.

Also your suggested fix produced this error:

The system cannot restart because the configuration is not valid: Error loading /config/configuration.yaml: while parsing a block mapping in "/config/configuration.yaml", line 262, column 7 expected <block end>, but found '<block mapping start>' in "/config/configuration.yaml", line 263, column 8

Is there a codex or universal translator to help understand, just what is a <block end> and a '<block mapping start>' ?

#35

Try this way. I have a similar switch setup in a package.

mqtt:
  switch:
    - name: "steve_Heat"
      command_topic: "cmnd/steve_heat/power"
      state_topic: "stat/steve_heat/POWER"
      qos: 1
      payload_on: "ON"
      payload_off: "OFF"
      retain: false
#36 
mqtt:
  switch:
  - name: "steve_Heat"
#37

Thanks guys. I knew it had to be in the indenting. FWIW, the formatting in the “breaking-changes” is also indented wrong.

Works now.

But, for future errors, and I will absolutely have more.

Should I be looking for a YAML 101 guide on the web?

#38

The indentation and formatting in breaking-changes is correct. The indentation in your original question was fine, your issue was the dash not having a space between your field.

Yaml only cares about relative indentation. These yaml examples are functionally the same:

mqtt:
 sensor:
 - name: ...

mqtt:
  sensor:
                            - name: ...

mqtt:
                         sensor:
                         - name: ...

This is what you did wrong:

image
image783×266 11.3 KB

1 Like
2022.6: Gaining new insights!
#39

Thanks. That explains a lot.

#40

Thanks for this @petro Got all 98 of mine switched over with this process.

#42

Hi there,

Please could someone assist me with my mqtt re-configuration. I have my mqtt files saved in one folder like this:

/config/packages/systems/ustou/ustou_lights.yaml

My old configuration was like this:

# Devices
light:
  - platform: mqtt
    name: "Entrance Hall Light"   
    command_topic: "cmnd/halllight/POWER"
    state_topic: "stat/halllight/POWER"
    payload_on: "ON"
    payload_off: "OFF"
    retain: true
    unique_id: entrance hall light
    
  - platform: mqtt
    name: "Dining Floor Light"
    command_topic: "cmnd/floorlamp/POWER"
    state_topic: "stat/floorlamp/POWER"
    payload_on: "ON"
    payload_off: "OFF"
    retain: true
    unique_id: dining floor light
    
  - platform: mqtt
    name: "Telephone Table Lamp"
    command_topic: "cmnd/table3/POWER"
    state_topic: "stat/table3/POWER"
    payload_on: "ON"
    payload_off: "OFF"
    retain: true
    unique_id: telephone table lamp

I have 3 .yaml files; one for sensors, one for lights and one for switches

Now after changing to RC 2022.6 I changed the above to this:

# Devices
mqtt:
  light:
    - name: "Entrance Hall Light"    
      command_topic: "cmnd/halllight/POWER"
      state_topic: "stat/halllight/POWER"
      payload_on: "ON"
      payload_off: "OFF"
      retain: true
      unique_id: entrance hall light
    
    - name: "Dining Floor Light"
      command_topic: "cmnd/floorlamp/POWER"
      state_topic: "stat/floorlamp/POWER"
      payload_on: "ON"
      payload_off: "OFF"
      retain: true
      unique_id: dining floor light
    
    - name: "Telephone Table Lamp"
      command_topic: "cmnd/table3/POWER"
      state_topic: "stat/table3/POWER"
      payload_on: "ON"
      payload_off: "OFF"
      retain: true
      unique_id: telephone table lamp

Now after restart all lights are “unavailable” but switches and climate sensors are working…?

I changed my switches from this:

# Power Outlets
switch:
  - platform: mqtt
    name: "Mums Blanket"
    command_topic: "cmnd/mumblanket/POWER"
    state_topic: "stat/mumblanket/POWER"
    payload_on: "ON"
    payload_off: "OFF"
    retain: true
    
  - platform: mqtt
    name: "Dads Blanket"
    command_topic: "cmnd/dadblanket/POWER"
    state_topic: "stat/dadblanket/POWER"
    payload_on: "ON"
    payload_off: "OFF"
    retain: true
       
  - platform: mqtt
    name: "Lili Blanket"
    command_topic: "cmnd/liliblanket/POWER"
    state_topic: "stat/liliblanket/POWER"
    payload_on: "ON"
    payload_off: "OFF"
    retain: true

To this and they are still present and working in my dashboard:

# Power Outlets
mqtt:
  switch:
   -  name: "Mums Blanket"
      command_topic: "cmnd/mumblanket/POWER"
      state_topic: "stat/mumblanket/POWER"
      payload_on: "ON"
      payload_off: "OFF"
      retain: true
    
   -  name: "Dads Blanket"
      command_topic: "cmnd/dadblanket/POWER"
      state_topic: "stat/dadblanket/POWER"
      payload_on: "ON"
      payload_off: "OFF"
      retain: true
       
   -  name: "Lili Blanket"
      command_topic: "cmnd/liliblanket/POWER"
      state_topic: "stat/liliblanket/POWER"
      payload_on: "ON"
      payload_off: "OFF"
      retain: true

I made the same changes made to my sensors and switches, as I did to my lights. So I’m confused as to why the lights no longer work.

Any advice would be greatfully received.