Announcement

Collapse
No announcement yet.

Shelly Dimmer/ Alexa

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

    #16
    If a Z-wave device better fits your needs then go for it.

    Shelly devices fit a niche where the faceplate does not need to be change while smart control is achieved. My house has Almond faceplates on switches and plugs and the only dimmers that are available of which I am aware are White. If there was better disclosure by HST of what the interface requirements are for Alexa/Google then others will have a better chance of supporting the community.

    The lighting technology I have installed at my house is UPB and I have been able to provide Alexa control of these devices with HS. My requirements, however, are only ON and OFF and have never tried to do dimming via voice. I have supplemented UPB lighting with WiFi. In all cases my WiFi devices use Tasmota firmware and this firmware already understands Alexa commands so I am not dependent up HST for their voice control.

    AlexBK also provides a plugin to interface with Shelly devices. He may have other information that I do not have for Alexa/Google voice integration. It is a general question of how any device can be dimmed via Alexa and not dependent upon WiFi or Shelly.

    Another approach is to submit a ticket to HST to know what the criteria is for ability to dim a light via voice command.

    Comment


      #17
      Sorry for the delay, it's been a busy week. I did some testing with the attached build, but not much has changed. It's still the same, the "best result" is a device showing as on/off + color in google home when I enable voice control and google discovery for the parent device.
      I can also see that whenever I change color (doesn't matter which) through Google Home app, there is a log message "Device: shellies Obývák Brightness to (value)% (0) by/from: CAPI Control Handler" so HS clearly merges ison and brightness features into a single device, but incorrectly.

      Comment


        #18
        I also opened a support ticket, describing my findings, but I'm only getting generic responses like.
        I recommend suggesting that the plugin developer reach out to our developer resources.

        https://docs.homeseer.com/display/HSPI
        The plugin author will likely need to change how these devices are created for them to work properly in Google Home, I've included a link to our plugin SDK below:

        https://docs.homeseer.com/display/HSPI
        So not much help.

        Comment


          #19
          I can submit a GitHub request. Did you try to ues the Is_Light setting that was added to the mcsMQTT MISC on the Edit tab?

          Comment


            #20
            Yes I did (and also the IS_DIMMABLE iirc) different combinations for the features. I'm back on the production version again, but if you'd like me to try out some specific combinations and write down details of the result in GH for your request, let me know.

            Comment


              #21
              Github issue #259 submitted with the following text.

              A user of a WiFi Bulb interfaced via mcsMQTT was created with a HS Device with two features. One with ON/OFF buttons. One with a Slider for brightness control. Slider range is 0 to 100. ON/OFF single values of 0 and 1.
              MISC settings set for Google Discovery, Alexa Discovery, Voice Control. Also tried with Is_Light MISC setting in both states.

              User is able to request the ON/OFF feature via voice and the light responds. User attempts to control dimmer/sider/brightness via voice and no response including no setiomulti call to the plugin to act upon a brightness change.

              User submitted a support ticket and the ticket requested that the plugin developer submit a GitHub issue for support to identify the requirements for setting up a feature for controlling a light's brightness via voice.

              Comment


                #22
                Thanks for the ticket and sorry that I haven't figured it out before you had to post it.
                I played with the brightness feature a bit more and I think I was able to fix the issue after all. I was still thinking about the reason why the light is showing as a color light and I found out that on the feature Status/Graphics page there is a Control Use column. In my case there there was for some reason "ColorControl". I'm not sure where this value came from, I don't remember changing it, but it can be just my bad memory. Could you check if it isn't a default value by any chance?

                So I changed it to "Dim" and synced my device with Google Home. The light changed to a dimmable light in GH, however the dimming had no effect in HS. Turned out that the start value of the control has to be 1 instead of 0, otherwise every change in GH dimming level leads to "Device: shellies Obývák Brightness to (value)% (0) by/from: CAPI Control Handler". My guess here is that the GH/HS assumes that the dimming range is 0-1 (0.5 being 50 %) and every value gets floored to 0 int (just a guess). However when I changed the brightness in HS, the GH slider changed correctly.

                TLDR: If I configure Status/Graphics like in this picture (Range: 1-100, Control Use: Dim), the dimming and On/Off control from Google Home works as expected.Click image for larger version  Name:	Screenshot 2022-02-17 at 7.21.32.png Views:	0 Size:	22.7 KB ID:	1527721
                Voice control and discovery is enabled on the root device.
                Attached Files

                Comment


                  #23
                  Good investigation!

                  What happens if you put the lower limit to be 0.1 rather than 1.0?

                  What happens with your current configuration when Shelly returns a 0 for brightness?

                  I had set the controluse to ColorControl. I will change it. It may have been done when using a slider for Hue, Saturation and Brightness.

                  Comment


                    #24
                    Got a response. First guess is that a device cannot have overlaping feature values.
                    This may be an issue of overlapping values.
                    The 0 and 1 for on/off are also in the dimming range.
                    Even though they are on different features, they are both grouped under one device.
                    My first suggestion is to set the on/off to 0/100 and set the dimming range to 2/99, then rediscover.
                    If this doesn't resolve your issue we will look into it further for you.
                    Rather than following the above suggestion, can you change the Off to be -2. On to be -1 and Slider to be 0 to 100 using the following steps.
                    1. Go the MQTT Page, Association tab and click on the Ref button of the ON/OFF device. In the VSP section toward the bottom.
                    1a. Click the Clear VSP button
                    1b. In the text box enter (without quotes) "false=-1;off;off"
                    1c. 1b. In the text box enter (without quotes) "true=-2;on;on" to get as below
                    Click image for larger version  Name:	Capture2.JPG Views:	0 Size:	25.8 KB ID:	1527861

                    2. Go to HS Devices or /deviceutility page and view the Status/Graphics property of the ON/OFF device. You should observe the -1 and -2 values for the two control states. Edit the controlUse property to be On and Off rather than Dim.

                    Click image for larger version  Name:	Capture3.JPG Views:	0 Size:	27.8 KB ID:	1527862

                    3. Go to HS Devices or /deviceutility page and view the Status/Graphics property of the Brightness device.
                    3a. Change controlUse to Dim
                    3b. Change the control range to 0 to 100
                    3c. Optionally change the graphics range with minimum of 0 and maximum of 100

                    Click image for larger version  Name:	Capture4.JPG Views:	0 Size:	79.5 KB ID:	1527863

                    Rediscover or whatever you do for Google voice and see if expected operation is achieved.

                    My objective of this test is to know what I need to do automatically in the plugin.

                    Comment

                    Working...
                    X