Nope : -) , an arduino uno with an ethernet shield (central setup) and a sonoff rf bridge as a complementary gateway.
Both with Openmqttgateway.
The described solution, magnet and reed switch, is a good one.
In my case, I use a micro-switch. The switch’s lever protrudes into the base of the hole where the deadbolt slides into. When the deadbolt is extended, it pushes the micro-switch’s lever.
The sole advantage is the deadbolt needs no modification (no magnet is required). The main disadvantage is it’s more difficult to install and conceal the micro-switch (it’s much larger than a reed switch). In comparison, it’s easier to install, and conceal, a reed switch.
Anyway, I have two door locks monitored this way (for about ten years now). The doors also have contact sensors. The combination of the two sensors allows me to confirm that a door is closed and locked.
1 Like
Yes, they will send “on” or “off” messages to HA (where “on” is open and “off” is closed). They work great, I get notified immediately when the door opens on my iphone (you’ll have to set an automation for that obviously) and apparently the battery will last very long (and they are cheap at IKEA which sits at 5 minutes away from me).
They are cheap, are easy to pair, easy to install and easy to work with. Oh and I forgot to mention, they don’t look horrible and they are small which can be important to you (you can choose between rounded mija ones or squared aqara ones, the aqara ones are newer and supposedly better, but I haven’t found a difference yet)
+1 for the xiaomi sensors. I had the sonoff rf bridge with the 433Mhz door sensors and they weren’t reliable for me.
Completely agree. I’ve been using 5 of these for over a year, haven’t even needed to change any batteries yet. 100% reliable with the OpenMQTTGateway bridge.
Since this I have tested a new one, this digoo :
it can compete easily with the gs-wds07, moreover it is delivered with a lithium battery which has a lower self discharge rate compared to alkaline ones.
Here is more infos about it :
2 Likes
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 …
2 Likes
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?