Ok I’ve only ever seen this referenced with Hubitat and now here… please explain what the “with Presence” is with these drivers? When I think “Presence” I’m fitting that into a background of geoFencing and location awareness.
It lets you know if the device is online or offline
1 Like
Oddest thing I’ve heard of recently. I suppose I find it odd because that’s a normal/standard feature in all of our drivers and not something “special”.
I figured that it was just me that struggled with this concept. We immediately jump to geofencing and Markus’ reasoning is the device is either present on the system or not. Thus presence was born in a new term for us. This WILL be a term that will be common for OLL going forward.
I hope I can keep all of these terms straight.
1 Like
Interesting. I’ll make a suggestion that you might want to stick with some common terms used within the CI (custom integrator) markets to make discussions and communications easier and adoption by the CI crowd more approachable.
As I work with and develop for a couple platforms each with differing terminology I often have to spend time explaining to the upstream vendor the new terms. Example I’m working with Nvent/Nuheat on an official RTI driver to market along with their Control4 driver. The CI platforms (Control4, RTI, Crestron, Savant, etc) use common terms for “drivers” which the upstream vendor (Nuheat) understands. When I was talking with them about the “NodeServer” for the Universal Devices Polisy platform they had no clue what a “NodeServer” was which is understandable… so I had to explain it was “like a driver” and then go into further explanations etc etc.
Each platform coming up with their own “terms” just makes it more difficult to talk about these platforms when a driver, app, plugin, nodeserver, component, integration, all mean the same/similar thing.
Again, personally I do not like the term “presence” outside of the field of location awareness or geoFencing or something having to do with actual presence of a person or object (vehicle, etc) as that’s the “common” understanding and thought about the term “presence” and the idea of a device being present aka “Online” or not or “Available” is again a common functionality that all “drivers” should manage about their devices.
Just my unwelcome two-cents. Back to finishing the touches on the NuHeat Signature driver for RTI and then back to Lutron NodeServers for Polisy 
1 Like
Really, it’s more a culture/regional thing. Not our own terms, per se, but how it’s referenced in other places will always be a challenge. To some “presence” is a correct term how it is used within that driver. BUT, I get it. I have a difficult time coping with these barriers.
I have the same beef with the entire metric/imperial system. Can’t we just throw in the towel, say the entire rest of the world is right, and just use flipping metric already? Lets not discuss the amount of double tool sets I have due to these “standards”. That’s not even mentioning the entire F/C conversion that makes my head spin! What do you mean 40 is hot!!
/rant
Why stop at just F/C conversion… ALL of them are a mess to deal with! I agree why can’t we just use what the rest of the world uses and be done with it.
Can’t we all… just get along!!!
–blam, blam, blam… blam…blam…
Just want to add something to this topic which I missed was even here. Presence in the drivers I and a few others have used was chosen because it was a capability that could be wrangled into fitting with this use case as well. Granted it is not a perfect choice in any way, but it was what made sense in order to have a tile to use in a Dashboard for example.
For the CC we will NOT use the word Presence. It’s device state, the exact wording and usage will be made clear soon enough. It’s a bit more nuanced than just online/offline, but it should be much less confusing than Presence 
7 Likes