Do you use a fake (assumed state) template switch?
I’m not confident the motion/vibration sensor will fit with the standard setup. It’s a bit hard for me to tell with my setup. It may fit if you put it like the picture below, but it may be very tight or mess with the outside key functionality? You may need to cut back the right side of the red thing? Or you could try dissembling the sensor casing to make it smaller? But the sensors are cool and I’m sure you’ll find another use if it doesn’t fit. So get one and play?
Either way, it still isn’t detecting ‘locked’. I’m working on some ideas for that. I’ll report back in my main post as it progresses…
Yes, my plan was to use a template switch.
Yes when the sensor fires an event counter clockwise (for the model left), you just assume that the door is locked (if you pair it with a classic open/close door sensor, when the door is closed AND fires the event counter clockwise, then the result should be almost totally accurate).
That was basically the plan. It’s hard for me to explain, but the sensor can’t detect any ‘locked’ movement (Counter clockwise for me). If you look at my charts, it only shows “locked” events (each “pairs” of events are for one “locked” command) . The long pause between the lock rotation ending and the ‘return to normal’ motion starting the makes it register. There are “unlocked” events that happened, but you can not see them. The short pause for unlock between the turning movement and returning to normal state means nothing is captured. It sees no change…
I do have a vibration sensor, but the developer_tools/events is not working (not showing anything when I put the sensor event_id), works only when is empty and start listening, but I have hundreds of events, can’t read the log-
If its not working puting the sensor vertically, I guess the only other way is to check if it works mounting it horizintally, although its a bit ugly mounted like that
I tried to use this new Xiaomi sensor and I think it’s not possible. The sensor doesn’t have gyroscope so detecting rotation is very limited and unaccurate. I think that better solution is to use Xiaomi Door sensor. This sensor without shell fits perfect inside Sherlock key holder (I changed battery to bigger one):
and outside:
The very last rotation on lock and unlock event are different. I use Node-RED to detect time differences between last open-close event of Xiaomi Door Sensor and it works perfect for me.
Oh cool! This looks promising. I think I am close to a solution with the motion/vibration sensor though, but the door sensors are cheaper and smaller, so if they can be used, then that could be better.
My newer concept for my vibration sensor implementation I was exploring wasn’t really fruitful, so I’m just fiddling a bit with my implementation of your door sensor implementation.
One aesthetic tip (if you prefer), is that you can swap out the smaller sensor with another subtler looking (and even smaller) magnet. I tested with a few I had around and it worked fine. I guess smaller ones like in my photo could even fit on the inside, instead of outside like yours? Not sure if the super magnets I tested could interfere with the Sherlock though?
I would prefer not to use node red for the time difference logic, so if you or other have ideas for that, then that would be awesome. I think I have some ideas for how. I’ll test soon.
Hi, I don’t get it how that is working, the position of the reed switch and the magnet is always the same even when rotating, what’s the trigger …?
I’m guessing the rotation of the internal reed switch is enough to switch it from ‘closed’ to ‘open’. They need to be quite aligned…
The trigger of a Xiaomi door sensor is when the reed switch and the magnet move apart (open) or move closer (close).
With the rotation of the handle they both rotate together, so there is no trigger … I do not understand
mmhhh ok, I see, that can work, The switch will then go crazy on/off/on/off multiple times before landing to a fix position. If the sequence of on/off is different between lock/unlock that can work.
I wish to see the code how to realize that, unfortunately I do not use node-red (I did in the past but was for me an aggravation for maintaining it)
This working for me with the reed switch. No node red required…
Have two automations like this in your automation file.
- id: '1755' alias: Smart door unlocked trigger: platform: state entity_id: binary_sensor.door_window_sensor_158d0001bf8643 from: 'off' to: 'on' for: seconds: 1 action: - service: notify.google_assistant data_template: message: "unlock" - id: '1756' alias: Smart door locked trigger: platform: state entity_id: binary_sensor.door_window_sensor_158d0001bf8643 from: 'off' to: 'on' action: - service: notify.google_assistant data_template: message: "locked"
Put a template switch in your config.
switch:
- platform: template
switches:
smartlock:
friendly_name: "smartlock"
value_template: "{{states.automation.smart_door_locked.attributes.last_triggered > states.automation.smart_door_unlocked.attributes.last_triggered }} "
turn_on:
service: script.locked
turn_off:
service: script.unlocked
For a unlock motion (longer) while both are triggered, the unlocked automation is triggered after the locked one, so looking at which was last triggered seems to get you a decent state indicator.
Note that I’m not really doing anything just yet with the switch template services, they are basically dummies. You don’t need the notifications either, they’re for my testing. I’ll report back later with reliability and consolidated solution.
1 Like
BTW instead of that ugly (IMO) white magnet, you can use a normal (thin) magnet (maybe even the magnet inside the plastic enclosure, never opened it though), paint it in black with a marker, attach it with 3M adhesive, and will be almost invisible
works perfectly for me, thanks mate!
1 Like
To understand first position of door sensor (let’s say when is unlocked) the binary_sensor has to be OFF (magnet away from reed) or ON (magnet near reed)?
I think you could do it a few ways. But I think it is best that when the lock is in its “resting state”, the door sensor is “closed” (near).
The lock state is basically inferred from the length of time that the sensor “is not closed” when it changes from closed to open, rather than the specific sensor state.
@ahzazou , @michel72 & @Klagio .
I’m about to get started on the hacked bluetooth button modification to complete my solution.
I would prefer to just wire it into my pi (don’t use a esp8266), but I understand this isn’t reliable.
So the esp8266 is the best option (with 10k resistor)?
Could you guys please comment on reliability you are achieving and confirm what you think is the best solution?
Yes that’s my experience: with the pi would work 50% of the time. With an ESP8266 its more 95% of the time. Remember to use a proper (equal or more then) 2A+ power supply for the ESP8266.
I recommend to use @ahzazou code or ESPhome. For ESPhome is this (you will need to change switch into lock somehow (I didn’t do it yet), its a bit better in the sense that it gives you also WiFi Signal strength and you can get notified if the ESP8266 disconnects from WiFi (with an automation, I did not do yet), and you can play, if you like, with ESP8266 LED, and you can make changes OTA.
esphome:
name: 12_door
platform: ESP8266
board: nodemcuv2
wifi:
ssid: "xx"
password: "xx"
manual_ip:
static_ip: 192.168.1.xx
gateway: 192.168.1.yy
subnet: 255.255.255.0
# Enable logging
logger:
# Enable Home Assistant API
api:
ota:
web_server:
port: 80
switch:
- platform: gpio
pin:
number: D0
inverted: yes
id: relay
- platform: template
name: "close_12_home_door"
icon: "mdi:gate"
turn_on_action:
- switch.turn_on: relay
- delay: 500ms
- switch.turn_off: relay
- platform: template
name: "open_12_home_door"
icon: "mdi:gate"
turn_on_action:
- switch.turn_on: relay
- delay: 500ms
- switch.turn_off: relay
- delay: 100ms
- switch.turn_on: relay
- delay: 500ms
- switch.turn_off: relay
sensor:
- platform: wifi_signal
name: "12 BLE Bridge WiFi Signal"
update_interval: 60s
- platform: uptime
name: "12 BLE Bridge Uptime"
text_sensor:
- platform: version
name: "12 ble bridge ESPHome Version"
1 Like