2022.6: Gaining new insights!

Blog
332

Three latest release has a temporary fix for that I believe.

333

I created an enhancement post about that. Vote for it.

1 Like
334

Check your indentation…here is what one of mine looks like:

mqtt:
  sensor:
  cover:
  switch:
  light:
    # MQTT lights
    # Insteon MQTT Lights
    - name: "Bonus Room Nook"
      unique_id: "36263498" #rng 1-100M
      schema: json
      state_topic: "insteon/26.ab.cd/state"
      command_topic: "insteon/26.ab.cd/level"
      brightness: true
335

Isn’t it same?

option:
- xxx
  yyy
  zzz

vs

option:
  - xxx
    yyy
    zzz
336

no, the list definition (- ...) needs to be indented

337

It shouldn’t be necessary; it’s the relative indentation that’s important to the YAML processor (see petro’s post).

FWIW, most of my automations (and other YAML configs) are indented minimally, like this:

alias: whatever
trigger:
- platform: time
  at:
  - '08:30:00'
  - '20:30:00'
condition: []
action:
- variables:
    foo:
    - 'cat'
    - 'hat'
- choose:
  - conditions: "{{ ... etc .. }}"
    sequence:
    - service: notify.whatever
      ... etc ..
1 Like
338

Yep, that’s how I do it. Less left and right movement.

339

Interesting, I thought it was more strict but that must just be me being anal

@foxy I think your problem is that you’ve used light. in the unique_id when it should just be the id without the light domain.

I could be wrong though, if that doesn’t work maybe try using availability_topic instead of availability: topic just to see if there’s any difference in the error you get

340

Mine is in zone2. It must depend on the specific model of NUC.

341

Learn something new everyday :slight_smile:

342

Did you update average. There have been a couple of fixes recently

343

This is probably due to me not changing over MQTT sensors yet but I noticed that reloading manual mqtt configuration only updates the sensors not binary sensors. More testing to follow but as of now mqtt binary sensors are only reloaded on restart.

344

there will be a Reload option on the integration panel some time soon, so all entities can be reloaded from there.

for now I have severe issues with reloading the MQTT entities , see few posts above

maybe it is because I no longer have platform: mqtt sensors and moved them all to the new mqtt: format.

its nasty because I was experimenting with several availability options in the sensors configs, and reloaded, only to find out my whole instance was taken down…

too bad we dont have an availability_template option we can relate to the state topic, and need a special availability topic (which none of my sensors have)

would love to be able to do:

  binary_sensor:

    - unique_id: amp_left_auditorium_state_binary
      state_topic: '70:B3:D5:6F:31:F2/powerswitch-zwave/c5745b57/state'
      name: Amp left Auditorium state
      <<: &binary
        payload_on: 'on'
        payload_off: 'off'
        device_class: power
        availability_template: >
          {{ value in ['on','off'] }}

or

    - unique_id: temperatuur_living
      state_topic: '70:B3:D5:6F:31:F2/sensormultilevel-zwave-airtemp/0c926d01/airtemp'
      name: Temperatuur Living
      icon: mdi:thermometer
      unit_of_measurement: °C
      device_class: temperature
      value_template: >
        {{value|round(1,default=none)}}
      availability_template: >
        {{ is_number(value) }}
345

Yes, I did. I haven’t had time to dig deep but the problem seems to clear up if I compress the DB. Then a couple days later the average sensor gets results that are way off. Recently saw the average humidity = to 150% where the humidity sensor was around 20%. This just started with 2022.6 update.

Once it reports weird values it stays weird until I compress and then everything is normal again.

346

There were a number of suggestions:

  1. Indentation: Other comments have already verified this, but I did test the indentation before posting and discovered that it could go either way, which is nice because it saves the hassle of adding the indent to every line when converting to this new format!
  2. Included light. in the unique_id: I haven’t had any issues with that; there are no errors listed for that line and it worked fine when changing the id’s to include _mqtt for my Alexa globs. Even if this were an issue, it wouldn’t change the error on schema, which appears to only allow default.
  3. Change the way availability is formatted - same as above; either layout works fine and changing this would not affect the schema error.

Seems to me that this is likely a bug that needs to be fixed? EDIT TO ADD: I just tried schema: default and got no error and schema: template and got an error to include a required configurable variable, indicating that template is an accepted schema.

347

Hi,
I’ve just updated my configuration and seems everything is working fine.
My configuration.yaml file looks like this:

#sensor others: !include sensors.yaml
#switch: !include switch.yaml
mqtt:
    sensor: !include mqtt_sensors.yaml
    switch: !include mqtt_switches.yaml

The commented rows were my previous configuration.
An example of my mqtt_sensors.yaml file is:

  - name: "Corrente"
    state_topic: "tele/tasmota_consumi/SENSOR"
    value_template: "{{ value_json['ENERGY'].Current }}"
    unit_of_measurement: "A"
  - name: "Potenza Ist."
    state_topic: "tele/tasmota_consumi/SENSOR"
    value_template: "{{ value_json['ENERGY'].Power }}"
    unit_of_measurement: "W"
348

More details of MQTT consider_home changes here:

349

I thought I would provide you with my experience…I have moved all my MQTT YAML configs to the new format and running 2022.6.2, the MQTT reload works. I will add that after about 20-30 seconds I do get a lot of errors but they are related to cover groups which seems to be an issue with the group utility code and not the MQTT reload specifically. I find also that my MQTT entities take about the same 20-30 seconds to show up again after reload, so I deduce that it takes this long for the reload to actually process. During this 20-30 seconds I now get an occasional warning about some other integration taking more than 10 seconds to do something. But nevertheless all works when finished reloading.

350

You might be interested in an another user’s comments regarding loading time. I had helped them convert from defining MQTT entities via YAML to MQTT Discovery. Basically, you make a script that publishes the configuration information in the format accepted by MQTT Discovery and it creates the entities. It also lets you define devices which is something you can’t currently do in YAML.

The user converted 130 entities, from YAML to MQTT Discovery, and reported the following observation:

Loading time for MQTT reduced from 68 to 5.9 seconds

An example of a script, to create an MQTT entity via MQTT Discovery, is posted here and is followed by the user’s reply.

2 Likes
351

Thanks. I actually spent a fair bit of time reading that post a few months ago proving the concept out (to myself), but never took the time to convert mine over. I had not picked up on the time savings. Again thanks for the tip :slight_smile: