I finally had a chance to look at that issue where you’re failing to load other sensors again, after working closely with Paulus to make sure this component still works upon next release- and I may have a lead to follow. I noticed that the problem really only occurs if you have an open browser with live updates on. I found that if a different browser tab was active- that I never saw the issue.
It almost makes me think perhaps we’re trying to get the state of the sensor too early, prior to initialization finishing. But anyway, can you also test out my theory? So next time a sensor disappears on you, try restarting hass without any active web browsers and see if that’s reliable.
I’ve tested this a few times since you posted and can’t seem to replicate the same behavior in my setup. No matter what I do (open browser tab/window or closed) it seems to be random in terms of if the binary sensors will load with envisalink enabled. I do also use hadashboard and appdaemon in my setup, both of which use the api. Maybe that’s why closing the browser sessions has no effect?
By the way, thanks for putting in the work to update the plugin to work with all the new asyncio changes in hass.
Ahh yes that could be the issue- my theory is that something is requesting status too soon- so if you don’t mind- can you please try and turn off any services that use the API + any browsers, and see if your sensors come back consistently when you start HA?
I learned quite a bit about how the components are initialized when retrofitting this component to work with the new way of doing things, and basically how it works is- HA spawns off a seperate thread, and within that thread, all of the components are setup serially/synchronously. So it is possible for normal events to be firing even though setup hasn’t even completed yet.
By the way, I thought I’d also mention to the greater audience here that I did discover why people’s “keypad sensors” were not showing useful information- I have been working with privatesam on the side on that one. If anyone else would like to help test the fix, I’d be willing to put it into an official branch- just let me know. I think we missed 0.29- but perhaps 0.30 we can get that in there.
Not quite- no. Since the panic branch has been merged into the main dev branch, it’s essentially dead. I’ll be looking to get the most recent fix in a new branch and immediately do a pull request to get it in dev.
Okay- I have another pull request out there to get this latest fix in. We’ll see if it makes it in 0.29, or if we have to wait for 0.30.
Ih8gates- if you’d like to try out the fix, please do the following:
To find the file to be replaced on your local machine, just go to / and run:
cd /
find . -name envisalink.py
This should come back with a list of files named “envisalink”. You’ll notice that one of them is in a folder called “sensor”. This is the one you wish to replace. So do:
cd /path/to/sensor
mv envisalink.py envisalink_backup.py
I might write out a little post with my config and alarm in action to demo how cool this is. I think this is such an important component because it essentially means you can re-use all your alarm sensors as part of other automations. Knowing the state of my living room motion sensor means I can automate lights etc without having to buy another z-wave or other motion detector.
Just checked the behavior this morning with all browser tabs closed and no external services accessing the api and I still am not able to get consistent behavior. I went through about 10 restarts and everything loaded correctly about 25% of the time. The other times it was either just the binary sensors failing or all the mqtt sensors failing to load.
Just to make sure something else wasn’t causing the issue I disabled the envisalink component and repeated the 10 restarts. All sensors loaded completely every time without issue.
I’d be happy to test any ideas you have in correcting things since the problem seems easily producible on my setup.
Thanks, @Cinntax. I’m using the All-in-on installation, so I had to deal with permissions first. To future viewers of this thread:
sudo su -s /bin/bash hass
will switch you to the hass user that owns the files.
Unfortunately, though, I’m not seeing a change to states.sensor.home_alarm_keypad.attributes.exit_delay.
I watched the UI panel that shows the keypad states and I also checked the variable via the template dev tool just to make sure it wasn’t an issue with the UI not responding.
This update also made all of my Forcast.IO sensors disappear, like @mezz64 is seeing.
Dang- yeah i’m out of ideas for now. It’s just so random. I did learn quite a bit about the setup process while accounting for the asyncio changes, so I’ll take another look.
I have a pretty good idea of what’s going on. It’s how I’m loading the sensors- however I’m not the only component Doing it this way (Ecobee/Vera do it this way too). So I may have to consult with Paulus on how he wants a resolution to look like.
Since the Envisalink will only allow one TPI subscriber, I have only been using it a bit as I port from my Vera setup. So, I’m wondering, @Cinntax, does the HA implementation of Envisalink report the user number of the last person to disarm it? I’m using that in Vera to let me know when my kids get home from school while I’m not there. Thanks!
Okay- with Paulus’ help- we finally got to the bottom of this issue- I’ll be doing a pull request to fix it later tonight. If you want to test it too- i have it checked in here:
The issue was pretty minute- so I’m glad Paulus came in with the assist!