Announcement

Collapse
No announcement yet.

Shelly Door / Window

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Shelly Door / Window

    The Shelly Door / Window sensor contains the typical capabilities of a typical Door / Window sensor which is event reporting when the reed relay moves away from the companion magnet.. Beyond this, it contains an accelerometer that it uses to report events of tilt and vibration as well as a lux sensor. Being a WiFi device on battery power its response time will be marginally slower than something like a wired, X10 RF, Zigbee or wired Z-wave sensor since it needs to wake up on the event and make a WiFi connection through the local Access Point.

    Click image for larger version

Name:	dw.png
Views:	575
Size:	42.0 KB
ID:	1400540
    Click image for larger version

Name:	dw2.png
Views:	369
Size:	170.8 KB
ID:	1400541

    Shelly has elected to make their case a little larger to hold two CR123 batteries which gives them of up to two years before changing the pair. Typically battery operated sensors of this type claim up to one year of life, but then only one battery needs to be replaced.

    Since it also contains an accelerometer it has the potential to be employed in other applications beyond the typical door or window installations. Xiaomi sells both a Zigbee door/window and Zigbee vibration sensor, but not a unit that contains both. Xiaomi's vibration sensor does have firmware that reports a wider range of accelerometer outputs, but for most this difference will not matter. The lux sensor also opens ups other uses, but likely not practical as a lux-only devece, but could be useful in combination with the other sensors.

    mcsShelly and mcsMQTT recognize this device and automatically create HS devices using default settings. Additional settings are available for personalized customization. These can be found at https://shelly-api-docs.shelly.cloud...indow-settings. The ones of interest are shown below along with example of use that was extracted from the mcsShelly manual.


    Assuming that the IP of the Shelly Door/Window is 192.168.0.123 (yours will be different) these settings can be applied using a browser with URL set with examples shown below. The red font is what will be the parts that you need to customize.


    http://192.168.0.123/settings?tilt_enabled=true&vibration_enabled=false

    Table 23 Shelly Door/Window Settings
    dark_threshold number Illumination definition for "dark" in lux, 0..100000 and must be lower than twilight_threshold
    twilight_threshold number Illumination definition for "dusk" in lux, 0..100000 and must be greater than dark_threshold
    dark_url string Set URL to invoke when luminance <= dark_threshold
    twilight_url string Set URL to invoke when luminance > dark_threshold AND luminance <= twilight_threshold
    close_url string Set URL to invoke on close
    vibration_url string Set URL to invoke on vibration detection
    led_status_disable bool Enable/disable status LED
    sleep_mode_period number Periodic update period in hours, 1..24
    reverse_open_close bool Reverse which position the sensor consideres "open"
    tilt_enabled bool Enable/disable tilt detection
    vibration_enabled bool Enable/disable vibration detection

    #2
    How can I use the GUI to build an event that is conditional on the 'open' / 'closed' status? In HS4 if I have an event that triggers relative to time. I want a conditional (Shelly door sensor is 'closed'). However the only conditional options seem to be device values, not device strings. I unsuccessfully tried to change the mqtt association in order to change device value instead of device text.

    As one work-around, I've tried to add a virtual device as a feature to the parent device, but I can't figure out how to add a feature. I can make an entirely separate device with a virtual device feature, but that seems really excessive.

    Comment


      #3
      Since you are using mcsMQTT for other things there is no advantage of also using mcsShelly. mcsMQTT will do everything mcsShelly will do. mcsShelly is just a restricted mcsMQTT for those who only want Shelly support.

      In any case the Open and Close status are based upon the VSP settings for the feature. Closed is normally 0 and Open is normally 1 so your event triggers will be on a value of 0 or 1.

      You can confirm this by looking at the HS Device or deviceutility page, Status/Graphics and the relationship between the number, text and the graphic icon.

      Comment


        #4
        Thanks for the response. Indeed I made a mistake posting here since I'm not using mcsShelly, as I was focused on the sensor.
        Test events do not trigger with changes in device value 0 or 1 for the state feature. Perhaps this sensor didn't get setup correctly? The icons were never correct, and I've messed around trying to make sense of things. The image below is the current Status/Graphics window. This doesn't show the relationship I think you are expecting. This is the second DWsensor I've setup with similar results.
        Attached Files

        Comment


          #5
          I look into it tomorrow. It is one of the new devices released by Shelly.

          Comment


            #6
            I can see that in your case you have a shellydw2 rather than a shellydw.

            The Shelly API defines the following for the Door Window sensor without distinction between model 1 or model 2. When I send messages of this format then the Devices and Features are created as shown in the original post of this thread and then VSP will also be setup for the open/close statuses.
            Code:
            [LIST][*]shellies/shellydw-<deviceid>/sensor/state: door/window sensor state open or close[*]shellies/shellydw-<deviceid>/sensor/tilt: tilt in °, 0..180[*]shellies/shellydw-<deviceid>/sensor/vibration: 0 - no vibration, 1 - vibration detected[*]shellies/shellydw-<deviceid>/sensor/lux: luminance level in lux[*]shellies/shellydw-<deviceid>/sensor/battery: battery level in %[/LIST]
            What I will need is the MQTT message that is being sent by the unit. It is likely the same as the shellydw, but I would rather have real data rather than my guess. You can capture this message if you have mcsMQTT History enabled on General tab and related checkboxes such as below. There are also other tools such as MQTT Explorer that will allow the MQTT traffic capture.

            Click image for larger version

Name:	Capture.PNG
Views:	371
Size:	24.9 KB
ID:	1435683

            Comment


              #7
              Attached is some history. This is from the debug log. Also is a screen cap from mqtt explorer
              Attached Files

              Comment


                #8
                Good set of data

                temperature and illumination are new and will be mapped directly to HS devices

                error and act_reasons are also new, but I do not see a reason to map the HS device but leave them stagged in Association table. Do you agree?

                Comment


                  #9
                  I did implement as proposed in#8. HS4 at http://mcsSprinklers.com/HSPI_mcsMQTT_5_9_4_0.zip. HS3/HS4 at http://mcsSprinklers.com/mcsMQTT_5_9_4_0.zip

                  remove your exists topics and devices with this topic using General Tab, Inbound Managment, Obsolete row with shellies/shellydw2/#. After the sensor publishes again you should see the following.


                  Click image for larger version  Name:	Capture.PNG Views:	0 Size:	177.9 KB ID:	1435976Click image for larger version  Name:	Capture1.PNG Views:	0 Size:	69.0 KB ID:	1435977

                  Comment


                    #10
                    Agree regarding error and act_reasons . Thanks for the update, again!

                    Comment


                      #11
                      All looks good. Devices were created, and now 'open' and 'closed' show up as trigger values (and changes trigger events). There was an error in the HS log, but it doesn't affect functionality that I've seen. 290 is the parent device for the newly created shelly dw2
                      Error while updating device 290 property StatusGraphics : Do not set StatusGraphics directly

                      Comment


                        #12
                        Thanks for pointing this out. I do not look at the log very often. HS4 does not provide a means that I could find to associate an icon with a device so I tried t force it and clearly it did not let me. I removed the attempt to prevent the log message for the next update. Agree that the message had no functional impact.

                        Comment

                        Working...
                        X