No. I am not saying that. If you look back through the early days of the es1 discussions I participated quite a bit. I might have been the first to mess with them. Who knows.
Mmwave sensors are substantially more complex than what the firmware in these exposes. The features that are possible include object counting and tracking objects in multiple zones. Mmwave is used in life safety to detect breathing and heartrate. Some detect falls. There is a huge range in the quality and intent of the firmware tuning the use of the sensor itself.
I've tested dozens of these things. None are perfect. None give enough control to cover a room effectively and correctly with only a single sensor. None of them give us access to the true potential of some of the more feature rich sensors.
This thread isn't maybe about mmwave, but they have potential. Hue motion with zigbee has some potential also. Cameras with Ai have potential. All of these and more can feed events to rooms or spaces attributes to report presence.
Say a room had a destination for presence events. You set the fade time on that room ocxupancy to 10 minutes. You now have rules from a wide range of sensors that simply send an event to the room object. As long as it keeps getting events that room is occupied. 10 minutes after the last event was sent from a sensor the room object has a state of unoccupied. You could use mmwave, pressure mats, camera, vibration sensors, pir etc etc.
It does feel like if we can't decide on what we want, it will be hard for the developers to land on something people will agree on... Just an observation...
Hopefully that's not how Hubitat's architecture and core feature list is managed. It's not a democracy.
If your suggestion is similar to @mavrrick58 's then my reaction is: feels like snatching defeat from the jaws of victory. The platform architecture has no concept of a room (or space) participating in automations. Adding that concept to the platform would no doubt require massive changes. Likelihood very close to zero, regardless of the idea's merit.
Contrast that to the OP's request, which is an incremental change to an existing concept already leveraged across the platform.
Meanwhile SmartThings seems able to evolve its list of capabilities (it has occupancy and radon, among others).
Sensor aggregation/fusion is a great tool (which I use profusely btw) but that's orthogonal to the discussion IMO. Still: you could achieve what you describe by creating a virtual (occupancy) device, calling it "Baby's Room", and writing apps, using RM or WebCORE to set its occupancy from multiple sensor inputs. That's possible today if you accept to use some other binary state sensor capability to represent occupancy.
I did look through some of those topics and found lots of opinions along the lines of "mmWave is just motion, but better", which, as you pointed out yourself, is ill-informed.
Fair comment... All I was hoping to achieve was to guide the conversation more towards consensus, it was not meant as any kind of jibe at how a productive conversation could be interpreted by the developers of our platform of choice. Glad to see you are moving the conversation along more than I have been able to.
If you don't mind me saying, you kind of come across negative. This thread is an open discussion. I like a healthy debate, but ad hominem darts sorta takes the fun out of it.
My thought is the concept of child(sub) locations would be what a room becomes. Those child(sub) locations then would be able to have attributes added to them and then programaticaclly updated by other items on the hub. Then you woud simply be able to subscribe to those child(sub) locations for events of the attributes just like we do now for things like HSM, or mode, but from the child location.
On a different note i just spent some time trying to figure out what would be a good alternative to my Govee Presense sensor to add to my environment. Trying to pick one today doesn't seem easy based on how inconsistant the potential functionality is. Then there is the concern of so many of them are cloud based. I was thinking about the Aqara FP2, but that seems to be problematic. Now there is the FP300 which seems promising, but isn't really avaliable. There are some that are more avalaible but are hardly more then just a PIR Motion sensor.
The Aqara FP1E is interesting as it is Zigbee, but it also is missing allot of the potential functinality.
All of that inconsistancy also makes this conversation much more complicated.
Agreed. Which is why I think it's important to consider a holistic strategy. One that is not dependant on a device or device functionality.
Unlike maybe some other members I'm open to talking about big ideas and solutions that seem hard to implement because without long term goals short term solutions can easily cause more problems and complexity.
I thinks features that make rooms, spaces and sites smart could be make organizing and supporting occupancy or presence easy. It could also add new capabilities beyond presence. It may help with Ai and voice in the future.
Honestly i think this is a big one. It coul be a direct way to ensure you tag a device to give a attribute for a room. HA actualy does this. When you go into the setttings "Area, Labels, Zones" you can configure Rooms. In their you have the option to assign a device to provide a Temp, or Humidity for the room. I don't see why that couldn't be expaneded to also have occcupancy, and be determined by a list of sensors.
I am pretty certain that those settings are used for AI when it is setup to provide those values back when you ask about a room condition instead of a device condition.
I think I would lean towards sensors etc putting events on a space queue for occupancy VS devices inside that room or space being tagged and associated with the space or room. The former allows greater flexibility by enabling rules at device level on what it wants to send to the room or space.
I like being able to define spaces. Rooms is obvious, but if I have back yard I have pool, pool house etc. Or maybe I have basement that also contains bar and boxing ring. Maybe the master bedroom has main and fireplace or sitting area etc.
Nesting and inheritance would be my desire. If a room space is occupied all of the parent spaces are also occupied, but not other child spaces. Parent spaces cannot be unoccupied if a child is occupied.
I'd want to ask:
Is anyone at the property?
Is the house occupied?
Is the house supposed to be occupied?
How many spaces are occupied?
Is upstairs occupied?
Maybe you get more advanced:
How many people at home?
Where is the cat?
Was anyone up at 3am last night?
Did the cleaning service spend at least 5 minutes in each room last week Tuesday?
...
Interesting idea. I can see a few examples why you would want to allow a device not in a area/space to assign attributes. I would expect though perhaps it would need to still be limited at some point based on some allocation. Maybe the Main location is the Hub, then the first area/room would be the parent that must contain all devices for any lower areas that can select from devices from the parent area/room. I like the idea of nested rooms.
I am not sure how a UI would work for that though
I think we are saying the same thing. For example, I would expect when you setup a area/room in Hubiat and select a Temp sensor, the room would act like a smartapp and subscribe to the sensor. Then when the sensor updates it sends the event to the area/room. Then the area or room would analyze that event and update accordingly. Maybe if multiple devices were selected it would average them for temperatures or humidity, or for something like occupancy review all of the devices and decide if a area/room is occupied.
I think that kind of thing can work, but I would prefer it slightly different. I'm going to make an example to try to illustrate it. I am not saying it should technically work this way, but I think it might help get the concept across.
Let's say you have a room or space object. Forget nesting or inheritance for a moment. Think of the room or space as a balloon filled with air. Now you have sensors or really anything intentionally sending a simple message with an indicator of "occupied" to the room. This is a shot of air keeping the balloon floating. Doesn't matter how many things are keeping the balloon floating. The balloon doesn't care what is making the air flow. Now you have a balloon setting that effects just how light it is. All it takes is a blow of air every 10 minutes to keep it floating. If nothing sends a blast of air the balloon touches the floor. In this case the if the room or space doesn't get a message in 10 minutes the room state becomes unoccupied.
I totally agree with also having devices tagged with room or space. This gives context for voice etc. Like turn off all lights in the guest room. We should also do that. What I don't buy into totally is the room using only the default state of the sensors that are tagged for the room determining the occupancy. I think setting up occupancy needs to be intentional.
The back yard example might be easier. Let's say I have an ai camera determining occupancy of a pool separately splash playground. I have two zones in my camera. It can send events to two different spaces. Pool and splash. That camera is actually in backyard. Pool and splash are child object's of backyard along with the lawn dart lane and the BBQ pit.
While a room or space could subscribe to sensor activity I think it's also important to use other methods that are decoupled.
Reading this thread. The idea about occupancy being a property of a room is nice in principle, but what would it achieve more than a virtual sensor ? It would still require an app or custom rule to toggle it based on some sensor. So the only thing it really solves is creating the virtual sensor/state.
I remember when I tried to implement a virtual switch in Home Assistant, and I found it soooo complicated, because there is no such thing and it had to be some custom attribute of I don’t remember what…
Virtual devices are a powerful concept. If the thing became a room attribute, I think at most they should just facilitate the creation of a virtual device in the room. That way nothing else has to be changed.
Why not just have the event trigger a routine that checks the state of the associated sensors. If all are in the state that represents no presence or activity then unoccupied. If any sensor is in a active/present state it is occupied.
Got to remeber by nature this system is event based. In theory you couls get a active state and not go inactive for hours. Why require it to keep sending the active state when nothing has changed.
Totally agree howere that is accomplished. I would expect the area/aroom attribute to somewhat dynamic in setup so we can be very intentional. The key is based on use occupancy couls be setermined
Occupancy isn't currently a standard capability which is how this conversation started. The concept of expanding the room function to a room/area that functions as a child of the main home location with sub areas allows for a more flexible way of dividing your home potentially and controlling those areas or obtaining information about those areas. Occupancy really isn't a sensor thing but a space/area/room thing. A sensor can detect something is infront of it ie present or active but may not be sufficient to say a room is occupied based on its coverage and such. Lastly as part of the room setup much of the need for a app could be eliminated by including to attribute setup as part of the room/area setup.
All that said you certainly couls configure a virtual present sensor as a room and write some rulea to control its state. But i think what we are trying to discuss takes the functionality a bit further then that.
Maybe that could be maintained or forked by someone? It appears to be abandoned at this point, the author hasn't logged in since 2023.
This app actually works pretty well, and is very sophisticated in how it can be used. It would be nice if this were a built-in app that leveraged the existing room concept.
I believe it's better to doucouple because the thing updating occupancy state might not be a sensor.
Are you worried about processing? This is how the active state of a motion sensor works. This it basically treating a room or space as the state keeper with multiple sources of motion data while the room or space controls fade time.
If this is a like a location of sort, you could also pass a event or to it like a app would with HSM. I would need to look it up, but basically you post the update to the location.HSM attribute. That is how . Just beauses you create one way for devices to be subscribed with the Room UI, doesn't mean you could access it via other means if needed. I am still not sure how you would suggest doing that without a sensor and event. Somehow a sensor to detect the state needs to be used.
Always.
Perhaps, but that doesn't mean that it makes sense for a hub that recieves events from those devices to function the same way. In a way you would still get some repeat events through from your devices in a room based on cooldown and how each device detects motion. Then the room routine would the manage the breathing as your example puts it by checking the selected devices states to see if all went inactive. This would cause a issue though if you setup some other method without devices involved to update the occupance value. That said i don't see how that would work with your example of breathing either.
