@lpakula I have an interesting proposition to make OT for HE set apart (more) from any other presence detection system for automation.
Scenario:
I have OT as a presence sensor for Advanced Combiner and a virtual presence with 'switch' which I adopted from the presence template driver. The switch aspect allows local phone automation to turn on/off for conditions indicating the user/phone is attached to a vehicle.
Android: I use tasker to detect BT connection to vehicle audio system and turn on the virtual switch (Maker API) in the combined presence/switch device. This indicates to HE that the user is 'In Vehicle'.
iPhone: I use shortcuts (automation) to detect when CarPlay is connected and turn on the virtual switch (Maker API) in the combined presence/switch device. This indicates to HE that the user is 'In Vehicle'.
With both the presence and a switch mechanism WebCore automations are made to determine vehicle arrival based on when the 'In Vehicle' virtual switch is enabled. Then many garage and other automations are based upon that simple combination.
OT adaptation:
If OT driver for the user had a simple virtual switch that was selectable using the same API in the OT device then the above scenario would not need the virtual presence/switch device and most likely not the Advanced Combiner aspect either.
Higher level of adaptation:
Include OT phone app detection for BT and/or 'android auto/car play' to internally turn on the 'In Vehicle' switch or attribute which can be used in automations.
Ok that is super interesting. To clarify, you just reboot the Hubitat and this happens?
If the HE is rebooting, then the cloud endpoint will fail, and the OwnTracks app will spool up locations and then will eventually send them all home when it can. Is this an Android phone? On the status page it will tell you if there was an error reaching the cloud endpoint, with a number of backlog messages in the "endpoint queue".
To clarify, are you looking for each OwnTracks device to be a virtual switch? Super easy/quick to do if you are looking for something like "on=present", "off=not present".
Changing the app is more painful. The devs for that aren't overly receptive to random changes, and [insert drunken monk image again] is how my mobile development is on Android.
Not at all, the switch aspect is not tied to presence.
In my use case, I have a virtual presence with switch device for each family member. The presence is for arrival and departure (as it would be), the switch is for binary state of being in a vehicle or not. So, if a person's switch is on and they leave, the logic is that they left while driving their vehicle. If the person arrives with switch=on then that person arrived in a vehicle. All sorts of automations can be done when arrival/departure is associated with if they are/are not in a vehicle.
I currently use tasker for android and shortcuts for Iphone to turn on/off the switch when either a Bluetooth, Carplay, or Android Auto connection is established/disconnected by the persons phone. So, for me, when I drive I have my phone set to auto connect to the car's BT. When it does, tasker does HTTP GET to Maker API (cloud link) to turn on the switch. Therefore, that device driver has both presence and vehicle use attributes.
It would be awesome if the OT device at the least had the same binary state (virtual switch or attribute) that could be addressed via it's already connected cloud based API which is used to connect hubitat to the mobile device. Then, I would not need the Maker API link on a phone that already has basically the same mechanism within OwnTracks. The more advanced would be the invoking the OT app with the ability to detect BT/carplay/android auto connections. What I gathered from your reply as a 'hard sell' for either android or iphone versions.
Yes, I simply rebooted the hubitat but the actual device 'travel' wasn't during the reboot, it was a few hours earlier in the day. What you outlined is still likely what happened - device was unable to reach the cloud endpoint, but the hub reboot is what (I guess) restored the cloud endpoint. This is with Android devices so the next time location stops working I'll be sure to check the Status page on the app. Currently showing 0 messages in the queue.
Now my problem is to understand why my hub has seemingly lost connectivity to the cloud a few times even though the Internet access has remained up. Even if there's an outage I'd hope the hub would periodically check and re-establish the cloud connection. Not an OwnTracks problem!
That's an issue with their cloud provider. I've seen errors in my OwnTracks logs that it couldn't connect to the cloud endpoint. No idea why, but works 99.9% the rest of the time, so I'm ok with it.
I see it's tagged in their GitHub project, and there is support tickets open for issues. There is a couple blockers for me right now:
Image cards aren't being linked to friends in the app.
Big one: Seems that when you leave a region, the transition message gets blocked and rescheduled until you stop moving. The app shows me leaving from home, and arriving at work at the proper times, but the HE app gets both events once I stop moving at work.
Thank you! Suprisingly, one of the android devices that wasn't reporting, just did all it's reporting and is staying current.
Anxiously awaiting the iOS fixes. I only have one device using it, and I'm really looking forward to it getting all the appropriate settings and regions.
I'll get that properly addressed. I missed the the changes in the last version broken how the HE could see home and other regions. I'll get that corrected in the next release.
Not sure if anyone else can confirm, but have .48 break the android and "fix" iOS, then going to .49 to fix the android, now both are reporting properly and the iOS got the regions when it checked in.
