Note that in term of power consumption the new Digoo beats all the others I have seen before.
I have added power consumptions measurements in the comparative spreadsheet:
The current consumption is measured with current ranger from lowpowerlab much more accurate compared to my multimeter …
so assuming the GS-WDS07, as it operate on 433MHz will happily work with the Sonoff RF Bridge.
like the fact that it sends dif codes on open and close, def places it better option than the sonoff then.
How do you access/configure them,
Can they be Tasmotized (and if will they still send dif codes on open and close) ?
G
I didn’t tested it with Tasmota but with OpenMQTTGateway. With OMG it works with ZgatewayRF (esp32 and esp8266) and with ZgatewaySRFB (sonoff rf bridge).
I think they should work with tasmota also.
Nevertheless my recommended door sensor now is the new digoo.
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
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. 
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:
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 
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? 
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.
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!
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?