This works if I walk into the room, then leave. But, if I stay in the room until the lights go out, the sensor does not detect any motion. If I then leave for 5 mins or so, the sensor will again detect motion when I enter. If I leave the room immediately when the sensor triggers and wait for the sensor to show “off”, then walk back in immediately, it triggers.
I suspect this behavior is a consequence of the sensor using PIR. It looks like my motion while still in the room isn’t producing enough IR difference to trigger the sensor. It seems that this sensor is not good at detecting motion in a room with someone already in it and is only good for detecting if someone has entered an empty room.
Do I have this right? If so, what I can do? Is there a way to make this sensor work? Is there another sensor that uses a different technology that will do what I want it to do? Again, I need it to detect that someone is in the room, moving around, and keep the lights on.
Most sensors detect movement perpendicular to device. If walking toward device many times they not trigger. Walking across the trigger.
There is also height that prevents trigger. Beam may be above moving object when closer to sensor.
My point is that you should consider if the mounted location of sensor allows it to detect common movement. Also, this will not work for person in seated position and will only detect the movement through room mostly and not too good for small movement within the room
I forget what it is but there is pin inside that puts sensor in a test mode, changing time between trigger from 1minute or so to 3 seconds (I forget exact amount). I reduces battery life but is much better at detection for home automation as it provides more sensor data
Thanks! It looks like you may be right. I mounted the sensor such that I was standing off to the side of it while in the room and got it to re-trigger. Originally, I had it pointed straight at where a person would be standing. I’ll play around with position some more.
Ok, this horrible sensor is giving me fits. After much experimentation, it looks like the sensor sort of hangs if there’s motion while the state is “on”. If I make it turn on, then leave the room, it will re-trigger immediately with motion after it goes to “off”. If I expose it to motion every couple of minutes while it’s on, once it goes off, it won’t re-trigger. In the past, I’ve seen it recover after about ~20 mins and work again. As I sit here right now, it’s still not working after about 30 mins.
This is the behavior with all three pet immunity settings (none, pet1, pet2). I’ve tried removing it from the z-wave network and adding it back. Behavior is the same.
Note that I’ve disabled the automation and am just watching the state of the motion entity. So, it’s not that my automation isn’t working, it’s that the sensor is behaving oddly.
I just called Ecolink support and the person claimed that these will only work with a SmartThings Hub. I was told this was something “new” so it wasn’t documented. I’m not sure I believe that this is really the issue, but I’m at a loss right now.
I have 3 of these Ecolink PIR sensors. I have all of them set to no pet immunity and also set for 4 minute timeout on no motion. I have played around with each of them and they trigger within a second of walking into its field of vision/beam and if I walk away, after 4 minutes the sensor goes back to off or no motion detected. If there is continual motion within that 4 minute timeout, the sensor stays as detected until the 4 minute timeout elapses. Also they re-trigger within seconds after the 4 minute timeout without issue. I use an Aeotec Zstick Gen5. Is it possible you don’t have the binary reporting setup properly on the node? Mine is set for Parameter 1: Basic Set Report when sensor is restored - Disabled and Parameter 2: Basic Set Report - Enable Binary Reports.
Are you using the Z-Wave JS integration? If so, then your setup should be identical to mine.
Yes, it’s possible I don’t have this binary reporting set up properly given that I hadn’t heard about it until you mentioned it :). I googled for some instructions on how to change these parameters but what I found was 3-4 years old and they don’t seem to match what I have in HA. I have no z-wave control panel option on the left side. All I have is the z-wave control in the integration section of HA.
I did find a service called “Z-Wave JS: Set a Z-Wave device configuration parameter” in the developer menu. Is this where I would change the parameters you mentioned? If so, where can I find a list of available parameters? I did find some references saying that this wasn’t implemented yet.
I do have the Z-wave JS to MQTT app. I looked there for this device and found this:
Yeah, I played with that too. It still doesn’t work as I would expect. It seems to me that I should be able to have it in “normal” mode and set my automation to keep the lights on when the sensor is in the off state for at least 2 mins. The sensor should look for motion again before the 2 mins expires and the lights should stay on. I don’t need the sensor to be looking for motion every few seconds and I don’t want to waste the battery doing this.
sorry, I don’t use Zwave JS, I still use the built in Zwave integration. Yes those are the two parameters and yes it appears those parameters are set on your PIR. are you able to view a network graph with Zwave JS? I’m wondering if your PIR is not a direct neighbor with your Zwave hub. If it is a direct neighbor, you will see node 1 listed first in the neighbors list of the PIR and whatever node the PIR is listed in the neighbors list for the Zwave hub. If one or the other is missing a neighbor, you may be missing some packet traffic.
Thanks for the response.
MQTT does give me a map. It looks like all nodes have a direct connection to the hub. Node 27 is the PIR sensor. The PIR is just on the other side of a wall from the hub.
I have to admit I don’t know what the little rectangle is on node 27.
It seems that the sensor may be behaving better now, but I’m not sure. And, if it is, I’m not sure why it would be. But, we’ll see…
That looks like a battery symbol and as the battery drains over time, the block will decrease the amount of fill to represent that. I’ve had one PIR for close to 4 years and it’s been at 99% for about half that time. The other two PIR are about 1 year old and still at 100%.
You might benefit from healing the node. Maybe healing the network. I don’t know where those options are in Zwave JS. The heal node forces the node to update its neighbors list and re-map its routing table and report back to the hub. Healing the network does the same thing but for all nodes and is very time consuming depending how large the network is, and typically renders all nodes unresponsive while the heal is in progress. Though if the node seems to be behaving better, I’d hold off on any of the heal procedures and monitor it for now.
Ok, thanks for all the suggestions. The sensor seems to be working well now. I believe the reason is that I updated the Z-wave JS add-on. After messing around for hours, I happened to notice that several add-ons had updates available. I didn’t update because I thought it would fix any problems. I just figured it would be good to have the latest versions of everything. I think it was after I did this that the sensor started behaving. I’m currently running 0.1.20. I can’t remember what I was previously running.
