Include bugfixes from PR #647

[dirstel]

In rstrouse#647 there are serveral bugs adressed. Unfortunatly it is quite a big PR changing lots parts. As I experience random crashes caused by the watchdog as mentioned here: rstrouse#535, the changes made here: rstrouse@c94819e#diff-f3f07c190c8475c561a758461a51df67a36886e6468db28d357b9cd04ce538c7R80 seem to be valuable. Please give this a try :)

[xkain]

Hi,
I haven't been able to reproduce this specific watchdog crash yet. However, to provide more 'breathing room' for the background tasks, I have increased the Watchdog timeout from 7s to 12s in the v2.5.0 released today.
Which specific ESP32 model are you using? How many shades/groups do you have configured in your setup?

Thanks for the feedback !

[dirstel]

I'm using an "oldschool" ESP32-Wroom and my Setup consists of 11 Shades in 2 Rooms (aka Floor in my Home) - so nothing special. I'll move on to your fork as soon as possible. As it's my productive setup this may take a while (Easter + some days off). I'm also thinking of moving to a smaller ESP32 (C3 or S3). But in order to keep as much parameters constant as possible, I'll stick to my old ESP32 for now.

[glich34]

Hello,
I know it is not your branch, but its original one.
Could be this log could help you.

I can help to test if you would like.

BR
glich

Serial_ESP32_SOMFYRTS_RSTROUSE_2.4.7_logs.txt

[xkain]

Hi,

Thanks for the feedback and the log. I’ve just Pre-released v2.6.0, which includes changes aimed at improving stability, specifically regarding the watchdog issues and random crashes.

Your help with testing would be greatly appreciated! Which board are you using?

[glich34]

Hello Xkain,
I use a D1 mini ESP32.
Is it OK? I can use other boards too.
I have enclosed photo od the D1 mini.

BR
Glich

[xkain]

Hello Glich,

I have been using the exact same board for 2 years for my own shutters and gates, and I also use it to develop all my releases. I have never encountered this issue, even with Rstouse v2.4.7.
Looking at your logs, the crash always occurs after a command.
Check your power supply, ensure it is stable, voltage drops during radio or Wi-Fi transmission often cause these types of errors.
Disable Web Logging, it consumes a lot of resources and can cause the Watchdog to timeout under load, test my 2.6.0 pre-release, have reworked the Watchdog for better stability. This version also includes an uptime counter, if the board reboots, the counter will reset to zero, confirming the crash.

[glich34]

Hello xkain,
I have installed your SW.
I have some comments:

• I have had boot issues after install SomfyController.ino.esp32.bin (release 2.6.0) no littlefs first. (log file logs_boot_issue.txt)
  After several install SomfyController.ino.esp32.bin file, it was loaded correctly.
  In another ESP mini I did not had this boot issues.
  This ESPS was the one that had previously rstrouse image.

• If I install littlefs bin file I have same boot issues. (log file logs_boot_issue.txt).
  Then I installed SomfyController.ino.esp32.bin and all was OK.
  I am not sure if littlefs bin file must be loaded. At GUI all seems OK:

• I have had an issue at restore with user/password, seems not to be restored.

• I needed to change the devices ID due the ones from rstrouse backup were not good.
  After looking for the right code at Radio/log, set the new code, all somfy were OK.

• I had a issue when I assigned the wifi. I scan for available wifi, I select the one I was going to use and write password. When I click save, at logs all time this line "Cancelling WiFi STA Scan..." until I reset the ESP32.
  I have not stopped the wifi scan manually.

Now it looks OK and it is working from HA.
I will leave logs running for few days.

You can contact me directly if you would like to test other things.
Thanks

logs_xkain_080526_1800.txt
logs_xkain_080526_1827_somfy_OK.txt

[glich34]

Hello xkain,
I have compared your backup with rstrouse:
From one line at device ID rstrouse backup (blod is the device ID):
1,true , 0, 682985,Vertical lateral , 0, 0, 56, 17000, 17000, 7000, 100, 16465727, 0, 0, 0, 0, 0, 0, 4700, 0, -1.00000, -1.00000, 0.00000, 0.00000,false,false, 1, 1, 0, 0, 0, 0, 1

It was restored as device ID 682985 on your image.

From same line at device ID from your backup (blod is the device ID):
1,true , 0, 16465727,Vertical lateral , 0, 0, 56, 17000, 17000, 7000, 100, 16465727, 0, 0, 0, 0, 0, 0, 604, 0, -1.00000, -1.00000, 13.45882, 0.00000,false,false, 1, 1, 0, 0, 0, 0, 1

Could it be 682985 is an internal ID for rstrouse, and you are using that information also for sensor ID?

I hope this could help you.

BR
Glich

[xkain]

Hi,

The v2.6.0 pre-release uses a different partition table. You must flash the ESP32 using the full onboard .bin file. Flashing SomfyController.ino.esp32.bin and SomfyController.littlefs.bin separately will cause issues because the offsets have changed. This likely explains the boot loops and the data corruption you experienced during the restore.
I haven't modified the data structure for the shade records or the header lengths (I only touched general and radio parts). If the IDs are shifting or appearing incorrectly, it is almost certainly due to the partition table offset conflict mentioned above.

If you'd rather not perform a complete reflash, v2.5.1 is your best bet. Since it doesn't include the major system and UI changes of the pre-release, it remains fully compatible with the original partition table and your previous backups.

Thank you for pointing out the "Cancelling WiFi STA Scan" loop. I will look into the logic to see why it isn't terminating properly after selection.

[glich34]

Hello,
I used the full onboard .bin.
Since today it seems OK.

Thanks for your help

[glich34]

I have just see this, not sure if its a problem (Invalid frame key):
[12:28:16]Received:{"shadeId":4,"target":0}
[12:28:16]Moving to 0.00% from 10.00% using Up
[12:28:16]CMD:Up ADDR:16400191 RCODE:235 REPEAT:1
[12:28:16]Enabled receive on Pin rstrouse#22 Timing: 1
[12:28:16]Timing WebServer: 306ms
[12:32:33]INVALID FRAME KEY:160 ADDR:10188958 CMD:Unknown(13) RCODE:49152
[12:32:33] KEY 1 2 3 4 5 6
[12:32:33]--------------------------------
[12:32:33]ENC 160 113 177 177 42 82 204 0 0 0
[12:32:33]DEC 160 209 192 0 155 120 158 0 0 0
[12:38:35]Sending Shade Command
[12:38:35]Received:{"shadeId":5,"command":"down"}
[12:38:35]CMD:Down ADDR:3899595 RCODE:2543 REPEAT:1
[12:38:35]Enabled receive on Pin rstrouse#22 Timing: 1
[12:38:35]Timing WebServer: 304ms

Thanks

[xkain]

Hi @glich34,

Regarding your INVALID FRAME KEY:160 log, the error occurs because the received frame contains the command 0xD (13 in decimal). In the somfy_frame_t::decodeFrame function, this command is classified as UnknownD, which forces this->valid = false. This is why the error message is displayed.

The most likely cause is a parasitic signal (radio interference) or simply a frame that the system correctly chose to ignore.

It's nothing serious, but keep an eye on it to see if it happens frequently. If it repeats often or ends up blocking your devices, please open a new specific Issue for it.

This current Issue is dedicated to "random crashes caused by the watchdog." It’s important not to mix different problems so we can stay focused on the stability fixes. Thanks!

[glich34]

Hello xkain,
since I installed 2.6.0 I have not seen the watchdog issue anymore.
I have only seen "INVALID FRAME" twice in 1 week. If I see it more, I will open a new issue as you mention.

BR
Glich

[xkain]

That is awesome news for anymore watchdog issue ! Thank you so much for the feedback.

I'll keep monitoring this issue a bit longer to see if other users provide feedback, but your results are extremely encouraging.
Thanks again for testing, and your help in making this fork more stable!