For what I can see from your log, motion triggers occupancy but can be retriggered while occupancy is in effect. From an automation point of view would'nt be best to distinguish between those in order to have more flexibility?
What do you think @tomw
You're going to have two different virtual devices for those motion and occupancy entities, right? Whichever is the most intuitive attribute to someone trying to drive automations off of the occupancy child should work without affecting the "real" motion entity.
Maybe I misunderstood. I thought the proposal was:
One motion virtual device with the motion attribute reflecting the HA motion entity.
A second motion virtual device with the motion attribute reflecting the HA occupancy entity.
Which is preferable to either a presence virtual device OR a custom occupancy virtual device, either reflecting the occupancy entity.
Correct?
I thaught presence would reflect more accurately occupancy instead of having two motion sensors from the same device.
That's what I was thinking, too (re: presence)
Well I get confused. The proposal:
One motion child device reflecting HA motion entity.
One presence child device reflecting HA occupancy entity.
Is that correct?
Presence, in the Hubitat ecosystem usually implies whether a specific user is at a location or not. Not whether or not a room is occupied.
I agree with @jlv in using a second motion sensor. If possible, maybe its name or label could reflect that it is an occupancy sensor?
In that particular case the entity_id is different but the friendly name is identical. That would require a special handling of the label.
Would using presence as a room occupancy sensor would break something in Hubitat?
We could also just make a custom Generic Component Occupancy Sensor with an "occupied" attribute.
That probably would satisfy everybody
No, it would not break anything. I suppose we could create a custom child device with a custom ‘occupancy’ attribute as well. Lots of options… 
In general, I doubt this is going to be used by all that many users. Going with the simple design requested by @jlv might be the simplest and easiest solution. I personally feel that the ‘occupancy’ sensor will be used just like any other motion sensor.
@tomw @ogiewon Both of you suggested the custom component as a possible solution. I think it is what we should go for.
@jlv can you work with that?
Correct. This is how it looks in HA.
With my change, I'm now getting them both exposed independently, and it seems to make sense, even if both show up as motion sensors.
FWIW, both the Hubitat Ecobee cloud API integrations I've used (the built-in one and the Ecobee Suite) expose the occupancy property as motion (but they don't expose the motion property; I don't think it's available in the cloud API). E.g., this is occupancy showing active:
I think having it as a motion sensor will make it the easiest to use in automations. I think making it presence works, too, albeit with a little loss in making easy automations. I think making it a custom component would make it the least obvious to use in a rule.
E.g., Room Lighting has motion as a easy to use Means To Activate. Either of the other options would require the use of selecting Custom Attribute. The same with Simple Automation Rules.
Another data point: the Aqara Fp1, which is a mmWave sensor and something that acts like a PIR (maybe it is a PIR).
The driver for it reports the PIR as motion and but the mmWave as presense.
Sounds like there is precedent for using motion as well as some benefits in other Hubitat built-in apps. Custom type wouldn't have any of that, so I prefer motion based on what @jlv shared.
Ok. I did not think about that.
Using presence as an occupancy sensor in Aqara driver is a choice made by the developer. Maybe Hubitat should add this capability.
So lets go for @jlv proposal then.
![16746198009326489209231737430783|666x500]
(upload://neeLOiXcc9K7ir9Oey8TKgt9En1.jpeg)
I did fallow the instruction above but Not sure why i can't find any devises from ha.
can't find any devises from ha.
Is this when trying to select devices from the app or when looking for included devices on the devices page from Hubitat hub?
South Africa is experiencing a massive energy crisis that has resulted in scheduled power cuts lasting 2.5 hours at a time, according to schedule (per neighborhood) that changes on an almost daily basis. In other words, scheduled blackouts that the energy provided calls "load shedding".
There's an add-on available for Home Assistant that pulls the schedules into HA from the internet. I set up HA in the hope that with the help of that add-on, I can access that information in HE. One of the entities the HA add-on creates, has an attribute "Starts In" which contains the time before the blackout starts (in minutes, e.g. "183"). I want to use this info to set up a rule in webCore that tests if my solar batteries' state of charge is high enough to last through the blackout, say, an hour before the scheduled blackout begins. If the state of charge is too low to last the 2.5 hour blackout, I want to change the solar inverter settings to draw power from the grid to charge the batteries so they have enough capacity to last for the duration of the black out. (I can change the inverter's settings from HE for this.)
The device where the information is stored in HA pulls through to HE with HADB, but unfortunately, not the attribute containing the information I need. (The Device Type assigned in HE is Generic Component Unknown Sensor
The device in HA looks like this:
And the attributes of the device:
Is there a way to pull through the attribute information to HE with HADB? Or perhaps by way of some other solution?
Thanks in advance.
Download the Hubitat app
