Best door sensors as of April 2019?

I use these, all work very well with OMG. I prefer the WDS-07 over the Digoo ones myself, but they both have 2 codes, on and off.

The motion sensors work very well, only one code though however. Easy to use an automation or time reset to tell HA no motion. They have a 6 second time between sensing motion again, so I have a 1.5sec reset time on them.

Get a good quality 9v battery and they will last at least 9 mths in a high traffic area.

https://www.gearbest.com/access-control/pp_593451.html?wid=1433363

Hi @tom_l, you mean the rcswitch protocol number ?

I did. But it does not matter now. I’ve gone off the idea of 433MHz sensors.

I have these digoo door/ window sensors. I have them combined with a sonoff rf bridge flashed with tasmota.

I however am not seeing 100% consistent rf codes being returned therefore sometimes my sensor doesn’t change state as it should.

EG my yaml:

  - platform: mqtt
    name: "French Doors"
    state_topic: "tele/sonoffrf/RESULT"
    value_template: '{{value_json.RfReceived.Data}}'
    payload_on: '01CE63'
    payload_off: '01CE69'
    qos: 1

90% of the time this works well. But everynow and again I see a slightly different code returned eg:

tele/sonoffrf/RESULT {“RfReceived”:{“Sync”:13010,“Low”:450,“High”:1260,“Data”:“01CE69”,“RfKey”:“None”}}
tele/sonoffrf/RESULT {“RfReceived”:{“Sync”:13080,“Low”:440,“High”:1270,“Data”:“01CC63”,“RfKey”:“None”}}
tele/sonoffrf/RESULT {“RfReceived”:{“Sync”:11320,“Low”:440,“High”:1270,“Data”:“00E711”,“RfKey”:“None”}}

This different/ rogue/ more random data key doesn’t match my yaml and therefore my sensor misses the event. As I am using these devices in a security use-case this isn’t great…

Anyone else seeing this?

Any ideas how to stabilise?

Trux

Some arrived here today, and yes I do to but in my very limited testing only when they are first activated.

Also does anyone know what the ‘tamper’ code looks like? It seems to be the same as the ‘open’ code on mine.

Finally, the Digoo website says that when the battery is low it sends a code. I don’t suppose anyone knows what that one looks like do they?

If 00E711 is an alias for the door-open state, you can use the following configuration to handle it:

- platform: mqtt
  name: 'French Doors'
  state_topic: 'tele/RF_Bridge/RESULT'
  value_template: >-
    {% if value_json.RfReceived.Data == '01CE63' or value_json.RfReceived.Data == '00E711'%}
      {{'ON'}}
    {% elif value_json.RfReceived.Data == '01CE69' %}
      {{'OFF'}}
    {% else %}
      {{states('binary_sensor.french_doors') | upper}}
    {% endif %}
  device_class: door

This is an adapted version of Strategy #1 from here: Sonoff RF Bridge. Strategies for receiving data. It also eliminates the warning message “No matching key found for entity” when your version of the door sensor receives a payload it’s unable to match (to either payload_on or payload_off).

How do you know it is an alias for the door open state? Is there something obvious I am missing, is it an educated guess because it come after the door close state or is there some relationship between the codes? And in any case why would there be an alias?

These sensors are sold as part of a whole system, how would the proprietary receiver know about the aliases? That’s half rhetorical because how would you know what is going on in the Digoo receiver?

And (again probably rhetorical) how do we know when we have catered for all the possible aliases?

I might just stick with my existing GS-WDS07 sensors which don’t look as nice and are sometimes a little temperamental with sending closed states (unless of course they too have some alias that I don’t know about so don’t cater for!).

That’s a lot of questions that I can’t answer because my statement was based on a hypothetical:

If 00E711 is an ...
^
|
|
This important word here.

My only goal was to show how to handle more than two received payloads.

Whoops…
I completely missed those two little letters…

Sorry. :blush:

If you use the Xiaomi Aqara sensor, with Zigbee, do you need a Xiaomi hub then? Or is the USB Zigbee stick enough?

I have made a detailled comparison about the 2 best choices at this time:

1 Like

Thanks for that. I actually use the GS-WDS07 sensors but then got a couple of the Digoo ones to try out as I was getting a few occasions where they weren’t sending the closed signal. For some reason that seems to have become much rarer recently so I haven’t actually changed any over.

In any case, that is not meant as a value judgement just a lead-in to my question :slight_smile:

I can find no reference anywhere to the WDS07 sensors sending a low battery signal. Can you confirm they do and that isn’t just a typo in the comparison? Also how does one discover what the low battery code is so that you can watch for it? :thinking:

Yes I can confirm that GS-WDS07 send low battery signal.

If you put an AAA battery with 1V you will get the low battery code.

2 Likes

Hi All,
I have noticed something with my GS-WDS07 transmitters.
They are labelled as working on 433 MHz.
Most of my other sensors work on 433.920 as the center frequency, there is scope to be a bit higher or lower than this at most receivers. (in using the Sonoff RF bridge)
My GS-WDS07 transmitters seem to transmit at 434.00 MHz, (some 80KHz higher than my receiver normally works at).
My GS-WDS07 are fitted with the SYN115 transmitter IC with a crystal marked at 13.560 KHz = 433.920MHz, however upon testing the Crystals in-operation I see that they are running at 13.5625KHz = 434.00MHz. (the Crystal is 2.5KHz too high)
So I’m not sure that I have the optimum setup here.
Yes, they are working, range is OK but I think could be better, add local interference from other devices on the correct frequency and it only gets worse.
Comments please radio hams!..
P

I

I know this thread has moved to focus on sonoff 433mhz based solutions, but after over 6months of running my system I have developed some experience with a handful of door sensors.

The most reliable for me have to be the ecolink zwave sensors. They always report open or close right away, have battery %, and as a bonus have screw terminals to easily add external red switch(es). After 6months, the lowest a123 battery of my ecolink door sensors (highest traffic door) reads 99% still (an ecolink motion is at 80%… still excellent!).

Second, I would have to give to xiaomi aquara. These are tiny, reliable, zigbee, and simple. The small size means a small 1620 battery, which is at 99% after 6months in a low traffic window. Not sure how that scales to heavy traffic, because this window rarely gets opened. That said, they are quite good, but 2nd place because not as reliable as the zwave ecolinks, and my application isn’t stretching the aquara to say it has ‘good’ battery life. If it appears to lasts as long as ecolink I have in other low traffic windows, I’ll report back (that could take years though… maybe I’ll experiment with my micro amp meter…).

3rd are my Visonic 340 sensors. These zigbee sensors are almost as cheap as the aquara, but they include a temp sensor and larger battery. The Visonic on my slider (medium traffic) is at 67% after 6months, which isn’t surprising since it polls temperature every 10 minutes (by default, but it is programmable). These sensors are otherwise reliable, but if battery life is an issue, maybe the temp sensor isn’t worth it?

My least favorite are my Aeotec recessed door sensors. You said no drilling (why? Drilled sensors always look best with stained doors) which rules these out. They are nearly invisible installed, which is why I still am putting up with the occasional missed state change. The missing state changes seem to happen randomly, more with lower batteries. I had one already need battery replacement. The other thing is they don’t report battery %. So you don’t know it needs replacement until it is dead. Maybe there is some zwave programmability that can make it report low battery, but I haven’t found it. Overall my experience with the recessed aotech gets an ‘avoid buying these’ rating due to missed states. They do look professional, but that will eventually wear out and I’ll be replacing them with ecolink or aquara.

Hope my $.02 helps you make a good choice!

4 Likes

I´m having a problem with one of such Digoo sensors: the value for de MQTT message is the same for open or closed state.
Any comments?

I’m already doing a similar route to what you imagined, so this is super helpful to run across!


But I think I can reuse the existing reed switch in this Wyze sensor.

The problem I run into is that the depth of the box my deadbolt strikeplate is attached to is exactly the right depth for the bolt itself. I may be able to glue a magnet to the end, but no means of putting the reed switch at the end of it, nor spring contacts given that the box itself is metal.

If you can tinker/solder, adding a remote wired Reed to any device is usually very easy. Just solder wires parallel to the stock Reed, and you are good to go. Ecolink has wire screws to make it even easier, but by no means is this trick limited to ecolink devices. A reed switch is a reed switch, and you dont even have to desolder the original as long as you keep it away from magnets.

On a side note… if you glue a magnet to the tip of the deadbolt, are you also drilling it a little to give clearance? I built my doors with pretty tight gap, and wouldn’t be able to do that without putting a blind hole in the bolt (otherwise the strike plate would knock the magnet off). I’m curious if putting it in a hole would reduce the magnet’s effective strength. I had similar issues when adding a reed to my metal breaker panel… the metal case made it where the reed had to be much closer to the magnet than normal for it to work (paramagnetic effects).

Interesting topic. I did the lock detection a little differently. I used two spring contacts screwed to the back of the cavity the dead bolt goes into. When locked, the deadbolt will connect them, closing the circuit. This is used like a normal binary switch. It’s a EU type dead bolt, which has different dimensions from the typical US ones, but the same principle applies. I’ve used this setup for a little over a year now and it works perfectly.

For the actual door open / close sensor I used the Aeotec Door / Window sensor 7. It’s very small and has been working flawlessly so far. I use the door and lock states extensively in my automations and also in my security system. I use exclusively ZWave devices for anything remotely security related. I don’t want to put the safety of my house (that’s the whole point behind a security system after all) in the hands of some cheapo $3 Chinese sensor that might or might not be reliable. Cheap 433 MHz stuff is fine for non-critical systems like lighting. But when it comes to things like doors or locks (or even climate control), it’s ZWave / Zigbee with certified and CE/FCC compliant devices all the way.

1 Like

Nice post, I’m sure it will encourage others with mortice type locksets to give it a go.

Regarding security of wireless devices, you may want to take zigbee off your list. Zigbee was shown to be vulnerable to remote exploits not long ago (~6mo or so IIRC, when the first article was published). The exploit can be done “down the street”, and can give the hacker full access to the rest of your HA device (by extension, possibly your network as well). Not sure if other hubs have patched this vulnerability. I don’t think HA has patched it yet; in fact I bet HA will be one of the last ones to get patched for that. Regardless, this is a big one for those using zigbee with alarm systems… sadly it was a deal breaker that forced me to replace 3 zigbee door/window sensors. I still use those on ‘non-critical’ stuff, but yeah never in places where security is a thing.

So really, that leaves us with just zwave or wifi for security type stuff (IMHO). Wifi of course won’t be useful for high traffic battery powered sensors for the most part. However if it plugs in or only sees occasional traffic, I usually prefer wifi over zwave (mainly for the price, an esphome device and do tons for much cheaper than zwave).