Yes, the “person” integration. A core HA one. You can use it completely from the UI. https://www.home-assistant.io/integrations/person/
The person integration would be fine if simply triggering a few automations off of it, but from a security standpoint it’s flawed. For me, when I arrive home it opens my garage door, unlocks the doors, disarms the alarm, turns on lights based on time of day and adjusts the temperature inside. When I leave it does the opposite.
Using the last updated tracker to determine home can easily lead to a false arrival which would leave the house vulnerable. Also the fact that stationary trackers have priority and some WiFi trackers can hold on to the “home” status for as long as a half hour could seriously impact the departure time.
The bayesian sensor does apply some threshold logic using math that I just don’t understand which is making it a challenge to really “tune” to my liking.
That absolutely what I believe, but it relates more to (I think) poor architecture. They’re probably right in that their hardware SHOULD have enough power.
For me, there’s not enough value in a presence driven auto-unlock to make it worth the risk. My automations with regard to locks are only lock, never unlock.
1 Like
Same here. Just the fact that I dont have to fish keys out of my pocket and only need a unlock code is good enough for me. Anything related to securing my house is set to autosecure only.
1 Like
Have you tried it? Because I find person more reliable. But it all depends on the trackers you give it. I use HA app geo, life360, unifi, BLE keyfobs. That combination is solid for my use case.
An excellent description and tooling. Took me a day to get my mind around it all.
1 Like
One little word of caution for running two Maker API’s like I did. It kept creating duplicate entities whenever I restarted HA for some reason. The second one was unavailable and called entity_2. The major problem was sometimes the unavailable entity would be the one without the _2 so that device would stop working.
Problem solved I think since the Maker API instance is removed as I’m switched over.
Hmmm… I’m assuming you didn’t have devices with the same names coming from each Maker API instance? (Like, something called “Bedroom Light” in both.)
Yes, the same devices were going to both instances.
So to be clear just the maker token, etc needs to be changed but the custom component instance created remains the same (hubitat) or changed to something else or somewhere else? Sorry for the noob question but I’m a HS guy who has been using HT for a long time now just grabbing data and pushing it into HS with their plugin. I currently run three HT hubs (large area to cover, replaced ZNets) and they are faster that the ZNets were and besides I have Zigbee now as well with them. I do use the HT for some Zone control but nothing else. I have been playing with HA with this down time and I’m thinking about going that way (tired of the HS BS). If I can pull over my devices with HA then I’ll just need to create events, no problem. I could also just turn events off in HS and mirror HA and if an issue with HA flip back. I’ve already pulled all my other devices over to HA and they are both running fine. I’m running HA an a Windows 10 VM without issues.
Thanks in advance
Thank you @jason0x43 for the great work. I’m new here. Noticed Hubitat entities intermittently get duplicated after reboot where old ones become unavailable. Is this a known issue? Appreciate your help
I have seen a couple reports of that. What version of the integration are you running? If you’re on v0.5.x, were you running 0.4.x before that?
Ah. Then the devices should have ended up with unique internal IDs, but their entity IDs would be the same. Like, both instances of the integration would want to create a light.bedroom_light.
You would install multiple instances of the Hubitat integration, one for each hub. In general, you shouldn’t notice that you’re using multiple hubs when writing automations or dealing with HA state events since those are tied to HA entities.
Hmm… there are some corner cases with hubitat_events, but those probably won’t be a problem. I should fix that, though… 
So the multiple instance is put in the custom component instance (hubitat) you would create a custom component instance (hubitat2)? I realize the maker needs to be set up on the additional hub with that token. Or in the Hubitat (Hubitat options) in HA just put in the new IP address. If so where to add the id and token. I see you can change the address and port.
It was only installed 1-2 days ago. Fresh install 0.52 via HACS on raspberry pi. Never updated yet!!
Thanks for the hard work to put this together. Currently just started messing with HA coming from HE. I do have one question as it regards to Fan control. I have multiple GE Fan in wall controllers and they do show up as a device but don’t have any speed control. Is this the case?
I have maker pulling them over into HS and they show up as a light and control like dimmer.
In HA you would add a new Hubitat integration for each instance of the Maker API you want to connect to, whether those are coming from a single Hubitat or multiple Hubitats. Basically, repeat the process you first used to add the Hubitat integration for each Maker API instance you want to connect to. Each instance of the Maker API should have its own ID and access token.
The next time the problem happens (duplicate entities are added and old ones become disabled), could you take a look at HA’s entity registry? The entity registry is in config/.storage/core.entity_registry. Open that file and find the entries for the old device and the new duplicate device and paste them in this GitHub issue (and if it’s OK with you, I’d like to continue diagnosing this on GitHub – it’s a bit easier to follow). I’m hoping that seeing the difference between the original entity and the duplicate will give me some idea about what’s going on.
1 Like