This entity does not have a unique ID, 0.108.3

Hi there,
something has changed in latest hass.io updates. I have two sonoff-basic (tasmota, 8.x) garage-door opener solution (cover-template in configuration.yaml) . Worked like an charm. But since some days, I think it was update to 0.108.x I don’t get the sensor retain after hass - restarts. Read a lot here but I have no clue what to do. I know from tasmota doc’s that some sensors doesn’t work properly, but they did so far. So solution could be, to create an unique id to this entity, but is this possible for an cover which was created in configuration.yaml?
Any other idea?
Bildschirmfoto von 2020-04-13 09-04-36

thanks
Horst

You are not using autodiscovery. Simply add an unique_id to your configuration. Example :

  - platform: mqtt
    name: "mains total energy"
    state_topic: "sensor/totalenergy"    
    unique_id: "mains_energy_total"    

Won’t help you with your sensors it think.

Sorry, I didn’t mention it. I use the build in mqtt-broker. I think it is not possible to configure this mqtt-broker in configuration.yaml.
What I meanwhile found out is, it’s possible that the sensor state is not in default topic/state included:

11:43:52 MQT: tele/sonoff-garage-2/STATE = {“Time”:“2020-04-13T11:43:52”,“Uptime”:“0T02:05:34”,“UptimeSec”:7534,“Heap”:26,“SleepMode”:“Dynamic”,“Sleep”:50,“LoadAvg”:19,“MqttCount”:3,“POWER”:“OFF”,“Wifi”:{“AP”:1,“SSId”:“xxxxxxxxx”,“BSSId”:“xxxxxxxxxxxx”,“Channel”:11,“RSSI”:60,“Signal”:-70,“LinkCount”:1,“Downtime”:“0T00:00:06”}}
11:43:52 MQT: tele/sonoff-garage-2/HASS_STATE = {“Version”:“8.2.0(tasmota)”,“BuildDateTime”:“2020.03.20 14:54:51”,“Core”:“STAGE”,“SDK”:“2.2.2-dev(38a443e)”,“Module”:“Sonoff Basic”,“RestartReason”:“Software/System restart”,“Uptime”:“0T02:05:34”,“WiFi LinkCount”:1,“WiFi Downtime”:“0T00:00:06”,“MqttCount”:3,“BootCount”:33,“SaveCount”:71,“IPAddress”:“xxxxxxxxxxx”,“RSSI”:“60”,“LoadAvg”:19}
11:43:52 MQT: stat/sonoff-garage-2/RESULT = “Version”:“8.2.0(tasmota)”,“BuildDateTime”:“2020.03.20 14:54:51”,“Core”:“STAGE”,“SDK”:“2.2.2-dev(38a443e)”,“Module”:“Sonoff Basic”,“RestartReason”:“Software/System restart”,“Uptime”:“0T02:05:34”,“WiFi LinkCount”:1,“WiFi Downtime”:“0T00:00:06”,“MqttCount”:3,“BootCount”:33,“SaveCount”:71,“IPAddress”:“xxxxxxxxxx”,“RSSI”:“60”,“LoadAvg”:19}

hmmm… how can I get the GPIO 14 Sensor (Switch1) into the default state message?
Has maybe changed in Tasmota…

I was not talking about your broker, I was talking about your switches. If you defined your GPIO correct in tasmota, simply try to issue ‘SetOption19 1’ in the tasmota console.

Ok, but I used SetOption19 already an didn’t change it. Checked it, looks good.
I looked in release notes and maybe here is a hint for my problem.

  • For MQTT alarm_control_panel , MQTT binary_sensor and MQTT sensor set up through MQTT discovery: The undocumented implicit setting of state_topic is no longer supported. Instead, state_topic must be explicitly set.
  • Support for json_attributes is removed from MQTT sensor, json_attributes_topic should be used instead.

Is that the solution?

Adding unique_id to the sensor’s configuration will not fix this problem.

Failing to restore a sensor’s state, after a restart, is not dependent on the sensor having a unique_id. I have senors without a unique_id and their states are restored after a restart (version 0.108.0).

1 Like

@123 taras
thanks for replying. Yes, I can imagine this. I get an update of the sensors state if I open the reed-switch and close it by switching the relay.
But in an earlier version of hass.io I got an entity_id and the proper status after restart (hass). Now there is no auto-update (no retain message from sensor switch1).
I use template cover.

@123 , your are right,

Adding unique_id to the sensor’s configuration will not fix this problem.

Seems changes in release 0.108 caused the problem.
I solve it with docs in mqtt sensor interation.

In my case for eample:

sensor:
- platform: mqtt
  name: "test-garage"
  state_topic: "tele/sonoff-garage-1/SENSOR"
  value_template: "{{ value_json.Switch1 }}"
......

fixed the Problem. Now Switch1 sensor ist allwas up to date and gets updates immediately or via teleperiod.

Strange, because Setoption19 1 in tasmota sends a value_template for sensors. However, it is solved :slight_smile: