Could be related to the Sep update/zigbee instability pointed out below.
Events right after the Sep Hub + App Update
ST SmartSense Motion sensor stops detecting motion. Resetting, changing battery, removing + adding device has no effect
Found out about the zigbee insecure join, thought it was dropping off and unable to rejoin, so went in to Hub, enabled the insecure join and got the ST Motion Sensor working again
Except that now it’s sensing ghosts, gnomes and pets I don’t have. Repeatedly throwing false positives.
I have other motion sensors (monoprice and aeotech) that don’t seem to have issues.
Yeah, we’ve got the ghosts too, but only once or twice a day.
Since the recent update there has been a really significant increase in delay between when the motion sensor and SmartLighting turns on the light in the room. Last night we counted nine seconds for a set up that previously reliably took less than one second. It’s really noticeable because this is the guestroom, you should open the door and the light comes on.
The motion sensor is a second gen SmartThings Motion sensor. The light is a GE link connected directly to the SmartThings hub. The delay has been consistent since the hub firmware update.
After your post, I decided to check for phantoms. And indeed, the motion sensor reported activity in the room at three in the morning, when no one was in the room. Battery level for the device is fine. There was no HVAC activity then either, and the windows weren’t open. Obviously no sunlight issues in the middle of the night. The motion sensor is set at shoulder height for a person and the door to that room is kept closed so no pet issues. So that looks like a ghost event.
There were also several ghost events on Thursday, Friday, Saturday, and Sunday. None on the previous Tuesday or Wednesday ( before the hub update).
That would require adding at least one additional motion sensor, which is an additional cost that hasn’t been needed for the exact same set up for the past year.
Plus there’s no reason to think that a new motion sensor wouldn’t have the same problem, since I’m pretty sure this is the platform, not environmental.
Granted, if it’s highly variable one physical sensor might have the glitch when the other didn’t – – but this is a small room, 10 x 10, and the motion sensor is only intended to catch the door opening. I don’t need two devices for that.
I know Mike’s zone manager is a very cool smartapp, and that’s great for handling situations where false positives are caused by environmental issues. But this one isn’t.
As @JDRoberts pointed out, its (=ZMM) a really cool app – one that I am planning on using soon (look to integrate that with CoRE). However, this seems to be a platform issue (or a ST Smart Sensor/Zigbee + ST combination) and don’t want to add another app to the mix and add one more thing to troubleshoot. Need ST to stabilize 1st.
Hmm, I have a contact sensor giving me a combination of ghost events and missing others…
Never mind, I have a bunch of dead batteries.
One weird behaviour that I noticed though. I have an ST multi on front door that gives open/close status, but no acceleration, and I have another ST Multi on my dining room door that gives me acceleration events very very often (but faces a busy street).
I’d love to be able to tune the sensitivity so I can use the one, and have the other one actually register when it opens and closes.
Battery is at 88%. Support is asking me to move the ST close to hub to see if distance is an issue. Not sure why after all these months, distance is an issue. Btw the sensor is 20 ft away. Unless the sep update did something to the range.
Sensitivity is typically defined by the SmartApp (ie., if the (X,Y,Z) changes by more than some percent). Unfortunately, it’s not possible to adjust this sensitivity in Smart Lights (or other first party SmartApps), but it is theoretically possible to do so with a custom SmartApp
Yeah, I noticed that it was theoretically possible, but haven’t dug too much into what it takes to start writing my own SmartApps. Sounds like a job for CoRE. @ady624
On a related note, I had my ghosts open my front door at 4:50am, and it’s hard to debug that one with the vibration never working. That one doesn’t have a fresh battery yet though.
So I did what support asked - Moved it closer to the hub (sitting next to the hub) to see if distance is an issue. In the last 3 hrs, there are no ghosts. Let’s see if this holds up. If it does, my next question is – what caused these range issues to crop up? What is the new acceptable range?
I had no ghosts last night, and I haven’t made any changes in anything, including the sensor location. So your moving it might not have made a difference.
Also, the sensor being out of range would cause it not to be able to get its reports through. But it wouldn’t cause ghost reports. So if there was a real activity report and it got through, and then the inactivity report never got through, you might think there had been continuous motion for longer than There was. But range wouldn’t just randomly cause a new activity report to appear.
And another also: zigbee spreads. If you’re trying to get a stronger signal from the hub, the best place to put the sensor is not right next to the hub, it’s about 10 feet away from it. You also want it to be at least 10 feet away from your Wi-Fi router. So in the same room with a clear line of sight to the hub is good for testing, but move it a few feet away.
There are three likely things that should cause you to have to move a zigbee sensor that used to work at 30 feet closer to the hub.
the battery is dying
Two) there is a new source of interference, typically boosted Wi-Fi. This could be affecting either the sensor or the hub.
Three) the device was previously using another device as a repeater to get signal to the hub and the other device has moved or become defective.
Moving the sensor close to hub worked – no ghosts overnight.
Moving it back to its original location brought back all the ghosts.
Temporarily removed the sensor from all CoRE rules + other automations. So other than the Sep update, nothing in the environment changed. Same Wifi, house, people, no pets, squatters…Unless the battery has decided to go bad at the same time of the update, continue to report 88% but not work in reality… However, I am going to swap it out, put it in its original location and see what happens.
I suspect this is what happened. Not sure if there was a change or it’s more coincidental… but when the Hubs rebooted after the firmware, we have come across a number of Zigbee networks that mapped through a meh repeater.
In my case, we may rule this out, because I never had any other zigbee device in the network. There are a whole bunch of zwave devices. The area where this Zigbee motion sensor also has Aeon MultiSensor 6 (which is zwave) and other microswitches which are also zwave. I double checked the devices.
I am trying to get my head around this thing – as @JDRoberts pointed out, the fact that it is reporting motion means that it is in range and is communicating via hub. So range can’t be the issue - right?
If range is not the issue, why it the sensor reporting ghosts? It could be the battery or could be the sensor itself going bad.
And I don’t know enough about the platform to know who is in charge of triggering the notice.
Is the hub merely relaying the info from the sensor, in which case the sensor is going nuts OR
Is the hub saying “I got a report from the sensor, let me decide what to do with it”, in which case the hub is reacting to events that it previously did not…"
