Shelly Dimmer

[Michael McSharry]

The Shelly dimmer provides PWM control to alter the energy provided to a single load (e.g. white bulb) thus effecting a dimmer function. It also provided absolute on/off control, power utilization measurement, device temperature measurement and monitoring for overload conditions. It is not able to control inductive loads such as a fan.

It has provisions for two mains-level inputs that are designed for use as local switch inputs. Note that these are not digital level inputs. Theses switches can be wired in various ways to achive different switch control characteristics as shown below.



Additional settings are available per https://shelly-api-docs.shelly.cloud...er-sl-settings and shown below. To change a setting a browser is used with the URL set of the IP Shelly device and parameter to be changed such as below for a Shelly Dimmer at IP 192.168.0.123. Those parameters that are user-defined as shown in red.

http://[COLOR=#FF0000]192.168.0.123[/COLOR]/settings?fade_rate=[COLOR=#FF0000]2[/COLOR]
http://[COLOR=#FF0000]192.168.0.123[/COLOR]/settings?fade_rate=[COLOR=#FF0000]2[/COLOR]&transition=[COLOR=#FF0000]2000[/COLOR]

pulse_mode	number	1 - Leading Edge Dimming, 2 - Trailing Edge Dimming
calibrate	number	0 - Delete calibration, 1 - Start calibration
calibrate_cancel	number	1 - Cancel calibration
transition	number	Transition time for on/off: 0..5000 ms
fade_rate	number	Brightness change speed when button is pressed: 1..5

Settings can also be set interactively by using browser and navigating to the IP of the Shelly Dimmer such as http://192.168.0.123.

The Shelly Dimmer also supports a night mode. When night mode is active, turning ON the device during the set interval it will only go up to the pre-set brightness limit.. The night mode enabled with a setting as well as the time bounds and alternate brightness level. For the start and end times to be useful the timezone also needs to be setup. While all of these can be done using browser URL, it is easier to navigate to the Shelly Dimmer URL such as http://192.168.0.123. If done problematically then the following are examples.

http://[COLOR=#FF0000]192.168.0.123[/COLOR]/settings_nightmode?enabled=[COLOR=#FF0000]1[/COLOR]
http://[COLOR=#FF0000]192.168.0.123[/COLOR]/settings_nightmode?enabled=[COLOR=#FF0000]1[/COLOR]&brightness=[COLOR=#FF0000]40[/COLOR]

enabled	boolean	Flag to enable/disable night mode
start_time	boolean	Start time in format hh:mm
end_time	boolean	End time in format hh:mm
brightness	number	Night mode brightness in percent

In addition there are settings available for how the load (bulb) behaves. These can be controlled as shown below or interactively such as http://192.168.0.123.

http://[COLOR=#FF0000]192.168.0.123[/COLOR]/settings/light/0?default_state=[COLOR=#ff0000]last[/COLOR]
http://[COLOR=#FF0000]192.168.0.123[/COLOR]/settings/light/0?default_state=[COLOR=#ff0000]last[/COLOR]&btn_type=[COLOR=#ff0000]edge[/COLOR]

reset	any	Perform settings reset
default_state	string	Default power-on state, one of on, off, last, switch
auto_on	number	Default timer to turn the dimmer ON after every OFF command in seconds
auto_off	number	Default timer to turn the dimmer OFF after every ON command in seconds
schedule	bool	Enable scheduling timer
schedule_rules	array of strings	String values for sheduling in ir format see description below
btn_type	string	Input type: one of one_button, dual_button, toglle, edge ot detached
swap_inputs	bool	Swap inputs
btn1_on_url	string	URL to access when SW1 input is activated
btn1_off_url	string	URL to access when SW1 input is deactivated
btn2_on_url	string	URL to access when SW2 input is activated
btn2_off_url	string	URL to access when SW2 input is deactivated
out_on_url	string	URL to access when output is activated
out_off_url	string	URL to access when output is deactivated

Use of this device is only appropriate in situations for controlling mains-level voltages. This is for both switch inputs and output loads. Digital level input and output are not supported. As mentioned above it cannot be used for inductive loads such as a fan.

Interestingly the device supports a night mode with different behaviors, but it does not provide a MQTT endpoint that shows if it is currently in day or night mode. I suppose one can look at the power level or brightness level and infer if in night mode or not if one needs to know.

Note also that it reports temperature in both F and C units. Likely you will only want one of these showing in HS. While it can be deleted as a HS device, it is better to keep the plugin and HS in sync to uncheck the "a" column checkbox for the temperature reading that is not to be shown.

For simple timer functions to change something at a given time of day and day or week the Shelly Dimmer has a built in event engine. It is most easily setup from the URL of the Shelly dimmer. The result is similar to setting up events in HS, but this is all local and does not involve HS. It only needs an internet connection so Shelly can get time update from NTP server.

[devoir]

most excellent work

Devoir

[Michael McSharry]

In the process of integrating a rate device into Shelly RGBW2, Bulb and Dimmer I observe an undesired behavior with the Dimmer. I did not go back to see if it existed with the others.

The scenario is that brightness was set to, for example, 14%. The dimmer was then commanded to OFF. The brightness was then commanded to 0. The device was commanded On and it used the 14% brightness level for the desire brightness. It reported this brightness even though the command was 0 when turned on. This resulted in the flashing of the light followed by the desired ramp from 0 to the new desire brightness.

I did not observe the light flashing for the RGBW2 or Bulb, but I also did not look at the status feedback immediately after transition to On.

More investigation is needed to better understand why the Dimmer is behaving this way and if it applies to the entire Shelly family.

[chrisgla]

Hi Michael,

Thanks for the Pl!

Bought a few Shelly devices to try- dimmer updated to latest FW 20200309-104554/v1.6.0@43056d58 with HS3 latest.

Something silly is going on with my MQTT/ HV device mappings- some of the HV devices are stale since installation a few days ago and mapped to generic "shellies/shellydimmer-D3EFB2/announce" topic

For instance power I have a HV device on "shellies/shellydimmer-D3EFB2/announce" but power is actually reported on Sub: shellies/shellydimmer-D3EFB2/light/0/power

Enclosed screenshots might help explain better- the device was discovered 17th March, "today" values are those which are updating.

I'm starting to understand the mappings in MQTT table and tried deleting all topics, disabling MQTT on device and re-enabling to re-learn topics. HV devices are re-creating as I associate in MQTT table but not the device type, grouping, etc

Is there a way to re-initialise the Shelly learn process- or a more graceful way to re-create without manually amending each sub-device?

Thanks!

[Michael McSharry]

The devices should not be created on the /announce topic as was shown in one of the images for device 304. The other image for device 307 looks to be correct topic. I am not familiar with your HS3 Device Management column 5 where the topics are shown. What is the column title for it?

There should be manual edits required. What needs to be understood is why the shellies/shellydimmer-xyz/announce topic even exists. You should not have too much invested in the plugin setup yet so I suggest starting over. On the MQTT page, General Tab, Inbound Subscription Management section, Obsolete topic row enter shellies/# in the text box. This will delete the record of all shelly devices and will delete the HS devices that were associated with them. Also enable the debug checkbox which is toward the top of the General tab. Observe the HS devices were deleted and manually delete them if not. Good to restart the plugin to make certain everything is clean (note last paragraph about using current plugin file).

Recycle power on the Shelly Dimmer. The devices will be created upon first observation of the device reporting. Announce topics are expected as shellies/announce/ not as shellies/shellydimmer-xyz/announce. The debug will contain the received topics. The debug file is in \Data\mcsShelly folder as a .txt file. It can be posted or emailed to mcsSolutions at CenturyTel dot net.

I have been working with ramp device in the plugin and nearly done. Use this version that is attached so I can better support using the current source code. Unzip the file to the \bin\mcsShelly folder of HS. The version number viewed from HS will not change as this is a supporting file and not the main file for the plugin.

[Michael McSharry]

After a good night’s sleep I looked at your debug and did see the initial message from Shelly included the /announce/ topic for status. This is the issue. I filtered them out as the plugin has the information built-in. The update is at http://mcsSprinklers.com/mcsShelly_5_2_1_3.zip for HS3 and http://mcsSprinklers.com/HSPI_mcsShelly_5_2_1_3.zip for HS4.

The same process should be followed to remove existing mcsShelly records and get to the point of no HS devices for the dimmer exist. This time the /announce/ devices will not be created for status and the real status device created instead.

I will need to try to update the firmware on my dimmer as yours is different than mine.

[chrisgla]

Thanks Michael- working fine now. Only thing I noted with the dimmer is input status devices weren't created automatically, they are with the dual switch- but I'm starting to grips with the MQTT table now and added.

[Michael McSharry]

I see that I had excluded it thinking it was the state which I already had as IsOn and not the switch input. I'm surprised you were able to add it manually. I did fix it with the version that is now in the updater. To have it discovered automatically there cannot have been a prior discovery so all the dimmer topics would first need to be made obsolete as was done in the prior iteration. No need to do this if you are good with how the input is being handled.