Several multi sensors allow for disabling motion detection, most typically so the device can be used outside as a temperature or Lux sensor without having constant false alarms on the motion sensing.
The problem is that the disable is done through the configuration step and that isn’t something that SmartThings typically allows to be done on the fly. Instead, it’s usually done at the time of joining to the network so you can’t change it after it’s set without taking the device off the network and rejoining it which requires physical intervention of the person.
I agree posting in the multisensor thread would probably reach the people most likely to know if it can be done for a specific model.
But the configure issue is why it’s not just easy to do. most battery operated zigbee and zwave sensors are sleepy devices which sleep most of the time but wake up periodically to check and see if anything has changed. The problem with configure is reaching them when they’re awake. That’s why it’s often simplest to do it during the join.
I mentioned this specifically because it’s possible it will turn out to be much easier to do with one of the mains-powered Z wave sensors ( which are always awake) rather than the battery powered ones. So that’s just another option to look into. Although if your only reason for wanting to disable motion sensing is to save battery life, I guess there’s not much point in looking at the mains-powered ones.
Let us know what you find out.
BTW, another approach which is used in some warehouse systems is to put the motion sensors inside a frame with an automatic door flap and lower the flap when you want to turn off the sensor. Those are usually much more complicated and much more expensive sensors, often combined with cameras, but it is an option for some use cases.
This would actually be fairly easy to do. Just create a tile for enable / disable that flips a boolean variable from true to false, then using that true or false condition, parse or do not parse motion events with the handler. There is also config parameter 4 which enables or disables the PIR motion sensor inside the multisensor itself. The downfall with using that to accomplish what you are after is that any battery powered device is “sleepy”, some always, some if the are on battery power and not if they are on wired power like the multisensor 6 (the cube shaped one). What this essentially means is a configuration change require you to wake up the device which means you have to put your hands on it, and yeah, with 9 of them I can’t see anyone doing that. So the tile option to tell the parse to be ignored is the way to go.
oh also, if you’re using the smart home security stuff that’s built into smartthings now, you have the option of using or not using motion sensors to trigger events or alarms just like a “real” alarm panel has stay arm and away arm… stay not enabling and away enabling the sensors. But, just like an alarm panel, the motions are still powered and doing their job, the system just ignores them.
What exactly is your use case anyway? Might be able to be addressed with existing functionality…
As I understand it, the OP doesn’t just want to just ignore the sensor reporting an event. That would be easy to do in many different ways with current smartthings functionality.
Instead, the OP wants to save battery life on the motion sensor by actually causing it not to trigger for motion, not just ignore the reports it does send.
To put it another way… there are really 2 main “states” that motion sensors have :
(1) BEING READY to receive any commands from the hub, and likewise transmit any messages to the hub.
(2) ACTIVELY SENSING and sending motion data to the hub (at its simplest, it’s simply “yes, I’m detecting motion”, in real time).
Right now it appears that both (1) and (2) are happening as far as SmartThings go. Motion-sensing events are being sent all the time and we decide whether or not to do something with it.
Since this product is called SmartThings, it implies that it is smart. Smart implies efficiency among other things. So, there should be no need to be in State # (2) if there’s no need for it, e.g. if the overall mode is Home.
The smart benefits and side-effects of this smart separation is, saving battery life, and also not doing PIR sensing, and not sending motion data, when none of these are needed because everyone is home.
I just got my reply from the sensor manufacturer, will post it in my next message.
Here is my reply from Aeon Labs. Keep in mind I can’t tell which specific model version (“gen”) I have. I had sent them a diagram showing what mine look like. This is their reply :
So it looks like we can do this. We can just set Parameter 4 to 0 to disable, and it looks like it will accept any non-zero value to enable, although it will make a difference in sensitivity if it’s the Multisensor 6 and the value is <= 5.
I just have no clue how to write the SmartApp for this. Anyone ? Much appreciated !! This SmartApp should be fundamental enough that its code should be built into all SmartApps involving motion sensors, no ?
I understand your points however if you send a configuration command to a sleeping device it won’t get it and won’t be configured. You would need to create a state machine that would monitor whether or not the configuration parameter was accepted. Configuration commands do not generate any reply from the device they are sent to. The only way to know is to pull the current configuration parameter and check it against a desired state and if it doesn’t match, resend the command ad nauseum. This is going to mean a bunch of processing which I’m not sure ST will allow inside a device handler. Maybe. Outside of that it also means a lag in command acceptance that could go on as long as the wake up interval is set. Around five minutes in my type by default or much longer from the factory. The reason for the more often wake interval and tighter Windows on sending motion clear was to have a more real time sensor data stream as requested by the users on this forum. It sounds to me like you would be better suited to a pure motion sensor or again, hard wiring them in. I understand when you say SnartThings should be smart, but understand this is more of a Z-wave standards meets random device manufacturers meets random community coders like me kind of issue. I wouldn’t blame SmartThings here or Aeon for that matter. If you choose something that isn’t directly suited to your application it is up to you or someone else to hack it.
That said I think the multi sensor 6 is a better option in that it has a lot wiser degree of configurability I didn’t bother making a multi sensor gen 5 type because there just didn’t seem to be enough extra functionality to make it worth my time to do so.
But Robert, it won’t be sleeping. It will just be PIR-disabled, not the same as sleeping, right ? I’m pretty sure this is the case and I’ve sent another email to Aeon Labs to confirm.
Also, we don’t need to determine the current PIR enabled/disabled state from the device, we only need to send (instruct it) (ONE-WAY). It’s as simple as this :
If Mode changed to “Home” then send PIR disable parameter to sensor
If Mode changed to “Away” then send PIR enable parameter to sensor
What JD and Robert mean by the device is sleepy is that you typically have to press a physical button to wake the device up to accept that particular parameter change.
In short you would have to physically press a button on each one of these changes to wake the device up so that it could accept those commands.
So, Yes the device has the capability to turn off the pir, but It most likely can’t (at least not easily, or reliably) be used the way you want it to be used.
I assure you this is accurate. I work with Chris Cheng on a semi regular basis. You need to read the Z-wave primers and SmartThings developer documentation and perhaps it will make more sense.
Most Z wave and zigbee battery-powered devices sleep almost all the time. This is to extend the battery life and reduce the power requirements.
Unlike Wi-Fi devices which stay connected continuously, mesh devices use a method called sampling. They sleep most of the time, then wake up periodically and check to see if anything has changed.
If it has changed more then their setpoint Delta, then they send a notification report and go back to sleep.
If it has not changed more than their setpoint Delta, they just go back to sleep until the next scheduled wake up time.
Many of the devices allow you to change the frequency of the wake timer, but even so they’ll still be asleep most of the time.
As Robert has already explained, this can cause problems during configure.
BTW, you can use Rule Machine Expert Features to reveal these commands from the device, if they are available. In Custom Commands, select capability Motion, then select one of these devices, then click on New custom command. There you will see all of the commands that the device is capable of.
Even if there’s some lag-time before the machine wakes up to receive its new state, that’s still acceptable. I can always tweak the time setting for this anyway. Is this an option ?
The issue with battery devices is that many of them sleep, and while sleeping do not respond to configuration changes.
You could try this app, the configured zones can be activated for specific modes.
Unfortunately, no. The configure message doesn’t get saved anywhere. It has to hit the device at the exact moment that the device is awake. That’s why the configure is normally done during the initial join process. many mesh devices extend the wake period during the join which gives you time to get everything done. But that will require physical manipulation of the device which doesn’t really seem practical for this use case.
