your image looks awesome,
I don’t think the OTA update is going to work for me as there are issues with the latest shelly fw.
I have 2 questions.
I removed the sticker on the inside,
but I can’t find a way to remove this screw
I checked with the original Shelly Plug S there is screwed from the other side using a philips screwdriver.
this Shelly Plus Plug S v2 it’s screwed from the inside, but the lines are so thin I can’t can a flat-blade to have any kind of grip.
I might can apply the power-drill to it, But I’m afraid I will never be able to remove the remains of the screw,
any advise would be helpful.
[Edit:] applying the power drill looses the screw, still there is no movement on the led ring. is this might be glued? or is there some outer mounting point I’m missing.
Is there any way to unbrick the v2 version? Im trying to unbrick it with esptool, and it gives this error.
You have to find the correct port.
Did you pull the transparent ring. Or pulled something else. From what I try there is no movement at all.
I hope to make a copy of the original firmware. So it might can be used to improve the ota update process.
so i have multiple open, the one im working on I cut the side of the plug near the circuit, but in the beginning, I pulled the transparent ring. What holds the transparent ring is a hollow cylinder of plastic that contains the screw.By removing the screw by drilling the head you can cut the cylinder from the inside with a knife or screw driver.I do not recommend removing plastic of the bottom part by force, you will break a fragile circuit component.
i fixed the problem(driver problem) but now im having a hard time with tx and rx.Having a hard time obtaning a stable connection. Had somting like that the first time but then it failed.
Here is the cmd of my atempt to flash esphome bin into the plug via serial.
C:\Users\migue\.esphome\.esphome\build\shelly-plus-plug-s-3\.pioenvs\shelly-plus-plug-s-3>python -m esptool --port COM4 write_flash -fs 1MB -fm dout 0x0 firmware-factory.bin
esptool.py v4.7.0
Serial port COM4
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
Chip is ESP32-U4WDH (revision v3.0)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: b0:b2:1c:18:fd:20
Uploading stub...
Running stub...
Stub running...
WARNING: Failed to communicate with the flash chip, read/write operations will fail. Try checking the chip connections or removing any other hardware connected to IOs.
Configuring flash size...
Flash will be erased from 0x00000000 to 0x000d0fff...
Compressed 855008 bytes to 531207...
Writing at 0x0000bd38... (6 %)Traceback (most recent call last):
File "C:\Python310\lib\site-packages\esptool\__init__.py", line 1139, in _main
main()
File "C:\Python310\lib\site-packages\esptool\__init__.py", line 923, in main
operation_func(esp, args)
File "C:\Python310\lib\site-packages\esptool\cmds.py", line 598, in write_flash
esp.flash_defl_block(block, seq, timeout=timeout)
File "C:\Python310\lib\site-packages\esptool\loader.py", line 131, in inner
return func(*args, **kwargs)
File "C:\Python310\lib\site-packages\esptool\loader.py", line 1077, in flash_defl_block
self.check_command(
File "C:\Python310\lib\site-packages\esptool\loader.py", line 467, in check_command
val, data = self.command(op, data, chk, timeout=timeout)
File "C:\Python310\lib\site-packages\esptool\loader.py", line 436, in command
p = self.read()
File "C:\Python310\lib\site-packages\esptool\loader.py", line 369, in read
return next(self._slip_reader)
StopIteration
A fatal error occurred: The chip stopped responding.
all info is in this thread, but not a step by step guide,
So I wrote down the step by step actions I took on my windows laptop
1. setup ubuntu vm on hyper-v
make sure you have enough diskspace 12BG is not enough 50GB is.
connect VM to your local network, not to the virtual switch
install openssh-server if desired
2. run the following line bij line and install all required stuff
https://esphome.io/guides/contributing.html#setting-up-development-environment
# Clone repos
git clone https://github.com/angelnu/esphome-1.git
# Install ESPHome
cd esphome-1/
script/setup
# Start a new feature branch
git checkout extend_ota
cd ..
3. create test.yaml
esphome:
name: test
platformio_options:
board_build.flash_mode: dio
esp32:
board: esp32doit-devkit-v1
framework:
type: esp-idf
platform_version: 6.4.0
version: 5.1.1
wifi:
id: wifiId
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: "${device_name}"
password: !secret wifi_password
ota:
unprotected_writes: True # This is mandatory if you want to flash the partition table or bootloader!
logger:
web_server:
button:
- platform: restart
name: Restart
4. compile to check if it builds and if upload-factory-ota at leas is available
cd esphome-1/
source venv/bin/activate
python -m esphome compile ../test.yaml
cp /home/bart/.esphome/build/test/.pioenvs/test/firmware.bin ~/firmware.bin
python -m esphome upload-factory-ota ../test.yaml
5. install tasmota according the the manual.
including migratation to the saveboot partition,
https://github.com/tasmota/mgos32-to-tasmota32
6. upload the firmware.bin using the browser on ubuntu.
7 upload factory ota
cd esphome-1/
source venv/bin/activate
python -m esphome upload-factory-ota ../test.yaml
8. now build a test.yaml from the HA addon and wireless update
just in case it helps someone
I have created a comprehensive step-by-step guide for flashing ESPHome onto the Shelly Plus Plug S (I had the V2 version) from the information accumulated in this thread.
Unfortunately the forum won’t let me post it, because it has too many links in it.
But it is available on my github. Feel free to add improvements!
Thanks a lot. That really helped a lot and for the first time my shelly plug works with bluetooth \o/
If someone has, please share working BLE configuration for Shelly Plus Plug S V2.
Because it’s has solo chip (1 core CPU) wrong configuration can brick it, so for V2 version which heavy to open it’s can be real nightmare.
Thanks in advance.
Specially i’m interesting for esp32 section which without BLE usually looks like:
esp32:
board: esp32doit-devkit-v1
framework:
type: esp-idf
But for solo chips and BLE configuration should looks something like described here and here
I have shelly plus PM mini, which also have single core esp and i’ve had to add “board_build.f_cpu” to my esphome part. Here’s my config:
esphome:
name: biodom-boiler
platformio_options:
board_build.f_cpu: 160000000L
esp32:
board: esp32doit-devkit-v1
framework:
type: esp-idf
sdkconfig_options:
CONFIG_FREERTOS_UNICORE: y
COMPILER_OPTIMIZATION_SIZE: y
advanced:
ignore_efuse_mac_crc: true
.....
Important line was “board_build.f_cpu”, without it my shelly was unresponsive - i’ve had to re-flash it via uart.
I’m not sure if that’s only thing you need, but i hope it helps.
Thanks for sharing! And in this config you have esp32_ble_tracker and it’s working?
I don’t have ble tracking on this device anymore, but, yes, it worked.
But, as said, without above lines esp didn’t run at all - it didn’t connect neither to wifi or HA and log on module’s Rx/tTx threw only some errors out (can’t remember what, though). I would guess that whole thing was compiled for 240MHz, while module, as it seems, runs on 160MHz.
Thanks for update! Will keep looking for Shelly Plus Plug S V2 config and if no one share it, will try your, hopefully it’s will work or at least not brick the plug 
I can confirm that Protoncek’s config works with esp32_ble_tracker: (active or passive) on the V2
@kadam12g your guide was great but please add a warning that esp32_ble_tracker: will cause a boot loop without additional measures like mentioned above.
A bit of thinking regarding this: perhaps line “board_build.f_cpu: 160000000L” wouldn’t be necesarry at all if i would choose correct board… i generally just copy/paste basic lines from a working yaml. Most of the time it works…
Some additional testing would be necesarry. I won’t be doing that right now since i have my mini nicely installed and if i brick it i’ll have to “dig it out”. Perhaps when i buy another one…
Thank you for the feedback! Could you confirm if this BLE bootloop issue is specific to this Shelly model? If it’s unique to this device, I’ll definitely add the warning. However, if it affects multiple ESP devices, I’d prefer to keep the guide focused on the core flashing process, while users can refer to ESPHome’s documentation or the forums for BLE-specific issues or configurations.
I flashed multiple Shelly Plus Plug S with @angelnu 's PR and mixed up my yaml files. In step 3. of this tutorial I uploaded a yaml with an ota password instead of unprotected_writes: True. When I try the upload-factory-ota I get the following error:
ERROR Transfering partition table is not supported by remote device - upgrade the firmware first!
If I try to upload a different yaml I get this error:
ERROR Error binary size: Error: device aborted flash that would have overriden running partition. Check your device log for more information.
The log on the esp shows:
11:08:01 [D] [ota:148]
Starting OTA Update from 192.168.0.20...
11:08:02 [W] [ota:383]
Remote closed connection
11:08:02 [W] [ota:239]
Auth: Reading cnonce failed!
11:08:02 [W] [ota:411]
Failed to write 1 bytes of data, errno: 104
11:09:43 [D] [ota:148]
Starting OTA Update from 192.168.0.20...
11:09:43 [I] [ota:464]
OTA type is 1 and size is 830704 bytes
11:09:43 [E] [ota:110]
Aborting to avoid overriding running partition
11:09:43 [E] [ota:111]
New partition - addr: 0x0e0000; size: 0x0cb000
11:09:43 [E] [ota:113]
Running partition - addr: 0x0e0000; size: 0x2a0000
11:09:43 [I] [ota:282]
PARTITION TABLE
11:09:43 [I] [ota:283]
===============
11:09:43 [I] [ota:287]
type: 0x01; subtype: 0x02; addr: 0x009000; size: 0x004000; label:
11:09:43 [I] [ota:287]
type: 0x01; subtype: 0x00; addr: 0x00d000; size: 0x002000; label: ota
11:09:43 [I] [ota:287]
type: 0x00; subtype: 0x00; addr: 0x010000; size: 0x0d0000; label: safe
11:09:43 [I] [ota:287]
type: 0x00; subtype: 0x10; addr: 0x0e0000; size: 0x2a0000; label:
11:09:43 [I] [ota:287]
type: 0x01; subtype: 0x82; addr: 0x380000; size: 0x080000; label:
11:09:43 [W] [component:214]
Component ota took a long time for an operation (0.08 s).
11:09:43 [W] [component:215]
Components should block for at most 20-30ms.
Is there any way to fix this or did I brick my device?