Shelly erratic behaviour, turning itself off

Hardware
1

Anyone with shelly (dimmer) devices seeing weird behaviour like this ?

I have written an appdaemon app that changes the brightness of a shelly bulb according to some criteria that is out of scope here.

The problem at hand is when I change the BRI from x to y on the shelly bulb then it decides to turn itself off for a few seconds or so and then turn itself back on with the expected new brightness value.

This only happens periodically :frowning:

Today I witnessed it first hand.

appdaemon app logs:

	2021-02-25 10:24:54.823219 dimmable light   light.bathroom_spots found at bri=234
	2021-02-25 10:24:54.908820 adjusting light 'light.bathroom_spots' to bri level='245'
	2021-02-25 10:24:55.660187 on_light_turned_off called.  old='on',   new='off',  attrib='state',       entity='light.bathroom_spots'	
	2021-02-25 10:24:55.684743 on_light_brightness_changed. old='234',  new='None', attrib='brightness',  entity='light.bathroom_spots'
	2021-02-25 10:24:57.270723 on_light_brightness_changed. old='None', new='244',  attrib='brightness',  entity='light.bathroom_spots'
	2021-02-25 10:24:58.631870 on_light_turned_on called.   old='off',  new='on',   attrib='state',       entity='light.bathroom_spots'

So I intially log the current BRI level of the shelly dimmer 2 bulb, which is 234
Then I call : await self.call_service(“light/turn_on”, entity_id = ‘light.bathroom_spots’, brightness=244)
obviously in order to set the BRI level to 244

this results in the bulb visually turning itself off for a few seconds, then only to turn it on again and settle for BRI=244.
all this happens within a few seconds

This can be seen in the logs as well.

I’m using a shelly dimmer 2 with beta FW 20210122-155640/v1.10.0-rc1@00eeaa9b
cloud turned off.
using shellyforhass integration vers. 0.2.2 beta 2
is it a CoAP bug ? if then where? in shelly codebase or in shellyforhass ?

Is MQTT any better I wonder ?
Or maybe the bultin integration in hass ?

2

Did that event reset the uptime counter on the device?

3

No… it didnt.
Its still on 16 hrs.
Happened a few hours ago.

4

happened again today.

I then immediately looked in the local web UI of the shelly and it stated in RED
“ERROR1”

querying the device using the API =>
http://shelly-bathroom/status

=>

{"wifi_sta":{"connected":true,"ssid":"enkegaard","ip":"192.168.1.120","rssi":-70},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"17:18","unixtime":1614269883,"serial":1580,"has_update":true,"mac":"F4CFA2E114AA","cfg_changed_cnt":1,"actions_stats":{"skipped":0},"lights":[{"ison":false,"source":"http","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":3}],"meters":[{"power":0.00,"overpower":0.00,"is_valid":true, "timestamp":1614273483,"counters":[0.000, 25.794, 20.556],"total":6394}],"inputs":[{"input":0,"event":"S","event_cnt":39},{"input":0,"event":"","event_cnt":0}],"tmp":{"tC":47.31,"tF":117.16, "is_valid":true},"calibrated":true,"calib_progress":0,"calib_status":0,"wire_mode":1,"overtemperature":false,"loaderror":1,"overpower":false,"debug":0,"update":{"status":"pending","has_update":true,"new_version":"20210115-103951/v1.9.4@e2732e05","old_version":"20210122-155640/v1.10.0-rc1@00eeaa9b"},"ram_total":48768,"ram_free":36140,"fs_size":233681,"fs_free":115460,"uptime":71592}

here we see loaderror = 1, a shame I cant see this as an attrib. within hass as it would be begging for some monitoring :slight_smile:

I’m not too excited about this shelly dimmer 2 device as you can tell.

But I think this explains it.

5

Look out for fw. 1.9.6 as this seemed to fix this issue for me.
Ill post here if anything changes for the worse.

6

Ironically the only device I tried to install the beta 1.10 on got bricked in the process, some devices I have with 1.9.4 are a lot more stable, except one which spontaneously rebooted for no apparent reason.
Is there a changelog for 1.9.6 ?

7

I don’t know if it’s related, but there are a lot of disconnection issues being reported on the Shelly support forum at the moment. See here for thread, here for a form to fill in (account needed).

My two Shelly 1s were given me problems by disconnecting, often permanently, immediately after operating the physical switch: I tried firmware upgrades and ended up bricking both. Eventually, an FTDI flash to ESPHome (with one of these) has revived both and they work perfectly now.

8

I quote:

Dimmer2 - 1.9.7 firmware is released and it’s very important to update your dimmer to it.

There is few very important changes:

1. Autodetect load type and set correct setting. This function is enable by default and check what kind of load to you have, how to control it correct.

2. Calibration improvements: We work hard to improve calibration for all type of loads no matter neutral is present or no. Now calibration first do Autodetect load and then calibrate device. After firmware update you should make it, old calibration will be deleted. When you make a calibration another logic starts testing it in the leading and trailing edge. Analyzes where there are peak, deviations, calculates how to control the pear with minimal heat release and adjusts the correct settings.

3. Safety: Full protection! This firmware take 20 000 samples from device every second and analyze them for problems. if it notices a deviation from the expected current and voltage behavior for 5 seconds, try to correct it and if can’t, turn off the light and show error message. The message also can ask to start new calibration or switch edge if you have disabled Autodetect load. It’s my personal work last month as a project manager and little bit a developer. Full protection cannot be disabled and work even Autodetect load type is disabled. There is 3 level of protection: Overcurrent peak protection - which analyze every singe peak is it on the expected range and what cause it. Wrong calibration/edge protection - checking all the time are the connected load generate initial peaks in the set edge, are the load is changed with new one which need new calibration. Adaptive Overtemperature protection, now is working not only by value but also by curve of temperature change. If this protection is activated, device is switch off and cannot be switch one before cool down.

There is no functions added or removed. I have list for small know bugs reported from some customers and they will be fixed with 1.10, but all of them are not related with safety.

Update your devices and enjoy!