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.
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)
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.
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âŚ
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.
