Or even wifi based localisation… on some cruise ships, they can know where you are on the ship to deliver orders by an app… it’s only a matter of time before we can know that a person is in a specific room.
Sure, but is there a legitimate use case for the former? They're generally considered a nuisance or false positives with existing sensors (and one of the reasons PIR is probably the most common options among other possibilities). No matter what you call it, I'm wondering what difference there needs to be in the hub for an app. Eliminate these nusiances and you basically have a motion sensor that works the way people always wanted them to before the technology caught up, IMHO. 
2 Likes
So you are saying that it is motion that is a misnomer. 
The thing is that motion is what current sensors detect, and that’s the wrong way to detect occupancy. You could be completely still, not even breathing, and an infrared camera could still know you’re there. Using motion to infer person is both too sensitive (leading to false positives) and not sensitive enough (leading to false negatives).
So when (not if), those detectors happen, they may not even be based on motion. And we would represent them as « motion » for historical reason. Completely confusing.
As for if there are use cases for motion, sure.. if I want to know if a car approaches, or passes. Probably would be based on cameras rather than infrared too.
1 Like
Can I tease you about being stubborn not accepting occupancy as a thing that can be treated differently than motion?
Keep the heat on while the room is occupied. Turn it off when it hasn't been occupied for 20 minutes.
How many rooms are occupied?
The water is running. Is the house occupied?
I'm about to set the alarm is anyone in the house.
Yes, it takes sensors, activity or cameras to determine the state, but occupancy persists when bulk motion doesn't.
Maybe you use a phone for occupancy. The person is dead. Occupied?
2 Likes
Thanks for the examples! Those are interesting. I do still wonder why the the inputs you choose in an app couldn't still be "motion" sensors and you only choose the ones you know mean what you're really looking for (in the same way you currently have to have some idea of how your sensors behave in terms of sensitivity, timeout, field of view, etc.), and I still think buy-in for a totally new capability would be an uphill battle (thinking in particular of apps that look for traditional motion sensors now but could work just as well with any of these). But I'm getting a better sense of the use cases!
And I certainly understand that you can, as some have, take my train of thought to the extreme of why there are separate things like contact, motion, or really any binary state like locked/unlocked at all (but to ruin the fun, the historical answer is something vaguely related to choices Zigbee made when determining clusters -- a strong influence on the ST capability model -- and the fact that Hubitat started with this as a base, likely to ease compatibility and transitions for early adopters in particular ... and presumably the fact that some division and abstraction into human-friendly ideas makes things more user-friendly). The best approach is probably somewhere in the middle, and I think that's where we are now, just trying to figure out exactly where. Thanks for the discussion!
7 Likes
Happy to add my poorly researched 2c.... 
I will acknowledge motion vs occupancy is largely a semantic discussion, like I think @bertabcd1234 mentioned... I am partial to making a distinction between them, if only for how rules may be interpreted by those entering the home automation space. Additionally, I think there can be some benefit to a degree of parity with other home automation systems, if in fact they have adopted this distinction, if only for ease of migration for users from other platforms. Not a strong case, I will grant you, but something I think worth throwing in the mix.
I could understand if some people see motion and occupancy as different concepts and want to automate their home differently based on motion and occupancy events / status. People may want to trigger rules based on motion becoming active on a collection of sensors in a room (e.g. a Zone Motion setup), but maintain the state of devices such as lights based on the perceived occupancy of a room, which could be based on a combination of active motion, interaction with or the state of A/V equipment (watching TV via Harmony Activity), the state of a virtual switch, etc.
I think some of the discussion so far has (understandably) focused on the mmWave example that was floated in the OP. Personally I feel that the justification for the introduction of an occupancy capability is broader than just handling that device type. While I feel there are some physical devices that could benefit from a more semantically accurate phrasing of their status. occupancy also allows for device types that cater for representing an aggregated status for areas such as a room, which motion does not, IMO, adequately represent.
Sadly wise words that could be applied to so many topics in recent years...
2 Likes
Would add that I wonder if the inclusion of PIR and mmWave sensors in some of the newer devices may result in the need to distinguish between motion and occupancy? Apologies if I am repeating something already mentioned...
2 Likes
Why would any app need to be updated, other than perhaps the Mirror app? Not to mention that plenty of device drivers expose more than one capability to work around this "adoption" issue. For example, some vibration sensor drivers expose motion in addition to acceleration (or shock).
Notwithstanding the fact that arguing occupancy is the same as or similar to motion is a stretch (IMO), mapping anything "similar" to motion to one motion capability just makes it more difficult to understand (or remember) intent. Even if the semantics of occupancy aren't perfectly defined or agreed upon, it is a useful concept to add to the automation vocabulary.
When there is no appropriate capability (for particulate matter or radon, for example), one has to fall back on custom attributes / commands (usually via the dummy "Actuator" or "Sensor" capabilities so the device shows up in drop-downs). Shoehorning features into "closest" capabilities we end up with thermostat drivers exposing Lock and those devices being offered in HSM custom monitoring rules (as just one of many such examples).
I wish the architecture leveraged capabilities as (ref-counted) interfaces instead of mostly (exclusively?) as filters for app config UIs. When forced to resort to linking to custom attributes or commands, swapping devices almost guarantees breaking those automations (child devices are another broken concept in this respect...).
My other home control platforms have nested spaces. Perhaps occupancy is a state and functionality of the space context.
- Site or property
*space or structure
**floor
***room
****room space
The maybe you can logically group rooms, floors and structures like "kids wing", "guest suite", "compound", "pool area"...
Occupancy or presence is inherited based on rules. Perhaps you have default inheritance and option for custom inheritance that is separate attributes so you have the ability to compare in rules.
Yes, Yes and Yes. Lost of devices like PIR sensors or MMwave sensors can generate the events. Cameras can also generate the 'names' of the persons in a room. Who is in a room is also a state, not an event.
All of the comments opposing this proposal are trying to equate motion and presence. Or that presence is the result of a rule.
mmWave sensors create the occupancy state directly. Some mmWave sensors create both the occupancy state and motion events in the same device. Those use multiple sensors.
Just ask @kkossev, he has written drivers to bring Apollo Automation devices intended for HA to HE.
HA is not trying to force fit presence sensors into the motion category.
Also, apps would only need to be updated if the author wants to use presence.
2 Likes
Wow allot of discussion. So here are my two cents. Allot of the arguments around this seem to all be semantic and is very blurred based on perspective. I think there is no doubt Motion is different than Presence and Occupancy, but motion is one of a few ways to determine occupancy. With AI we can use video to determine occupancy by analyzing the video stream and looking for things. That can give you the advanced features some are looking for like determine if a human is present in the area viewed. It may even go further as AI is trained on people or other animals that may appear.
A mmWave based sensor is basically a more advanced Motion Sensor that has ways to analyze a expected view vs current, I believe. I am not completely clear on how it works as I only have tested the Govee Presence Sensor. My understanding at least from that sensor is that it understands how its view should look and then it basically is looking for differences with every scan of the room. It can use both PIR and mmWave, and when these sensor technologies identify something isn't the false state, it says the room has presence.
Weather you think of Prescence or Occupancy as the same thing is very much just a perspective thing. Trying to pigeon hole occupancy into something that is different is probably a bad direction and would cause confusion.
Presence as a concept doesn't need to be related to Geofencing. That link was made largely due to a lack of other options, but presence could mean a general location, a Room , something was returned to it's right spot, ect. Occupancy in many cases will overlap with those same asks.
If anything I would say that the concept of rooms or locations should updated perhaps to have a attribute of Occupancy. It makes more sense lets say my office to have a attribute of Occupied, and then my Govee Sensor to say it detects presence. Then we would need a app that allows us to assign devices to trigger that attribute to be updated based on sensors that detect presense/Motion/ect.
To that end I wouldn't think adding a new capability that is so similar wouldn't really help. If anything it will make it potentially confusing for driver and app developers to write their code. At best it would increase requests to modify code because of stuff like:
Hey Developer, Your app doesn't detect my x sensor, and you update your code to work with it.
If anything I would love to see enhanced usage to rooms around this. If I remember a long while ago there was a room manager app that tried to do just this, Having something built it could be a game changer.
That Room Manager app is below:
Custom Apps and Drivers / Custom Apps - Hubitat
1 Like
Sorry, but I don't see how it is a perspective thing.
We get too easily confused by words (occupancy sensors marketed as human presence, for instance):
- Motion is motion - some thing is moving (modulo a timeout / cooldown delay)
- Presence is identified (a specific device reported it is "here")
- Occupancy is anonymous (a person is sensed "here", moving or not).
I don't think the discussion is about how "here" is defined (but that is an interesting discussion).
Part of the discussion is about whether these distinctions are meaningful and might change how automations are built, thus justifying a new capability.
My opinion is that they are and they will, and therefore the new capability is justified.
However I am not holding my breath, I am already using virtual (contact or switch) devices to represent occupancy. It's an ugly workaround that degrades the user experience but it works.
6 Likes
One more thing (sorry @mavrrick58 I don't mean to pick on your take specifically)
If one accepts that motion, presence and occupancy are different concepts, this becomes a red herring. There is nothing that says a device cannot expose more than one of these capabilities (or all three). For example, a camera that can do face recognition / tracking would likely expose all three as it could detect motion, detect an unknown person (for occupancy) and possibly identify that person (for presence).
IMO the confusion goes in the other direction, due to potential shoehorning of fundamentally different concepts into "motion" or "presence". Ambiguous use of a capability will confuse not only users but the new AI rule builder, too.
To avoid this, developers have to resort to custom attributes, which creates a new problem. To give a concrete example, I am currently experimenting with a Moes mmWave device. The community driver (appropriately) exposes motion as a capability, but it also exposes a distance to the detected object (no capability) and an "existance time" (sic) which works a lot like occupancy (no corresponding capability).
I argue that the "existance time" attribute being custom makes it unusable (directly) in automation apps. Why? Because if you change your mind and decide to use a different device that happens to expose the occupancy concept differently / with a different custom attribute, you end up breaking any automations that link to that custom attribute. Swapping the device won't work. You have to go down the road of opening the "In Use By" device details pane and chase down every app one by one and fix them. Such a pain.
What I do instead is mirror the custom attribute into a standard one (like contact) on a virtual device that then gets used in apps. I avoid a potential hardship down the road in exchange for tolerating the semantic ambiguity now. YMMV.
1 Like
This conversation reminds me of, "It depends on whose ox is being gored." I see motion and presence as a function of what a device can sense. Motion can trigger a device, presence can keep it alive without motion. Occupancy is related to a broader location. I'm present in a room so the lights stay on. Someone is somewhere in the house so it is occupied.
Those two concepts could easily be reversed. I wonder if how they are interpreted could also vary by language.
1 Like
There have been many discussion on this in other threads. It's a smoothing method. You have a light triggered by a motion sensor in a room. You move in and out of the room every 2 minutes because you are moving things between room or the like. You can smooth the off trigger by extending the time so that the room light stays on longer than motion. You use this so you don't have to create rules to do the same thing.
mmWave sensors in principle can track static targets (presumably motion is necessary to first identify a target). Are you saying they don’t? None of them do?
The ES1 for instance has distinct sensitivity settings for motion and static detection (the latter may be achieved through micro-motion detection, I don’t know, doesn’t really matter). But I cannot recover the existence signal simply by smoothing the motion signal.
Honestly, I think you missed what i was trying to say.
I agree above with what you said above for Motion and Presence. My point though is that Occupancy is more about a area and not about a specific device. Occupancy should be about a space or room and it would really be better if instaed of trying to pin this to a capability in a device, this became something that was monitored and designated in a room or space. Basically an enhancement to how rooms work.
Think of this example. I have a designated my dog's dog house as a space. I get a presure pad that is installed that i want to use to turn on a small heating pad for him when it is cold and a Light when he first goes in. If i have a space called dog house i want it to be occupied when the presure pad is triggered. That will allow me to trigger rules for the Light and heater based on other sensors. Occupied is a attribute of the dog house area and the trigger for that state is simply the presure pad. in that case Neither a Camera, Motion, or mmWave sensor is needed.
The point is that Occupancy probably works best on the space or area involved. Not on a single sensor. I would never trust a single device to determine occupancy myself.
4 Likes
There is nothing in the platform architecture currently that I'm aware of to leverage rooms (or any concept of space) in automations, only devices and variables. Seems like a much bigger change request.
You can set up or write an automation app to use all those inputs to set a virtual occupancy device, which in turn can trigger further automations - that's the whole point. Devices can be used as an abstraction layer. In the current platform model, you'd still want an appropriate Capability on that device.
I understand but I don't see the relevance. There's lots of devices, including motion sensors, that can't be "trusted" (see, for example, Zone Motion Controller, false motion reduction). No battery-operated device can be trusted IMO. Robustness and resiliency are separate topics.
I totally agree. Just becaude it isn't easy doesn't mean it doesn't have merit.
Yep and the rooms app I mention in a way does that, but it would be better if it wasn't in a app and device, but at the room level. Keep in mind that Room Manager all came before Hubitat eve. Had a thing such as rooms.
I understand this isn't a simple ask. But seems to me to be the best go forward option.
