No announcement yet.

Shelly RGBW2 (Color Mode for Light Strips and RGB lights)

  • Filter
  • Time
  • Show
Clear All
new posts

    Shelly RGBW2 (Color Mode for Light Strips and RGB lights)

    Click image for larger version  Name:	Capture.PNG Views:	0 Size:	21.5 KB ID:	1368878
    The Shelly RGBW2 is a WiFi device that is able to use Pulse Width Modulation (PWM) to provide color and dimming control of up to four channels of lighting. This is typically Red, Green, Blue and White. Common applications are dumb LED light strips and RGB LED lamps. Price point is in the neighborhood of $25.

    Its total drive capability is 3.75 amps per channel which is most significant when determining the length of LED strips that one unit will be able to drive. For 12VDC LEDS this will be typically be a strip of up to eight meters. Twice the length for 24V LEDs.

    Note that smart LED strips that have individually addressable LEDs (e.g. WS2812B) will not use the RGBW2, but just a simple micro controller discrete output for their control. Where the RGBW2 shines is a replacement for other RGBW controllers such as magichome, HUE, or LIFX which are either expensive or more difficult to control without using the cloud.

    Typical of PWM dimmers there is a tendency to observe flicker when the gain (brightness) is at low levels. For some this will not be noticeable. Color space also tends to loose quality at lower intensities. This is not unique to the RGBW2, but common for the technology.

    The RGBW2 also contains a mains-level input that will typically be connected to the switch input that exists in the J-Box where dumb lighting is made smart with the RGBW2. The RGBW2, as most Shelly products are small and can usually be installed behind the switch without too much difficulty in the J-Box.

    A typical wiring diagram for a LED strip or color bulb is shown below.
    Click image for larger version  Name:	Capture2.PNG Views:	0 Size:	89.7 KB ID:	1368879 discrete output.

    The RGBW2 operates in two modes. One is Color and one is White. This discussion covers the Color mode. The HS devices that are created for the RGBW2 in Color mode are shown below. Properties reported to HS include the brightness (gain), power consumption, on/off status, RBG and White color level, special effect and indication of a overpower condition. Also reported is the online status which is maintained in a separate group dedicated for Shelly online status.

    Click image for larger version  Name:	Capture3.PNG Views:	0 Size:	80.4 KB ID:	1368880
    Unlike the Shelly color bulb, the RGBW2 configuration of the mode is via the settings in the App or URL to the IP of the web server running in the RGBW2. Assuming that the IP of the RGBW2 is then setting the mode to color is done from a browser with URL shown below. The IP shown in red will be different for each user's install.

    The other setting available is the voltage of the power supply being used. It is a true/false setting for 24V vs. 12V power supply source as shown below.
    mode string Set to color or white; determines the operating mode
    dcpower bool Set to true for 24 V power supply, false for 12 V
    Defining both settings would be done like below where 12V is selected in this example.

    The other settings apply only to the Color mode. These have the URL path of /settings/color/0 with the options shown below:
    reset string Any non-zero-length value will reset light settings to default
    effect number Applies an effect, see description below
    default_state string Sets default power-on state: on, off or last
    auto_on number Sets a default timer to turn ON after every OFF command in seconds
    auto_off number Sets a default timer to turn OFF after every ON command in seconds
    btn_type string Input type: momentary, toggle, edge or detached
    btn_reverse bool Whether to invert external switch input
    schedule bool Enable schedule timer
    schedule_rules array of strings Rules for schedule activation, e.g. 0000-0123456-on
    Supported values for effect are:
    • 1 - Meteor shower
    • 2 - Gradual change
    • 3 - Breath
    • 4 - Flash
    • 5 - Gradual On/Off
    • 6 - Red/Green change
    An example use would be the following to restore the output to the sate that existed before power loss and the input being a toggle.

    While any of the six effects can be commanded from the browser URL, the effect is also setup as a HS device so controlling the HS device via Device Management, Script, or Event will be the normal way to change the effect. If one is into effects then the WLED project may be of interest as it has a much richer set of effects and can be used in more elaborate lighting schemes such as those synced to music or for seasonal lighting pizzazz. http://<a href="</a>

    I performed the same evaluation with the RGBW2 as was done with the Shelly color bulb for the purpose of ramping at a user defined rate to a target brightness level. In this case with the Generic LED strip I used for evaluation a very good continuous response was achieved at all brightness levels. The only quantization observed in 1% increments was under 5%. There were no dropouts.

    As a side note I observed the RGBW2 had fewer special effects vs. the Bulb. The on/off ramp effect was not available for the RGBW2. Since the user-defined ramp rate works well with RGBW2 there is not much need for it.

    in the next plugin update I will include the rate HS device for the Shelly devices that have a brightness control.

    What I have in my evaluation is a ramp at power on and a ramp when user changes brightness level. I did not ramp brightness when turning the device off. Any opinions on this being the desired implementation?

    It is possible to change the target brightness when the LEDs are off and in this case the brightness will ramp to the new target when they are turned on.

    if the Shelly has been configured to restore power-down state upon application of power the plugin will not ramp the brightness as this was due to an external power event and not a user action. The same is true if the physical switch was used to affect the on/off state. The Shelly will immediately restore the target brightness.


      Appreciation all your work on this.

      my Shellys came today, just waiting on the power supply (should be here Friday). 100 plus feet of RGB plus cool white for the home theater.


        I completed the integration of the rate device for RGBW2, Dimmer and Bulb. It works well for the first two and the Bulb has some issues with respect to certain color/brightness combinations resulting in no output from the Bulb. During integration I also some cleanup that was needed on the original implementation.

        The HS3/HS4 version of the plugin is at HSPI_MCSSHELLY.exe goes into the HS folder. mcsMQTT_2020.dll goes into the \bin\mcsShelly folder.

        I will update the HS4 pluign in the next day or two. I will wait for some feedback to confirm operation is as desired before I submit update to Updater(s).


          The HS4 version of the plugin was updated to add the ramp rate devices.



            Thanks for all your work!! I'm trying to get the input status of the RGBW2 (it to know if the connected switch is on or off). The plugin installed great and the RGBW2 controller setup was a breeze and devices were created, but not for the input status. I actually don't need any of the devices created for the RGBW2 other than the input status. Any way to do that? I have been trying to manually create an HS device to update with the RGBW2 input status. When I go to http://ip/status I get:

            I was reviewing the MQTT documentation from Shelly and it doesn't look like the MQTT pushes include changes to the input status (switch changes), but it is not clear to me. I also can't find the input status anywhere in the MQTT history either. Can it be manually included? If not, is there a way to poll the ip/status URL and parse it out of that every 3 seconds or something?



              I never noticed before, but there is nothing in the Shelly documentation about exposing the AC Switch input state. Either via MQTT or HTTP. It looks to be GPIO5. I did confirm that the /status endpoint delivered the "input" with a value of 0 or 1 depending upon the ground vs open state of the input. I can add a polling function to support the input. The downside is that there is latency for status change based upon the polling rate.

              Why use the RGBW2 in all you need is the input? The Shelly 1 has the same form factor and does push the input state changes.


                I've been using and abusing these Shelly devices, they are just so awesome. I use the dimming channel pins to control LED strips, simple motor controllers, and I also need a contact closure input, all in the same location (my various chicken sheds). One channel opens/closes the chicken shed door, another channel turns on LEDs during the day so the chickens have more light in the winter (more light = more egg output), and the input is tied to a simple little single throw switch which gets flicked on/off as the door opens and closes, reporting that nothing got in the way from the door actually closing or opening (ie freezing, chicken gunk build up, etc, rare but it happens). I could use the dual relay module as well, and I thought about it, they both would work in this scenario, but the rgbw2 gives me more flexibility for dimming the LED strips and more channels if I want (motor, LED in the coop, LED strip in the pen, who knows maybe more later?).

                These bloody chickens are going to be the death of me.... but Homeseer makes it more tolerable. It looks like one of my other plugins has status polling built in that I hadn't noticed before. It's probably on a 3 second timer or something, but that is just fine for my needs, a little delay won't slow me up one bit. I'll work that side and see how this weekend goes....


                  I have updated to HS3 mcsShelly plugin to add the polling input for the RGBW2. It is at HSPI_MCSSHELLY.exe goes in the HS folder. mcsMQTT_2020.dll goes in the \bin\mcsShelly folder.

                  After making the update, for the new input device to be created you will need to mark the existing RGBW2 devices as obsolete. This is done from the MQTT page, Association tab, "O" column. After checking each then the column title will contain a button to remove them. It only needs to be done for the topics that have associated HS devices. It can be more easily done done from the General tab of MQTT page, Inbound Management section, Obsolete Topics row by entering shellies/shellyrgbw2-123456 where "123456" is changed to the specific id of the device. After this then power cycle the RGBW2 so it report again.


                    I uploaded the HS4 version of the plugin and updated both to create the new endpoint for the Input status if it does not exists. It means you do not need to go through the dance described in post #9 to mark existing devices as obsolete. With all that is needed is a power cycle on the RGBW2 so it will generate an announce message.



                      I have another post I made in the support thread as the Plugin does not show up as installed when I use HS3 Plugin Manager. So that is one issue.

                      I do have my ShellyRGBW2 showing up now in HS3. Question...How does a person VOICE Command it? I can't seem to find a way to say "Hey Google, Turn on Test LED" (I have set the voice command line for ON/OFF to be Test LED and I also checked the Voice Command box.

                      Just wondering if this is at all even possible. Thank you kindly.


                        Smart speaker skill is provided by HS. It enables the skill for the devices that have the auto voice property set. For mcsMQTT/mcsShelly devices this checkbox is on the MQTT page, Edit tab of the device. Clicking on the Association tab ref button on the device,s row will get you there or entering the ref number of the device on the edit tab will get you there.


                          Michael, have you considered adding a long fade feature? So, fading up or down over 5 minutes or something?


                            I believe it already exist as the Rate device. You specify the transition time in the device and when brightness changes it will change slowly over the rate specified.


                              Good Afternoon,

                              Thank you for all the hard work in getting this device to work with HS.

                              I have a quick question about building events that change the LED strip color. Seems I am presented with an unalterable list containing strings of positive or negative numbers of up to 10 digits. Does this seem right? I suppose I was expecting to provide Hex or RGB values for colors. I know in the control that user-provided hex is converted to a number like this but the event builder only contains a drop down populated with values.

                              I am beginning to think I have a config issue. Please let me know if that's true and I'll chase it down; I just don't want to chase my tail forever.

                              Thanks !