Shelly Wifi Door and Window Sensors Review

Hardware
1

Got 4 of these delivered today. Killed one. Just as well I only needed 3.

It’s way over priced for what it is and has some poor design choices. The Neo Coolcam / gocomma wifi door sensor is way better built and can be found for a quarter of the price of the Shelly but has no option for local control, only cloud. There are people working on this but it’s not ready yet. Also the quoted battery life of those devices is a lot less.

There is no indication of battery polarity in the battery compartment or in the manual for the Shelly. Connect them the wrong way and you will kill it. There is no reverse polarity protection.

FYI the folded battery contact is negative. The raised ring battery contact is positive

The reed switch component leads poke through the PCB interfering with battery insertion. Best to slide the battery up under these.

Also the PCB is covered in cyanoacrylate glue fume (white powdery looking fingerprint marks).

Connection and setup for local access was very straight forward,

  • Insert the batteries (the right way round)
  • Press the button
  • Connect to the device’s AP
  • Browse to 192.168.33.1
  • Set up WIFI connection
  • Reconnect
  • Update firmware
  • Set up MQTT (retain = true will allow HA to restart and get the device state while it is asleep rather than waiting for the next open/colse event).

It sends open and close messages but is a bit slow. About 10 seconds between opening or closing and the state updating in Home Assistant.

Good 3M double sided tape for fixing in place. Battery life promises to be excellent (2 years according to Shelly).

Binary sensor:

- platform: mqtt
  state_topic: "shellies/<device_id>/sensor/state"
  name: "Lounge Door"
  payload_on: 'open'
  payload_off: 'close'
  qos: 0
  device_class: door

Battery sensor:

- platform: mqtt
  name: "Lounge Door Battery"
  state_topic: "shellies/<device_id>/sensor/battery"
  value_template: '{{ value|round(0) }}'
  qos: 0
  device_class: battery

You can change the <device_id> to something more descriptive than Shelly-ABCDEF in the device mqtt settings.

I didn’t bother with a rest RSSI sensor (wifi signal strength) as it will be unavailable most of the time when the device is asleep.

The API document has not yet been updated for this device but you can see the available rest resources at <device_ip_address>/status when the device is awake.

They’ll do the job I need them for - preventing my aircon automations running when doors and windows are open - but I’m thinking twice about buying more to cover windows and doors for security.

5/10 stars.

Yes I know there are zigbee sensors, don’t mention them. I don’t want them interfering with my wifi.

3 Likes
2

Hi there,

Thanks for the review. I got mine today too, and honestly I was expecting more for its price. Is quite slow waking up (even with fixed IP it takes between 10 and 18 seconds to report) and when is up, is only up for about 5-8 seconds, so if you don’t push the button (which mentioned a lot in the manual, but is a bit hidden in the device, it took me a while until I saw it), you won’t probably have enough time to do anything with the device (like, I don’t know, things you will never do, like configure it, or upgrade it…).

Anyway, I got it for a garaje door where my Zigbee signal is poor, and I expect this to be more reliable than the Xiaomi Zigbee ones… will see.

Cheers

3

Good review, tutorial and thoughts all baked into one. :+1:

I can confirm I get similar response times between 8-11 seconds.

Polarity protection seems like something basic and perhaps was overlooked/time constraints on delivery.

Agree with the statement of expecting a bit more value out of it.

@okercho, I get pretty good performance out of my zigbee ones when paired with a phoscon/conbee usb but have good signal though. I am using the Shelley door/window for exactly the same reason you are (garage door) + out of range. Need some sort of easy zigbee repeater to sort it out I reckon

4

I’m testing since a few days ago using RPis as “extenders”, instead of ESPs, and I’ve found that it works much better. Now I’ve several RPis with the Zigbee USB Stick, sharing the port over TCP, and a central docker machine that runs several dockers, each one using the stick of a remote RPi, and works flawlessly.

Please note that in order to achieve this, I’ve several independent zigbee networks (running in different channels with different keys) over my house (basically, one network per floor), as I found it eaiser and more reliable than a big network (I’m using Zigbee2MQTT since the beginning, and it failed a lot for me in that moment with a big network with extenders).

Cheers

5

Have you tried https://github.com/StyraHem/ShellyForHASS?

6

Hi,

I got one shelly D/W too.
I’m also interested in illuminance, i’m able to get it through shellies/<device_id>/sensor/lux topic.

This is working pretty well. But the binary_sensor doesn’t get updated when device is asleep. Actually, the only way I found to wake it up is to open/close the door… (Which is a bit annoying :slight_smile:)

Do you think there is any way to wake it up ?

Thanks,

Thomas

7

Hi @tgermain,

I got one shelly D/W too and interested in getting illuminance.

My idea is to use illuminance when somebody opens the door, based on the value it gets from lux, it will choose to switch the light on, or do nothing.

Can you share a bit more of your sample?
I’m not getting the lux value at all. :frowning_face:

Thanks,
giosemmo

8

Hi,

I created a sensor like this:

- platform: mqtt
  name: "Shellydw xxx Lux"
  state_topic: "shellies/<device_id>/sensor/lux"
  value_template: '{{ value|round(0) }}'
  qos: 0
  device_class: illuminance

then the sensor is updated with the current lux.

Hope it helps

1 Like
9

Thanks man!

It worked. :wink:

1 Like
10

Do all of you have very slow response times?
And how do you connect to shelly? Mqtt, rest, cloud, shellyforhass,…?

Because i’m planning to buy a couple of them.

11

Yes, mqtt.

12

Yes, it is not immediate.

I usually have to wait 5 seconds, more or less.

Mine is connected via mqtt.

It’s acceptable in my case, I have just one on the apartment door.

13

Yeah when you use wifi and batteries (ie deepsleep), there is going to be added latency due to wifi authorization, and also dhcp if you don’t use a static ip. That can be a bummer for some automations. Zwave devices can fill the gaps here. For alarm use, something to think of is having 5sec of latency may be enough time for said burglar to hit the esp device with a hammer before the alarm gets triggered.

14

hi everyone, an update for Shelly Door / Window came out yesterday.
they finally implemented vibration and tilt.

Shelly Door/Window: MQTT

Taking inspiration from this topic I implemented the device as follows:

####################################################
#                                                  #
#                Shelly Door/Window                #
#                                                  #
####################################################

binary_sensor:
  - platform: mqtt
    state_topic: "shellies/shellydw-xxxxxx/sensor/state"
    name: "Shelly Door/Window Sensor"
    payload_on: 'open'
    payload_off: 'close'
    qos: 0
    device_class: door
  
  - platform: mqtt
    state_topic: "shellies/shellydw-xxxxxx/sensor/vibration"
    name: "Shelly Door/Window Vibration"
    payload_on: 'vibration detected'
    payload_off: 'no vibration'
    qos: 0
    device_class: vibration

sensor:
  - platform: mqtt
    name: "Shelly Door/Window Lux"
    state_topic: "shellies/shellydw-xxxxxx/sensor/lux"
    value_template: '{{ value|round(0) }}'
    qos: 0
    device_class: illuminance
    unit_of_measurement: 'lux'

  - platform: mqtt
    name: "Shelly Door/Window Battery"
    state_topic: "shellies/shellydw-xxxxxx/sensor/battery"
    value_template: '{{ value|round(0) }}'
    qos: 0
    device_class: battery
    unit_of_measurement: '%'

  - platform: mqtt
    name: "Shelly Door/Window Tilt"
    state_topic: "shellies/shellydw-xxxxxx/sensor/tilt"
    value_template: '{{ value|round(0) }}'
    qos: 0
    unit_of_measurement: '°'
    icon: mdi:angle-acute

everything seems to work except the vibration that is not detected even if from the interface via the schelly’s ip when I do the vibration test it works instead HA does not detect any status.
Could anyone try to see if this works for you?

binary_sensor: 
  - platform: mqtt
    state_topic: "shellies/shellydw-xxxxxx/sensor/vibration"
    name: "Shelly Door/Window Vibration"
    payload_on: 'vibration detected'
    payload_off: 'no vibration'
    qos: 0
    device_class: vibration

I don’t understand if I wrote something wrong or it’s a Shelly bug
Thanks

2 Likes
15

Any improvement in the delay between opening a door/window and it reporting its state?

Try this:

binary_sensor: 
  - platform: mqtt
    state_topic: "shellies/shellydw-xxxxxx/sensor/vibration"
    name: "Shelly Door/Window Vibration"
    payload_on: 1
    payload_off: 0
    qos: 0
    device_class: vibration
2 Likes
16

no indeed in my opinion and reading on shelly’s facebook page it seems that it is even worse than before.

I tried your solution but it doesn’t return any results equally maybe it’s Shelly’s problem

17

One last try:

    payload_on: '1' 
    payload_off: '0'
18

I just tried but even so it does not work … through the IP of the shelli displays the vibration instead of HA nothing … mah

19

Well the api reference definitely says 1 and 0 for the payload. And the topic looks correct.

Have you tried looking in your mqtt broker With mqtt explorer to see if the topic is correct (or if anything is actually being published for vibration).

20

I did not know this MQTT Explorer program … really done well, however after installing it, I triggered the vibration and returned the following message:

dw