Zooz Sensor ZSE18 Control App

SmartApps & Automations
1

I recently purchased the Zooz ZSE18 and so far there is no problem getting to work with the hub. I am using to turn on my front porch when movement is detected, and for far it works as intended.

Since my setup is a batter powered one, I would like to enhance the use by turning off or making the sensor very unsensitive to movement during the day. The problem is that the DHT provided does not seem to allow setting settings via automations. I looked at the DHT code provided and after some digging I found that param12 is used to control sensitivity. It seems like I should be able to send the device zwave configuration commands, but I have not been successful in accomplishing this, or at least I am not sure it is working.

Can someone point me in the right direction? Are the commands not working because the device is battery powered? Is there a way to force the device to wake up and accept a parameter command?

Thank you for any help,
Jose

2

tagging @TheSmartestHouse

1 Like
3

The device’s radio will be off for most of the time to conserve batteries, that’s how Z-Wave battery devices work. They only wake up to send reports to the hub and periodically to receive new information from the hub (usually every 12 hours). You can decrease the wake-up interval but it will decrease battery life in the long run. Another way to wake it up is to the Z-Wave button for 5 seconds but it sounds like it may not work in your use case.

There could be a way to schedule a wake-up for the device in ST but we’re not as familiar with the platform to confirm that or provide any detailed guidance here unfortunately.

4

In SmartThings, this type of request is normally handled in the automation rather than the device.

The device continues to send its messages, but you create your rule so that the system only acts on the message during a specific timeframe, in your case at night.

The downside of this is that it doesn’t save battery life. The upside is that it’s really easy to create different rules for different situations without having to know the technical intricacies of the device parameters. It also makes it much easier to group multiple devices of different brands into one rule. And finally, it makes processing a change in the trigger conditions a lot faster. That might not matter for a case like the one you described, but it can be helpful for conditions like home/away where depending on reconfiguration of the device might cause you to miss some condition changes during the reconfiguration.

Can you show us a screenshot of the rule you are using now to turn on the light?

5

@JDRoberts Thank you for your post. I know how to use the automation to make it so that lights only turn on during the evening. That’s pretty easy. I don’t have a screen shot, but I have done enough of them to understand how to do it efficiently. Basically, the sensor makes the light turn on only if it is evening and then the light turns off 5 minutes later…

From what I am trying to do, maybe the trick is to enhance the physicalgraph.zwave.commands.wakeupv2.WakeUpNotification event handler and respond with zwave.configurationV1.configurationSet with the parameters in question?

Regards,
Jose

6

It should already do that if there are any changes to send. @krlaframboise would know since he wrote the DTH.

7

@Automated_House , @krlaframboise

Yes I’ve been looking at the DHT and it does do that. What I’ve been trying to figure out is how to set the values of configParams at dawn and dusk…It’s easy to write a smartapp that wakes up twice a day to do this, but since there is no door into the DHT to change the parms, I created new command to allow me to do it. At first I thought all I had to do is change the values of configParams, but that is not doing the trick.

I’m sure it is my ignorance here, but I’m not sure how configParams is even set.

Regards,
Jose

8

It will only work if you are transmitting the parameter change at exactly the same time that the sensor has woken up to receive hub communications.

The biggest engineering challenge for devices of this type is getting the batteries to last about 12 months. So these devices are designed as “sleepy“ devices which means they sleep most of the time. They wake up for only a millisecond or two at a set interval and evaluate the environment to see if motion is happening. If it is, they send a message to the hub. If not they go back to sleep.

Configuring the parameters requires that the sensor listen for transmissions from the hub, which is a different kind of activity, and then process them. This is quite a battery intensive action, much more so than just The regular check for motion. This is why in this particular case the manufacturer has set the device to only listen for hub transmissions twice a day. And you have to catch it right at that time.

If you have an important reason to set the parameters, you can also manually wake it up by pushing the button on the side five times, but that doesn’t fit your particular use case.

Battery operated Z wave devices are normally only configured at the time that they join the network, unless it’s some other one time event like setting up an association, which is what the manual button is for.

So… I’m not really sure what you’re trying to accomplish here. Doing a full reconfiguration twice a day is likely to run your batteries through, my guess would be they will only last three or four months if you have that setup. So it’s not something most people would choose. But it’s your sensor so if you want to do that, you can.

However, you have to get the timing exactly right so that you are sending the reconfiguration request during the little tiny time window that happens every 12 hours. If you send it at any other time, the sensor is going to be sleeping and it won’t hear the configurations request.

@krlaframboise has done a lot with this model and should know better if there is any way programmatically to synchronize this other than just trial and error.

But I think it’s going to be tricky to set up and it’s going to dramatically shorten the battery life compared to just putting a time filter on the automation.

Your choice. :sunglasses:

9

@JDRoberts covered all the things I was just about to write.

The ZSE18 can be joined as a USB powered device so if you don’t plan on using it with batteries then what you want to do is possible, but the code change still isn’t as simple as you made it sound…

1 Like
10

@krlaframboise @JDRoberts

Yes I understand that you don’t want to have the device waking up too many times (more than the 12 hours setup or twice per day) I think the best way is to add configs for the day and configs for the night and when the device wakes up it decides if it is daytime or night time and then set the settings accordingly. No smartapp required and no excessive waking up. Obviously, this is not required, but I think it should improve battery life, no?

What do you guys think?

Regards,
Jose

11

No. It will definitely make battery life worse, probably much worse.

The process of communicating with the hub is the most battery intensive thing the device can do. You are saying you want it to hear a message from the hub (and you’re going to have to get the timing exact, I don’t know how you’ll do that), run some logic to figure out whether it’s daytime or night time, and then go through a configuration step, which is the second most Battery intensive thing it can do. It’s probably the equivalent of taking 1000 sensor readings, maybe more.

It’s just not the kind of thing these devices are designed for.

If you can figure out how to do it, you can test it for yourself, but I don’t think you’re going to get the outcome you’re hoping for.

12

@krlaframboise should definitively say, but what I am seeing in the DHT is that all the configuration changes happen when the device wakes up. You then have to tell the device to go back to sleep. There is no timing to figure out. You respond with the commands you want the device to execute before it goes back to sleep. At minimum, the DHT sends a “go back to sleep” command every 12 hours. Is sending 1 more commands that much worse? 1000 sensor settings worse? Maybe “go to sleep” is much easier than “set this config”, of course.

As far as figuring out the day or night logic. I came up with this simple code:

    def currentTime = new Date()
    def currentHour = Integer.parseInt(currentTime.format("H", location.timeZone))
    log.debug "$currentHour"
    if(currentHour >= 6 && currentHour < 18 ) {
       day()
    } else {
       night()
    }

I guess it is crude but close and simple enough.

I’m sure you’re correct about the battery difference, not trying to contradict, just thought it might be neat to think about the sensor going to “deep sleep” during the day. Again, thanks for all the help and comments.

Regards,
Jose

13

Awesome! The engineering team mentioned this behavior is normal because removing a device profile from the package is not currently supported. This is to avoid inconsistencies with the devices that could still be using this driver, removing the profile would leave them in a weird state.