Enerwave ZWN-BPC Z-wave Ceiling Mounted, Battery Powered PIR Sensor

Same results here constant motion all the time. I don’t think these work with the v2 hub.

Did you leave them in a dark draw for 10minutes?

They work for me. i had to place an eco link motion in a draw for 10 minutes to get it to stop reporting motion.

Yes I left them in a drawer for 24 hours and no change.

This is an answer and it works.

I added the enerwave to my V2, could not get it to work, tried the custom enverwave it worked on the first one.

Then added the other 6 I have - they wouldn’t work.

This branch works - I keep hitting the tile configuration button and the button on the PIR… boom, battery shows up as 100% and everything works.


@JH1, I’m glad to hear it worked for someone else too.

@JH1 @notoriousbdg @professordave Thank you all for your help. After several hub reboots and other tips listed above it worked. It took sometime to add the second sensor but it is working. I wish I could get a 100% confirmation of the steps but it seems a reboot of the hub and device (removing batteries) and pressing the device config button and the tile config. And I used @notoriousbdg code.

There are occasions when ST makes me feel like this:


These are supposed to be officially supported now. See:

Any one have luck with this?

I tried to set one up, but it detects it as a Z Wave Motion Sensor and doesn’t seem to get battery status, detects motion constantly, etc.

There doesn’t appear to be a built in specific device type added by SmartThings for the Enverwave.

What am I missing?

I have four that work and one that constantly detects motion despite trying on three hubs, different batteries, etc. I’m fairly certain they just have a high fail rate. :confused:

1 Like

What I am referring to now is the blog post that says ST officially supports these, but I don’t see an official published DH for them.

As far as your concerns - I doubt it because I have over 12 of them, and each one was a pain to get working but was able to with the modified code in this thread. I was looking for the DH from ST things though.

Z-Wave Motion Sensor is the correct device type. Note that due to fingerprint issues, it will initially join as a door/window sensor and then automatically change to Z-Wave Motion Sensor. Once they’re configured properly they send the same messages that other Z-Wave motion sensors do so that’s why they use the generic handler.

However, it appears that some of these devices have communication problems right after joining that can interfere with the configuration process. My advice for maximizing the chance that the configuration goes through is:

  1. Make sure it is properly excluded. (May have to reboot your hub if you’re not getting confirmation of the exclusion.)
  2. Bring it in close proximity to the hub to include it.
  3. As soon as the device pops up on the “Searching” screen, promptly tap it and then tap “Next” on the first configuration screen right away. You can change its name later.
  4. Wait until the green light goes out and then cover the motion sensor to confirm that it is reporting “No motion” events properly. If it’s not … start again I guess, it may be defective.
  5. Bring it as close as possible to its final destination/orientation and do a re-include: Go to Connect Now in the mobile app and wait a few seconds on the searching screen, then push the button on the device. If it works, the green light should go on for a longer time – more than 4 seconds. Don’t move it around or obstruct its signal while the green light is on.

Hopefully this will help someone. Furthermore, these instructions should work for any Z-Wave device that is having connection or configuration troubles. There will be potential fixes for all the issues that these steps address in the next big hub firmware release.

If these steps work for you, let me know. Thanks.



Have you actually set one of these enerwave motion PIRs up yourself?

I guess I have been gotten again. I tore down a working PIR, removed my custom DH and re-added it using this method.

No Dice. I can’t get past step 4 - it shows constant motion, tried the process 1/2 dozen times and same results. No, it is not defective the same units work fine with the custom DH.

I am very confused as to how this is listed as officially supported, and yet it seems to require voodoo and seances to get working. Even after doing that, I still can’t get it to work.

Back to the custom DH, which does work. Countless hours of back and forth.

I have 2 of these… I’ve had them on both hub1 and hub2. Yes they work on both, I did have to pair/exclude them several times to get them to work on hub v2. They seamed to pair better when close to the hub. No, I’m not using a custom devicetype, I’m using the default zwave motion device and it seams to work well after I got them paired. That part was frustrating.

When did you add them? Official support was announced Oct 20th.

Official support is for those who play by the rules or don’t want to do some serious homework before buying… :slight_smile: I have several devices that work that aren’t officially supported. In some cases I wrote a devicetype to make it work. According to Amazon I ordered them in July and been running them ever since.

Yes I have one. When I was writing those instructions, I added mine to my hub v2 using the instructions and it was successful. Then I tried adding it to my v1 at a large distance and had problems and had to reboot the hub before it would exclude. Then I added it to the v1 hub again using the instructions and was successful again.

I agree that it probably shouldn’t have been added to the supported list due to all the problems people have had. I got it working with our official Z-Wave Door/Window and Motion sensor device types many months ago, but I guess it just went through the SmartThings “certification” process recently and was deemed to be supported.

Thanks for the input and reply.

No luck here so far.

It is frustrating as all hell. It took me well over 50 plus excludes and pairs to get to work on the v2. Best I can say is to exclude the device reboot the hub and try the pairing process again. All so, it seemed that it was more successful when I inserted the batteries while holding the button on the back of the device. I hope it someone.


Sure, understood. I had mine before official support working as well.

Point is, what is the success rate of adding them with official support using the ST DH for them? And what processes are used… etc.

If you have to do so standing on one foot, whilest spinning about, and repeat 7 times until successful… it’s hard for me to fathom ST saying it’s a ‘Compatible Device’ no matter where the fault lies.

When you are on a custom DH with a device not listed by ST as compatible, as frustrating as that might be, it’s certainly not on ST.

Thought I would contribute my experience with it on v2.

Can’t say that I’ve had any issues; mine unpaired from the old and repaired to the new hub without any problems. It initially paired as my custom device type; I was going to move to the officially supported method but it worked fine as-is and the official method is just the generic handler (issues with that one is why I created the custom one). AFAIK the only functional difference is the generic handler doesn’t support the software-enabled test mode.

I only run one of these in my system; they proved to be too sensitive (even with dip adjustment) and my dogs constantly triggered it.

They are very sensitive, but they are very… unnoticeable. They blend in to typical homes. Where as the other PIRs really stick out which I don’t like. I overcame the sensitivity by using the stickers and or masking tape to reduce the input to the PIR. I may try fogging the lense of a test device with some sort of semi-transparent paint some day.

The reason why I wish to ultimately move to the ST official supported DH for these is that I want to ensure the apps and functions can run locally in the long run.