0.87.1 Update breaks sensors?

Installation Home Assistant OS
1

Seems like every update I do lately breaks my setup?
Just got false positive on the garage door - scary stuf when your not home!
Running latest version 0.87.1

What should I do?

image
image1504Ă—888 105 KB

2

Any warning/error messages in Home Assistant’s log?

Can you post the configuration of one or two of the affected binary_sensors?

My guess is there may be an invalid option specified. Version 0.87.X no longer ignores invalid options but will identify and complain about them (and refuse to register the entity).

1 Like
3

Just tried to do a validate after updating and I get allot of errors now (I had 0 before)
This must be a major release update?

image

  customize:
    # Add an entry for each entity that you want to overwrite.
    binary_sensor.garagedoor:
      friendly_name: Garage Door

  house_sensors:
    name: House sensors
    control: hidden
    entities:
      - binary_sensor.main_door
      - binary_sensor.back_door
      - binary_sensor.main_door2
      - binary_sensor.garagedoor

# Automations notification for Garage door open if Nobodys home 
  - alias: Garagedoor
    hide_entity: true
    initial_state: 'on'
    trigger:
    - platform: state
      entity_id: binary_sensor.garagedoor
      to: 'on'
# Only when the adults are not home <--
    condition:
      - condition: and
        conditions:
        - condition: state
          entity_id: sensor.henrik_presence
          state: 'not_home'
        - condition: and
          conditions:  
        - condition: state
          entity_id: sensor.nina_presence
          state: 'not_home'
# Comment above lines out to enable garagedoor notification ALWAYS <--
    action:
      - service: notify.ios_group_caspersen_home
        data:
          message: "Garagedøren er åben? {{ states('sensor.time') }}"
          title: "Home Assistant"
4

The error message identifies the source of the problem. Several of you binary_sensors are configured with an invalid option. optimistic is not a valid configuration variable for an MQTT Binary Sensor.

Prior to 0.87, Home Assistant would ignore invalid options but not any more. See the last item in Breaking Changes.

MQTT platforms will now flag mistyped configs from configuration.yaml correctly as invalid, instead of just ignoring them. (@emontnemery - #20562) (mqtt docs) (breaking change)

5

But they are all set to false?
and according to the guide (At that point in time anyway)

So do I just delete all these lines?

cover:

  • platform: mqtt
    name: “Sonoff SV Garage”
    state_topic: “cmnd/garagestate/POWER2”
    command_topic: “cmnd/Sonoff_SV_Garage/POWER”
    payload_open: “ON”
    payload_close: “ON”
    payload_stop: “ON”
    state_open: “ON”
    state_closed: “OFF”
    optimistic: false <---------delete
6

Yes, delete them. There’s no such thing as optimistic mode for a binary_sensor. It is typically available for components that can transmit commands, like MQTT Cover.

7

And that shouldnt affect funtionality?

I also get error on RETAIN? but I think I need them for it to remember previous state?

# Sonoff switches
  - platform: mqtt
    name: "Sonoff B1"
    command_topic: "cmnd/Sonoff_B1/power"
    state_topic: "stat/Sonoff_B1/POWER"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    retain: true
8

Please explain how adding an invalid option to a component’s configuration can improve its functionality? It’s invalid and unused by the component.

I also get error on RETAIN?

For which entity? If you specified retain for an MQTT component that publishes nothing, like a binary_sensor, then Home Assistant 0.87 will identify it as an error. Check the binary_sensor’s documentation, there’s no retain option.

9

@123 and thanks for taking the time to help me!

RF Motion sensor key E565EE

retain: false

RF Garage Door contact sensor

  • platform: mqtt
    qos: 1
    retain: false

Found them in allot of places

10

Okay for some reason I dont get the line numbering on the errors anymore so its hard to find what needs to be changes

Reading the links it looks like ratin is ok for switches…so most be for all the others

image

11

MQTT Switch publishes messages to a topic (via command_topic) therefore it makes sense this component offers the retain option (although there are valid reasons for setting this to retain: false which happens to be the default setting).

12

Ok so it should be enough to remove this from binary sensors

binary_sensor:

# RF Motion sensor
  - platform: mqtt
    state_topic: "tele/RF_Bridge1/RESULT"
    name: 'Garage Motion'
    value_template: '{{value_json.RfReceived.Data}}'
    payload_on: ''
    payload_off: ''
    device_class: motion
    qos: 1
#    retain: false

just removed from every binary sensor and I got “Configuration valid!”

so everything should be back up and running after a reboot

Thanks for your help!

1 Like
13

last question I promise! :wink:

the switch for the garageport now changed after the removal, and now it looks like this

image

but I still have my:

cover.sonoff_sv_garage:
device_class: garage
homebridge_cover_type: garage_door
friendly_name: Garageport

Could this be related to another change, and not the removal of retain & optimistic

14

I can’t make sense of this:

Please post the entire formatted configuration for the cover. Is the cover’s friendly_name in the customize.yaml file?

15

no I have everything in the configuration yaml file

  customize:
    cover.sonoff_sv_garage:
      device_class: garage
      homebridge_cover_type: garage_door
      friendly_name: Garageport

# Garageport switch DIY
cover:
  - platform: mqtt
    name: "Sonoff SV Garage"
    state_topic: "cmnd/garagestate/POWER2"
    command_topic: "cmnd/Sonoff_SV_Garage/POWER"
    payload_open: "ON"
    payload_close: "ON"
    payload_stop: "ON"
    state_open: "ON"
    state_closed: "OFF"

##########################
###  Garage Switch     ###
##########################
  - platform: template
    switches:
      garage:
        value_template: "{{ is_state('cover.sonoff_sv_garage', 'open') }}"
        turn_on:
          service: cover.close_cover
          data:
            entity_id: cover.sonoff_sv_garage
        turn_off:
          service: cover.open_cover
          data:
            entity_id: cover.sonoff_sv_garage
        icon_template: >-
          {% if is_state('cover.sonoff_sv_garage', 'open') %}
            mdi:garage-open
          {% else %}
            mdi:garage
          {% endif %}

group:
  garage_door:
    name: Garageport
    view: no
    control: hidden
    icon: mdi:garage
    entities:
      - cover.sonoff_sv_garage
      - switch.garage

That should be everything, and some notification on the state

16

That’s a weird configuration.

You have a group, that includes both the cover and a template switch, that uses the cover to provide the switch. Why?

According to documentation retain and optimistic are still available for cover MQTT.

I’m confused by your setup

17

I made a switch for the garageport and also created the “real” garage function in home assistant.

  - cover.sonoff_sv_garage
  - switch.garage

The switch was needed to get it working as a switch in google assistant or Siri - can’t remember
Is this a problem?

Its not different than having all the switches defined as both switches and lights

18

Its still there

image
image726Ă—52 5.26 KB

So wouldnt the friendly name be changed by:

  customize:
    cover.sonoff_sv_garage:
      device_class: garage
      homebridge_cover_type: garage_door
      friendly_name: Garageport
19

Google assistant sees covers just fine.

I don’t know if it’s a problem but it seems like redundant work for no benefit

20

Any input to why Home assistant dosent see it as Garage port?
Deleting the switch dosent solve it…

And for some reason it ignores the:
customize:
cover.sonoff_sv_garage:
device_class: garage
homebridge_cover_type: garage_door
friendly_name: Garageport

The icon worked before showing open and closed correctly?
This update really calls for many changes :thinking: