2022.6: Gaining new insights!

I am experiencing the same using the custom Average integration.

l’ve mentioned that during the betas and in some of the issues. There were/are a lot of issues with live logbook and the changed behavior in filtering. Because of that, the pause button might have lost attention :wink:

dev team has been working hard to smash those issues, so its not yet a finished product.
It might be good though to add it to a FR and gain some +'s on it.
Hopefully Nick can respond to that if its up.

1 Like

Anyone else experience issues with reloading of MQTT entities (either tirjugh quickbar or dev tools yaml)? even though Fix reload of MQTT yaml config by emontnemery · Pull Request #72901 · home-assistant/core · GitHub, I find that the system hangs and after some time spontaneously restarts…

even after having checked the config to be valid.
Which it is, because upon restart the new mqtt config is loaded correctly and all states are back.

All of my MQTT entities are of the new mqtt: format.

I’m converting my mqtt devices. I understand the new layout and have successfully converted other device types, but I am having issues with lights. I’m using the json schema, but I get the following error on that line (schema: json): Value is not accepted. Valid values: “default”. I then of course get the error that brightness, color_mode and supported_color_modes properties are not allowed. Looking at mqtt light documentation and samples (MQTT Light - Home Assistant) shows that the default, json and template options are still all supported.

mqtt:
  light:
  - schema: json
    name: String
    unique_id: light.string_2_mqtt
    state_topic: "livingroom/dimmer"
    command_topic: "livingroom/dimmer/set"
    availability:
      - topic: "livingroom/availablity"
    brightness: true
    color_mode: true
    supported_color_modes: ["brightness"]
    retain: true

Any ideas on what is causing this?

1 Like

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

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

1 Like

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

Isn’t it same?

option:
- xxx
  yyy
  zzz

vs

option:
  - xxx
    yyy
    zzz

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

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

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

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

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

Learn something new everyday :slight_smile:

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

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.

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) }}

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.

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.

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"