The Shelly app prevents the screen from turning off after the usual timeout (typically 30 s). The app will just stay open and the screen will stay on. Other apps work as expected and don't prevent/override the screen timeout. There is no specific setting to be found on Android to manage this behavior for a single app!

This is bad for several reasons:

• screen burn in (OLED)
• battery drain
• security (phone stays unlocked!)

Current version that I am using: 1.35.6/ecbe323

Perhaps this is expected behaviour, but for me at least, the Consuming meter is a bit misleading.

I have Solar panels (connected to a PM mini), and so when they generate power i can be in a situation where the meter shows feedback energy to the grid, but in reality the house is consuming from the grid.

I see that "Unknown" is not calculated towards the totalt meter, but there should be an option for it at least.

Now to see what the house actually consumes, I need to look at the "Grid Source" as the "Speedometer" removes the "Unknown" energy.

It also shows feedback energy as i said when solar is producing, so the Consuming meter is never correct (in my setup).

(Its correct in the sense that it shows all consuming devices in the system)

I understand that Grid meter would = Consuming speedometer, but that seems "correct" to me, if i want to know how much is not metered in the house i could see the "Unknown" field.

Perhaps add an additional "total" speedometer needle, so it has 2 parts (2 indicator needles that combine), 1 part that is the "metered" from all devices and 1 part of the meter is the "Unknown".

That would be really clear (for me at least) and the meter would show "correct" values.

Add solar >90W  to the total (not in screenshot) then it would show producing, even though the house is consuming.

And in this image, consumption is 395,5W, not 90W.

Thoughts?

TL;DR: Regional outage for control.shelly.cloud in San Francisco bay area. Works from some other geographies.

I was trying to set up a new Shelly device starting yesterday and when opening the Shelly app on Android, I get the message "Shelly failed to load. Make sure you have stable internet connection and enough storage space!". I then tried opening on a desktop computer https://control.shelly.cloud and get a text "404 Not found" error. I'm in the San Francisco bay area. When I VPN into a service based in San Francisco, CA and then try again, I get the same result. If I then VPN into a service in New Zealand, the page then loads fine. This says to me control.shelly.cloud served from Google in the San Francisco bay area is misconfigured.

It looks like control.shelly.cloud is served from Google on Anycast address 34.95.90.149. Shelly, please can you look into your cloud infrastructure on GCS in us-west2. Thanks!

Our client did file a claim for a pristine device…

CT type can be set with WebUI (only).

The device cards show V but the Main controls mini graph and the charts tab show C as the Y axis  

Firmwares all up to date

Description:  
After moving a Shelly H&T Gen3 from its original room to a newly created room, the (new) room widget in the dashboard does not display temperature or humidity values. The device itself continues to report measurements correctly, and values are visible in the device detail page (as well as the device widget)

Steps to reproduce:
1. Add a Shelly H&T Gen3 to Room A (initial setup).
2. Add the Room A widget to the dashboard → temperature/humidity display correctly.
3. Create a new Room B.
4. Move the H&T Gen3 from Room A to Room B (via device settings).
5. Add the Room B widget to the dashboard.

Observed behavior:
- The Room B widget shows no temperature or humidity.
- The device page (as well as the device widget) shows correct, regularly updated values.
- Removing and re-adding the Room B widget does not fix the issue.

Additional tests performed:
- Moving the device back to Room A restores correct temperature display in Room A widget.
- Moving it again to Room B results in missing values again (in Room B widget).
- Creating a second new room (Room C) and moving the device there leads to the same issue: the Room C widget also does not display temperature/humidity.
- The device continues to report measurements correctly throughout (no connectivity or reporting issues).

Expected behavior:
- The room widget should display temperature and humidity from the device currently assigned to that room.
- Moving a device between rooms should update the data source for the room widget accordingly.

Notes / Hypothesis:
Binding/cache issue where the room widget remains linked to the original room assignment or fails to correctly reassign the “main sensor” after moving the device?

Impact:
Prevents using room-based widgets reliably when reorganizing devices across rooms.

Workarounds tried (unsuccessful):
- Removing and re-adding room widgets
- Waiting for multiple reporting cycles (over several weeks)
- Creating new rooms and reassigning the device

Please let me know if additional logs or diagnostics are needed.

I'm experiencing a calibration issue with my Shelly Pro Dimmer 2PM (SPDM-002PE01EU) 
since firmware 1.7.x that I cannot resolve.

Setup:
- Device: Shelly Pro Dimmer 2PM (SPDM-002PE01EU)
- Firmware: 1.7.4 (20260120-145253/1.7.4-gf9878b6)
- Load: 6x GU10 LED 8W = 48W total, wired in parallel
- Shelly Bypass installed in parallel on the output

Problem:
Every calibration attempt fails with:
"Calibration aborted because the lights are not dimmable"

The same LEDs worked correctly with a Shelly Dimmer 2 (Gen1) on the 
same wiring. On/off control works fine via RPC (Light.Set?id=0&on=true). 
Only brightness control is blocked because calibration never completes.

Any RPC command with brightness parameter returns:
code -109 / "Precondition failed: Output not calibrated! 
Brightness and transition_duration are not allowed."

What I already tried:
- Installed Shelly Bypass in parallel → calibration still fails
- Verified parallel wiring (not series) → correct
- Total load 48W well above minimum threshold → correct
- Firmware is latest stable 1.7.4

Questions:
1. Is there a known regression in 1.7.x regarding the calibration 
   algorithm for LED loads?
2. Is there an RPC parameter or config flag to force/skip calibration 
   and allow brightness control anyway?
3. Is there a way to downgrade to 1.4.x stable where calibration 
   was working correctly for similar setups?

Thanks

Dieser Bug betrifft die Version 3.74.0

Habe die Daten von der älteren Versiion 3.72.1 wiederhergestellt, und dort funktioniert alles. - Leider passiert das Update auf 3.74.0 nach einigen Neustarts des Shelly Apps automatisch, und lässt sich nicht verhindern. - Somit liegt es eindeutig an der Version 3.74.0

Bitte um schnelle Korrektur dieses Problems, und ein Update, wo dieses Problem behoben ist.

Danke!

Seit kurzem wird beim Shelly 1 Gen 3 sowie dem Shelly 1 mini Gen3 das Passwort am selben Gerät nicht mehr richtig gespeichert.

(Die "alten" Shelly 1 Geräte sind nicht davon betroffen)

Sobald das App > 1 Stunde geschlossen ist, wird beim nächsten mal betätigen des Schalters das Device Passwort erneut verlangt. - Das Shelly schaltet zwar trotzdem in dem Moment für 1x, danach ist es "gesperrt", sofern man das PW nicht erneut eingibt. Nach erneuter Eingabe funktioniert dann wieder alles für eine kurze Zeit. Stunden Später das selbe Problem!

Habe bereits die Daten ge-wiped (gelöscht), und mich frisch ins neue App eingeloggt. - Problem bleibt bestehen.

Bin auf iOS 15.4.1 iPhone 12 Pro.

Ich denke, dass es sich hierbei um einen neuen Bug handelt.

Edit:

Auch nach dem Downgrade des iOS Apps (war 1.4.4) auf eine ältere 1.3.x Version, hat sich oben rechts die Nummer 3.111.11 nicht geändert.

Ich denke also, die Version dargestellt retchts oben 3.111.11 betrifft ausschließlich die Shelly Cloud, richtig? - Hat also mit der iOS App Version selbst nichts zu tun.

Der Fehler reproduziert sich auch auf einem anderen iPhone 11 Pro, mit dem selben Account angemeldet:  Nach einer gewissen Zeit kommt bei jedem Device (nur die Gen3 von Shelly 1, auch die Mini) ständig die Passwort Abfrage! - Habe auch schon versucht, das Passwort im Browser eingeloggt unter Settings / Authentication (Enable password protected device) zu ändern und neu zu speichern - Hat nichts gebracht.

But on my wife's iPhone 12, iOS 26.3.1, and iPad Pro iPad OS 26.3.1, it stopped to work a few days ago. The App dashboard could not be completely loaded. It first appeared and lasted only 2-3 seconds and quickly dissappered, only a black screen. Because of the black screen, nothing can be done there, I could not verify the App version, but I think it must be 3.7.5 as the auto-update is on. If I go to iPhone App Store, my App, it shows Shelly Smart Ct ontrol, under What's new > it shows Version 1.8.1, 2w ago. But I don't think this is App version, it might be the installer version, as it is also shown as 1.8.1 on my working iphone Shelley App 3.7.5.  Remove App, re-install it did not help. It is strange. The bug only affect her iPhone/iPad, but not mine. 

Br, Fang

When Create new script view is open is normally do changes and clic on save and restart the script

Now isnt anymore possible to do changes becourse there is a "shadow" script behind and all changes gone on wrong row

Odd thing is that original script working but no changes possible

Changes can be made by AP on the device but thats not a easy way: All AP:s closed and a 60km drive for by car to do weekly changes= No thanks

It seems not to be a operativesystem issue either, asked about this on a finnish forum and it seems to be similar for others too

Attachment picture added where is clearly shown:

I am having a bit of trouble reproducing this bug, but this happened over 5 times now.

All matter communication with my Home Assistant stops, and the device shows offline in the Matter integration. A reboot of the Shelly 1 Gen4 via the still running webinterface solves this state.

This is somehow triggered by a sequence of restarting Accesspoints / Coordinator and Router, as it seems to occur after I do upgrades to my network equipment. (But not every time, and tested with rebooting them manual and this does not seem to trigger it)  So somehow I meed a specific set f conditions where the Matter implementation does not recover from after reconnecting to WiFi when everything is up again.

For me it is a small inconvenience, and maybe fixable in new firmware

only desconected from wifi and using móbile data the app allows control over the relax.

with wifi I can see every single device, and read voltage, power/ etc 

When the light is on and you change the input that is configured as Switch, the OFF position is not detected.

When the light is off the switch input does detect on and off states as expected.

1.7.99-dimmerg4-prod1
Firmware ID: 20251013-122859/g39113ed

Web build ID: 250826171419-ccd53470

Device: Shelly BLU H&T Display ZB (SBHT-103C)

Description:

The Shelly BLU H&T Display ZB has a built-in ambient light sensor (XYC ALS1206) and reports light levels via BLE advertising using BTHome v2 protocol. However, the device uses Object ID 0x1E ("light" - binary sensor) to transmit the light value with 3 discrete levels (0=dark, 1=twilight, 2=bright).

According to the BTHome v2 specification (https://bthome.io/format/), Object ID 0x1E is defined as a binary sensor that only supports values 0 (off) and 1 (on). Using it with a value of 2 is outside the BTHome specification.

Problem:

This causes integration issues with home automation platforms like Home Assistant:

• When using BTHome integration natively, the sensor is interpreted as a binary sensor (on/off), the value "2" (bright) is not properly handled
• When using a BLE-to-MQTT gateway script, the light field is not recognized as an illuminance measurement and requires custom handling
• The 3-level approach (dark/twilight/bright) does not match any standard BTHome Object ID

Expected behavior:

The device should use one of the following approaches, in order of preference:

1. Use Object ID 0x05 (illuminance) with the actual lux value from the ALS1206 sensor. The device already has configurable dark/bright thresholds (characteristics c1a32099-...841 and c1a32099-...842 with default values 50 and 500 corresponding to ~1 lux), suggesting the hardware provides actual lux readings. Transmitting the raw lux value would give users maximum flexibility and full BTHome compliance.
2. Use Object ID 0x05 (illuminance) with mapped approximate lux values (e.g. 0 lux for dark, 50 lux for twilight, 500 lux for bright), based on the configured thresholds. This would at least provide a BTHome-compliant illuminance sensor.
3. If the 3-level discrete approach must be kept, use a more appropriate Object ID such as 0x3A (button/selector) or a custom enum sensor, rather than misusing the binary sensor Object ID 0x1E.

Current BTHome beacon payload:

ID 0x00 (pid)         - uint8
ID 0x01 (battery %)   - uint8
ID 0x1E (light)       - uint8  ← should be 0x05 (illuminance)
ID 0x2E (humidity %)   - uint8
ID 0x45 (temperature)  - int16

Firmware version: Latest available as of February 2026

Documentation reference: https://shelly-api-docs.shelly.cloud/docs-ble/Devices/BLU_ZB/ht_display/

I am using multiple different Shelly devices and they are all affected. I am also using the Alexa integration (which I was asked to disable the last time).

Unfortunately after the update each time the device starts it tries to calibrate lights that are not dimmable. In the previous version it was simply failing once and marking the light as non dimmable which was perfect for me. Now in the new version it tries to calibrate automatically each time the device starts and blinks which is quite annoying. On top of that on a Ikea led strip it manages to calibrate where it shouldn't and because of that the light is not able to work normally (it blinks and is not usable at all).

Is it possible to rollback to a 1.4.x ? I have 8 dimmer and only 3 lights are not dimmable so I've updated all of them before finding the issue...

Unfortunately, the measurements are cumulative for graphs when devices are set to the same device type, e.g., Cooling. Can I disable the type designation so that the device is not displayed in the Energy by Device Type window?

PS. I have a Shelly Pro EM 50 as the main meter, so it's only a submeter.

So, I always have to reenter the password when changing anything because the password is not saved in the app either.

I would propose to just keep the existing password. The MQTT.SetConfig call does exactly that when omitting the "pass" field. 

That means: a file will be created, but not as a .csv-file !

Although csv files are created, the content is not properly readable by Excel.

See example file (exported today).

gesamtenergie_overall_consumption_26_01_2026_00h__02_02_2026_00h.csv