zha-device-handlers
zha-device-handlers copied to clipboard
[BUG] Philips Hue Motion Sensor (SML001 & SML002) Motion & Occupancy Wrong
Describe the bug Philips Hue Motion Sensors devices have the following problems with their Occupancy and Motion entities:
- What is currently showing as the "Motion" entity is DEAD. This entity's state is always OFF, never changes.
- What is currently showing as the "Occupancy" entity is actually the "Motion" entity and works fine but has the wrong device class (should be 'Motion').
To Reproduce Just install a Philips Motion sensor.and you will see that what is currently showing as "Motion" entity is always dead, never changes state. On the other hand, what is currently showing as the "Occupancy" entity is actually the "Motion" entity and works fine, but it just has the wrong device class.
Screenshots
Was testing with one of my and they is only sending status changes from endpoint 2. Was trying re configuring and its saying OK and also the OnOff cluster is being OK bonded to (the coordinator ?) but is not sending any OnOff to it.
Then the OnOff cluster is for sending light commands it can being that its not liking sending then with unicast to the coordinator and must being bonded to one light group or its only working with group added ZLL paring (its still one HUE ZLL device.
The class "Motion" is for light controllers that is sending on commands with off time to one light group and shall not being mixed with "Occupancy" that is one "real" motion sensor class and not one light controller.
I cant testing so easy then both my sensors is on my production system and its running full debug for the moment = the log file is very large and cant being open in HA.
Oh, really sorry, I don't know how to see all the technical aspects you are mentioning. I am just telling you what I see in HA UI: All my Philips Hue Motion sensor devices get 1 occupancy entity and 1 motion entity. The Motion entity is always dead. It does absolutely nothing, never updates, always off. The Occupancy entity behaves like a normal Motion entity. It works perfectly; it just has the wrong device-class (should be Motion not Occupancy). See my screenshot.
Apologies I cannot get any more detailed info.
The OnOff sensor is connected to a pinhole switch inside the back cover labeled as "T".
Not sure if that is T for Test or T for Tamper, but it is functional, even if effectively useless.
The last i think but i testing it and reporting back !!
Looks working 110% toggling the OnOff function but it cant being tamper then its have no maniacal detection and i was also testing with the strong magnet if they was having one magnetic sensor inside but i dont getting it working = no togglen of the OnOff cluster :-(((
but it cant being tamper
Yeah, not sure why it's there. My guess was it was designed as tamper then abandoned, but why still install the physical switch on the board at all?
No real news but just linking my comment here: https://github.com/zigpy/zha-device-handlers/issues/804#issuecomment-1126735659
(Basically, the on_off
sensor should be disabled, as that cluster is only used when pairing the sensor directly to a bulb IIRC. The Occupancy
sensor can then be marked as a motion sensor.)
Same Problem with sml003
@tomg1970 Have you seen my comment here: https://github.com/zigpy/zha-device-handlers/issues/804#issuecomment-1126735659? The sensor basically works as expected. The "OnOff" sensor can be disabled/hidden and the proper "Occupancy" sensor set to the "motion type".
@TheJulianJES
Sorry to be blunt, but your comment is not a scalable solution and the motion sensor device is not "working as expected" - for those of us with many sensors (I have 20 hue motion), this is a ton of manual effort.
This problem is a bug. The "tamper" (on/off) is not a motion sensor and the entity reported as "occupancy" is actually motion.
I'm with lougreenwood it is a bug and I think the problem should be fixed in code. I'm only not smart enough to do it myself...
the motion sensor device is not "working as expected"
The manufacturer decided to use the "Occupancy Cluster". A motion/occupancy sensor is always a binary sensor in HA. ZHA just recommends HA to display the binary sensor as "occupancy" (for obvious reasons). It's four clicks to change it to motion in the UI and there are no functional differences whatsoever. It's just the UI part that changes. Automations work the same regardless of what type the binary sensor is set to.
Not recommended, but you could even modify the files where this is stored (you shouldn't do it and especially not if you don't know where this is stored).
If you want to change the type for all your 20 motion sensors, just go to the integrations page, click on the entities tab, enter "occupancy"/"sml" (or whatever the entities are called by default) and then do the four clicks to change the type for each sensor. For 20 sensors, this should take 1 to 2 minutes.
The "tamper" (on/off) is not a motion sensor
This isn't a tamper entity. The manufacturer decided to also implement the OnOff cluster. This is used when you bind the motion sensor directly to a light (so it turn on/off a light without HA at all). With a quirk, we could remove the OnOff cluster, but we'd break the ability to bind the OnOff cluster using a UI. You can just ignore the OnOff entity (or disable it with 4 clicks).
The issue isn't closed for a reason and I've also looked at improving this, but it can't be done in a clean way from what I looked at. With a quirk, we'd need to completely remove the occupancy cluster and manually fake an IasZone cluster to provide the data there ... which is hard to do, can break easily, and also breaks existing installations. Perhaps the BinarySensorDeviceClass could be hard-coded directly in ZHA for these sensors, but that's also not really a proper solution. As long as quirks are the way they are (using ZCL as the interface), there's no way to properly improve this.
So, at the moment, I'd rather focus my free time on fixing more important things. If you have another way to fix this, feel free to PR it and we'll be happy to look at it.
Edit: I've looked at this again, and it might be possible to just override the device class in ZHA by default for the four models of Hue sensors.
As a note, the "Motion" is not dead. It gets triggered by a second button inside the battery compartment labelled "T" I have no idea what it actually does. My work around for this, to make the motion sensor motion instead of occupancy was to change it in Home Assistant, the platform I use, but if a fix upstream can be made, well I am watching this space for that :) As a note, In DeConz, which I use to use, it is detected properly as motion.
will the issue be fixed in any future release?
@Mar1usW3 Then both Z2M and ZHA is having the same problem i think you shall asking that question to Philips if they can fixing there bad device.
@MattWestb
A lot of people use these successfully with smartthings, hubitat, and even with ZHA and Z2M with different coordinator. I think we need to stop saying bad product and find out what the issue is. We know the device is not perfect, very few ZigBee devices are, but the fact so many of them work properly makes me feel bad product is not a good excuse. Even my ones have just started working without any issues or degradation after changing to a different coordinator.
Edit: If no solution is possible, then maybe it is compatibility with some coordinators
Im is one of them that its working OK and never have them left the network as long i have bad routers they can jumping to.
Yes, that is the major flaw with them. Hanging on to bad routers, or direct to coordinator
Or putting the timeout for some days in ZHA and you never see that they is deep sleeping.
In ZHA, yes putting the timeout higher may work, though, as per logs I posted a little while back, they do report their presence and last seen regularly.
I have just added these sensors to ZHA, I believe mine are the first version (they say Philips as opposed to Hue).
To me the motion sensor is the one changing, given that the occupancy is always set as detected.
@davidrpfarinha Occupancy usually is the one changing, but yes 9ne is static and one changes. It's easy to change them, but can see why it might need to be updated That isn't the only issue though. These SML001 versions sometimes get bad connections and drop out, though they have been stable for me in the latest HA release. That is under a different issue though :)
Thanks for your reply, @austwhite. I wasn't aware that they interchangeable, but I wanted to share that in my case, for some reason, is the other way around. About the bad connections, interestingly enough, yesterday I faced that issue (SML001 started to show a red light when pressing buttons) not sure if it was because I was spamming the brightness buttons. But I'll keep in eye on it.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.