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.
1 Like
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 
1 Like
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
1 Like
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 ?
I tried that but unfortunately it didnt work 
Unfortunately, it appears the migration (as well as the zwave js integration) just isnāt ready for primetime. I went ahead and just manually renamed my devices after the migration, since it didnāt actually migrate anythingā¦
I basically just wrote down the node numbers and their associated names, then I did the migration, and I fixed the names after. It was a little bit of a hassle since it took me a few hours to rename everything and make sure Iād found it all properly, but itās done now.
The downside is that there are still A LOT of things missing from zwave jsā¦ so Iām not quite sure why theyāve marked the old zwave as ādeprecatedāā¦ it just makes it more confusing for users, and frustrating when things donāt work properly after a migration. My biggest issue with zwave js is that most of the UI configuration is completely missingā¦ so I have to manually set things via service calls, rather than just being able to handle device configuration changes via the UI like I used to be able toā¦ so Iād suggest waiting for that to be available before migrating. For the time being, I am staying on zwave js and just hoping the UI configuration gets implemented soon.
Edit: Apparently the UI config does exist, but only if you re-add devicesā¦ so the migration is totally worthless since I have to manually remove and re-add all my devices anyway. Iāve tried re-querying the devices and that does nothing.