Hi,
Just as a small FYI: This is a screenshot of why I thought my device reports to supports S0 and S2
The Dutch parts translate to:
S0 Legacy:
Example: Older door locks without S2-support
S2 Non-verified
Like S2 Authenticated, but without verification that the correct device has been added
Youāre correct in that case, I mistook the meaning, sorry. Thanks for the clarification. HA wonāt know before adding whether the device supports either, itās discovered during the inclusion process.
When you select multiple security classes, the highest security class should be used. In your case, S2 Unauthenticated should be preferred over S0. Did you happen to confirm via the dump? Another way to check is by enabling debug driver logs, and if the messages are S2 encapsulated, itās using S2.
The S2 Security for z-wave is not working. got brand new Aeotec 700 usb and also Aeotec power plug 700 but I have tried serval times connect with s2 but always end up normal inclusion, when you have to enter pass code it just freeze after code and end up with normal incl. . so I donāt want to test all my other devices before it is fixed.
No worries of course. 
And yes. I verified with the dump and the devices (radiator valves) give a 0. So it has the s2 level active. I havenāt taken the time to do all the devices of the same type, and the ones that I havenāt done have a value of 7. (So s0)
Thanks again for the info
Same happened here. I commented out the device_class a while back.
Are you using platform: history_stats ?
Iām still getting all these warnings : (opened up an issue ages ago in git but hasnāt been looked at)
Logger: homeassistant.components.history
Source: helpers/deprecation.py:123
Integration: History (documentation, issues)
First occurred: 09:43:48 (2 occurrences)
Last logged: 09:43:48
get_state was called from history_stats, this is a deprecated function. Use homeassistant.components.recorder.history.get_state instead, please report this to the maintainer of history_stats
state_changes_during_period was called from history_stats, this is a deprecated function. Use homeassistant.components.recorder.history.state_changes_during_period instead, please report this to the maintainer of history_stats
Is there any way we can get an option to manually reload TP Link devices that drop connection without having to restart the entire system? The new integration supposedly keeps them from dropping (or more accurately supposedly eventually reloads them hen they do) but I have a few that routinely drop connection and if they happen to be on an automation that turns them on at a certain time and theyāre offline at that time, then I 'd like to reload them immediately. I can only do that now by restarting HA.
Just noticed - my battery sensors now have static icon:
It used to be mdi-battery-90, mdi-battery-50 etc.
Described it here.
You can reload an integration from the integrations page, which will reload all the devices/entities for that integration. You can also call the reload config entry service with the device ID from the developer tools. Thereās more info somewhere on the forum on this (canāt find it now). The former is probably the easiest.
The integration reload is no longer available. Digging a little deeper (perhaps after a Core update this am) the individual devices now seem to be reloadable.
Thanks! I managed to fix it for a couple of weeks, but now it has broken again, although everything is configured properly and it did work. Now suddenly doesnāt š¤¦. āOfficialā somehow doesnāt instil confidence with Tuya anymoreā¦
There s a fix on the way, it was already raised 
Yes, and it was you who registered the issue the 1st time, thank you)
Have you had any success with this and the trackr tags? Iām stuck trying to get a sensor to detect them.
@beacher, sorry for the late reply. Unfortunately I havenāt had any time yet to deal with the trackr / EspHome solution.
But Iāve just found this:
There are a pair of comments with this:
Our local dollar store was selling these TrackR things for cheap so I picked up to try. Iāve paired them though. If I reset then, will they go back to being BLE beacons? This would be a much better use than what Iām currently doing with them.
Yes! Simply unpair them from the app. My recommendation is this:
Flash one of the ESP-32s with ESPhome. Then, check the ESPhome logs. Itāll scan every 30 seconds and tell you what devices it detects.
Youāll find that as soon as you unpair from the Trackr app, it starts showing up on the list!
Thanks! I actually came across that last night and did get them working, ESPHOME was showing the MAC addresses as ārandomā which you canāt use, but so far they have maintained the same MAC address, so itās worked well to get the RSSI and status of the tags.
Only thing I havenāt figured out is writing a characteristic to have them beep, but I donāt believe thatās supported in ESPHOME yet.
Did you ever find an answer? I am seeing the same thing, I ran thru a migration, nothing migrated, so I reverted to a backup
My MQTT Cover stopped working, no errors in the logs and I canāt see to find anything on the internet. Did something change?
What hardware / software is outputting the MQTT ?