Who wants altitude too?! For high rises?
I’ll take altitude, can always use it at work
Hopefully this doesn’t stall the awesomness! From what I remember between Android/iOS different apps had different issues. The ST app was the worst at being closed and still reporting. Life360 seems to do a good job. BUT I’m sure as with those apps they will need to be set manually to NOT shutdown. Battery optimization = “Not Optimized” for Android and I forget what’s it’s called in iOS.
Even the thought of something working as described above is simply awesome!
Thought there might be some good stuff in this to aid in the app creation.
Sounds delightful! Would love to get on as a beta tester like whoever else suggested it above ^^
What do you think your rollout timeline is?
This would be awesome! This might honestly fix all my presence issues and bolster my automation needs. However I can help let me know!
So, ran into a bit of design issue. Here are the facts that I need to deal with:
- a user can have multiple instances installed into a location
- a user can have multiple locations (multiple hubs)
- a user can define multiple - let’s call them - places
- a user can have multiple phones
The main issue is the synchronization of all these things. I will need to complete the signup and login process because I need to store the linking information between all of the above. In the process I am considering this:
- register a browser, then while in the dashboard, you get the option to login or register. At this point, one can register multiple times (for various, shady reasons?) - can multiple user accounts share an instance? Should they?
- Should all other instances belonging to the same account as the registered instance automatically be populated once a user is created?
- Should places be common to the whole account, the whole location, or independent from instance to instance? I’d make them account-global, so that creating a place automatically spreads that place to all presence devices managed by webCoRE for that account (so all locations, all instances)
- another problem is handling devices - only one instance in a location should handle devices, two instances would fight over creating devices with the same name. This is one of the biggest issues I have - an instance has to take ownership of the device and it is also responsible for managing presence and all updates to said devices.
I think that’s an unnecessary complication… there should be one admin user for the dashboard, that admin can assign guest users for visors and the app.
I don’t think there will be “guest users” - I’d rather make the visors work with invitation codes - that can expire too and provide a) view access b) control access c) control access with a password, etc. So you’ll be able to create n visors and m codes - then a matrix between the two determines what each code can see/control
Presence is a bit more complicated since I set the bar high: multi-location - so we’re not dealing with two circles, we’re dealing with many. I am thinking so far at a way to setup “places” independent of devices (phones). That’s because most locations are common to several people in the house. So you’d create home with location and radius (I’ll default that to 100ft) and I’ll also add another circle automatically that’s 500ft on top of that. Then one of the locations is “HOME” - the one where the hub is - not sure if I can pick up the hub’s location, but I think it’s better if you set it up in the same place as the others. But one place is the main one and will determine the value of “presence”. Presence is set to ‘present’ when you enter the small circle and set to ‘not present’ when you exit the larger circle. Then, the DTH will provide:
- presence = present/not present (main place only)
- arrivingAt = placeName/empty (set to the name of the place that the user is approaching - when the user enters the larger circle, until he enters the smaller circle)
- leavingFrom = placeName/empty (set to the name of the place that the user is departing - when the user exits the smaller circle until the user exits the larger circle)
- distance = calculated distance from HOME (main place)
- presentAt = name of the place the user is at - this is set to a place name when the user enters the smaller circle and set to empty when the user exits the larger circle
- closestPlace = name of the place closest to the current user location
- altitude = current latitude of the user - this will be an option - you can enable it or not
- longitude = current longitude of the user - this will be an option - you can enable it or not
- altitude = current altitude of the user - this will be an option - you can enable it or not
- floor = current floor of the user, IF KNOWN - this will be an option - you can enable it or not
also thinking of either some departing / approaching attributes that use a custom set radius (say 3 miles), or a way to use distanceTo and somehow provide which place. Still figuring things out.
Note that some features may not work with some devices - iOS allows subscriptions to “significant location changes” which means that the app can track the user and the Presence sensor can therefore provide an approximate location of the user. The location is “approximate” because iOS only reports location once in a while as to conserve battery power. This works even if the app is terminated, which is awesome. Also, owing to privacy, this feature will be optional (user needs to enable it on a device basis) and I do not know if that option exists for Android - I’ll find out when I get there.
I am currently figuring out ways to do user registration / login. Once that’s done, a user can then set up to 10 places - each place has a set of coordinates and a radius (will default to 100ft/30m). Places are common to all locations and instances in the account. Then, when the user opens the dashboard in the mobile app, he can register that device as a presence sensor - then the user chooses a name associated to that device for each of the locations he has (and if a location has multiple instances, he’ll need to choose which instance to use) - at that point, he’s set. Presence sensors will be created for each hub(location) and the instance that owns the devices should be able to automatically select them (no need to visit the Available devices).
That’s the plan, at least.
Jeezzzzz… You’ve set the bar high there… sounds awesome!!!
Food for inspirational workflow… @ady624
this going to be so cool, its almost like magic!
looks like individual users would need to handle part of the setup by going to the dashboard? if yes, maybe have an option so instance admins could handle the setup without individual user action? the admin could change the DTH for phones on the account to the webcore DTH and everything works from there the same? the DTH could even have configurable options if those are needed, configured either thru the IDE or on the phone.
Drooling a bit as I read this thread. I would love to see the app bundled with a handful of push notification sounds that could be selected in webCoRE. That would greatly reduce the lengths to which I go to get different sounds for notifications of different urgency. At least on iOS you can just name the sound file in the push payload.
Looks like there’s an alternative for that in paid app Pushover which I may try.
If sounds are too easy for you then also look into notification acknowledgment to allow a piston to know when you have interacted with the notification and which [configurable] button was tapped.
Noob question here. Does that mean we will be able to see the tiles generated from one piston on a dedicated dynamic page?
I mean, the equivalent of https://dashboard.webcore.co/piston/:$pistonID: but showing only the tiles rather than piston edition page.
Not currently looking into push notifications, but yeah, definitely something to add later. For now, it’s going to be a web wrapper with an underlying location monitoring system that reports directly to ST (no middle man on presence/device current location)
visors will allow for either device tiles, routine tiles, piston tiles, shm, clock, etc. Kind of what SmartTiles and ActionTiles do, but tightly integrated into webCoRE.
A very very pre-alpha look at the visor editor https://dev.webcore.co/visors
Oh, I get what you mean now. It’s incredibly promising.
Are we going to be allowed to create more than one visor per instance (like, let’s say, one visor for every users allowed to the instance)?