This doesn’t even make any sense… Not doubting you and others have reported this as well… but why?
Yeah I’m not sure why.
I tried updating HassOS -> v2.11, and the addon it self to the latest version. That didn’t seem to help unless the broker restart after updating those two did the trick. 
Thanks 123. I will try your solution
I hesitated for a week before updating from 0.89.0 to 0.90.1
Had to do nothing at all after that.
However, our configs may be different - I use internal database engine and Mosquitto add-on.
Even managed to disable its allegedly insecure 1883 port (just for fun)
and Vista!
Thanks for your answer, I waited for something like that for so long…
What exactly does that mean? I’m still confused…
Does an entity HAVE to change its state every time something is posted to a topic it subscribed to?
I think it’s something to do with HA/mqtt implementation’s guts as I had no idea it should return anything 8()
And many of my sensors don’t use value_template at all…
To clarify, I presume that many people have issues with that warning because their use case includes ONE topic for ALL their devices so they all listen to that topic but have different payload_on and payload_off values, like this
- platform: mqtt
name: "safe"
state_topic: !secret rf_bridge__topic
device_class: door
payload_on: !secret door__safe__open__code
payload_off: !secret door__safe__closed__code
Anyway, I’ll try to digest your examples and we can carry on there if you don’t mind 
UPDATE: I think I get your point - here is my thoughts.
FINALLY…
In few days my log file exceeded 2Gbyte!! and I just have
logger:
default: errorThe recorder: will be recording every state change of every device/component
I was referring to home-assistant.log file (BTW also my home-assistant_v2.db is 2Gb but for that I know its because I have many components)
I agree, I used “LTS” just as a generic example of a version which is considered to be working very well before jumping into one that includes a major new feature, which usually comes with quite a few initial issues.
1 Like
And Windows ME
Exactly.
The payload_on and payload_off options are designed to match the payload from the sensor’s unique topic. However, in the case where a single topic is used by multiple sensors, the payload may be intended for one sensor but not others. As a result, the “others” receive a payload that fails to match their payload_on and payload_off.
The simplest solution is to create a value_template that, when it receives a payload that isn’t intended for it, simply reports it’s current state.
FWIW, my preferred solution is to demultiplex the single topic using an automation (or a Node-red flow). The demultiplexer creates one unique topic per sensor thereby simplifying the configuration of each sensor (i.e. value_template is no longer required for each sensor).
Others mentioned ME and 8, but how dare you forget Microsoft Bob?!
That was well worth forgetting!
1 Like
The upnp errors? They were in the Home Assistant log file, when I checked from a terminal session. After disabling the component and restart, Remote UI has been rock solid.
Is this new realease providing streaming from HA to Homekit? Are we able to shutdown our homebridge that we keep running just because of this feature?
Thank you for the info in advance.
Is there maybe a plan to give each component a unique numeric ID , so renaming the component wouldn’t necessarily be a breaking change? Would work great with a UI for adding/managing components
Anyone else have their zwave blow up going from .89 to .90? Devices go unavaliable and timeouts. Reverting everything back to .89 resolves.
My few zwave devices seem OK, though they are accessed via a Vera Edge box.
No issues here on Z wave. ZHA has been a bit of a pain, but its getting some needed upgrades and the quirks are getting worked out.