No in fact I would have assumed that node-red was calling the same endpoint with the same parameters. However, I wonder if you omitted the device on node red if it would just send it to the entity. Sending to just the device will move all.
The above in your logs looks like you have something that is not emitting json to node-red and node red thinks that it should be getting json. What sensors do you have flows for that are emitting an analog signal of 2048 and a result value of 19.
The lines below it simply look like HA is sending a command to every entity on the device one at a time. That is what happens when you just send the device id.
Got it !
It was so obvious that I havenāt seen the issue.
By having device & entity as target all devices were triggered ā¦
I made the change and kept only the entity and it works fine !
Thatās for your support !
Did you get this resolved?
I have the same errors when I restart HA, and likewise, all the blind entities are unavailable until I reload the integration. Iām running 2.3.0.
Is the component getting set up before the /discovery call returns with the serverId?
2024-01-19 14:25:19.859 ERROR (MainThread) [homeassistant.components.update] Error while setting up espsomfy_rts platform for update
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 360, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/espsomfy_rts/update.py", line 27, in async_setup_entry
async_add_entities([ESPSomfyRTSUpdateEntity(controller)])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/espsomfy_rts/update.py", line 41, in __init__
self._attr_name = f"ESPSomfy RTS {controller.server_id}"
^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/espsomfy_rts/controller.py", line 208, in server_id
return self.api.server_id
^^^^^^^^^^^^^^^^^^
File "/config/custom_components/espsomfy_rts/controller.py", line 422, in server_id
return self._config["serverId"]
~~~~~~~~~~~~^^^^^^^^^^^^
KeyError: 'serverId'
2024-01-19 14:25:19.867 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up espsomfy_rts platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 360, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/espsomfy_rts/sensor.py", line 96, in async_setup_entry
new_entities.append(ESPSomfyDiagSensor(controller=controller, cfg=ESPSomfyDiagSensorDescription(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/espsomfy_rts/sensor.py", line 116, in __init__
self._attr_unique_id = f"{cfg.key}_{controller.unique_id}"
^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/espsomfy_rts/controller.py", line 213, in unique_id
return f"espsomfy_{self.server_id}"
^^^^^^^^^^^^^^
File "/config/custom_components/espsomfy_rts/controller.py", line 208, in server_id
return self.api.server_id
^^^^^^^^^^^^^^^^^^
File "/config/custom_components/espsomfy_rts/controller.py", line 422, in server_id
return self._config["serverId"]
~~~~~~~~~~~~^^^^^^^^^^^^
KeyError: 'serverId'
It was solved by updating the integration and installing the latest firmware. My espsomfyās firmware was corrupted and had to reflash it by usb. Though there is a method a few eaactions above that mentions how to flash through a url
My firmware update didnāt work. I was going from v1.7.2 to v2.3.0. The firmware update worked fine and showed the new firmware version. But trying to Update Application the download of the backup completed but now I canāt connect.
Well, itās a bit odd, because the expected ports are open:
bill@macha:~$ sudo nmap espsomfyrts.local
Starting Nmap 7.80 ( https://nmap.org ) at 2024-01-21 08:17 PST
Nmap scan report for espsomfyrts.local (192.168.0.200)
Host is up (0.0073s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
80/tcp open http
8080/tcp open http-proxy
8081/tcp open blackice-icecap
MAC Address: 40:91:51:FC:03:84 (Unknown)
But Iām unable to connect either in Chrome/Mac or via command line. Netcat just hangs:
bill@macha:~$ printf "GET / HTTP/1.0\r\n\r\n" | nc -vd espsomfyrts.local 80
Connection to espsomfyrts.local (192.168.0.200) 80 port [tcp/http] succeeded!
^C
bill@macha:~$ telnet espsomfyrts.local 80
Trying 192.168.0.200...
Connected to espsomfyrts.local.
Escape character is '^]'.
Connection closed by foreign host.
I get the same trying /discovery on port 8081.
I can do a fresh flash, but curious if thereās other debugging I can do. I find it interesting that the ports are open but canāt get the webserver to respond. Any debugging tips?
My files:
bill@whm4pro ~/Downloads $ ls -lt | grep Somfy
-rw-r--r--@ 1 bill staff 1947 Jan 20 18:20 ESPSomfyRTS 2024-01-20T18_20_23.backup
-rw-r--r--@ 1 bill staff 1441792 Jan 20 18:14 SomfyController.littlefs.bin
-rw-r--r--@ 1 bill staff 1259280 Jan 20 18:13 SomfyController.ino.esp32.bin
-rw-r--r--@ 1 bill staff 4128768 Jun 21 2023 SomfyController.onboard.esp32.bin
My board:
Thanks,
Make sure you save the backup file that should have downloaded. If you do not have it first enter this url in a browser and press enter.
http://192.168.0.200/backup
This should download a file to your downloads.
Next enter the following url in a browser and press enter. While this is processing avoid any movement or remote usage. The primary failure mode for the application update is when the ESP32 persists data during the update.
http://192.168.0.200/downloadFirmware?ver=2.3.0
Let this process run for at least 2 minutes then try access again.
No luck. Iām not sure those requests were handled. They just both hang in the browser until they timeout.
nmap still says all three ports are open, but I canāt get any response either via a browser, lynx, netcat, or telnet. I have power-cycled the ESP a few times and the ports come back. So closeā¦
Happy to do any debugging that you can think of.
I donāt suppose thereās any logs (or even a way to get at them).
I do have the first backup when updating the app via the UI (ESPSomfyRTS 2024-01-20T18_20_23.backup). If I start over and flash I can use that to restore?
Thanks,
Yes you can use that to restore. If you connect to usb you can view the logs in web.esphome.io after you connect to the port. Do you see an ESPSomfy RTS SSID network in your wifi list?
No, itās not in AP mode. I can ping (and nmap) its assigned IP.
Oh, the logs help! Seems to be hanging at Check github for updates...
Launching web server...
Creating Web MicroServices...
WiFi Mode: 0
Scanned 4 Networks...
*0: catalan (-60dBm) CH:1 MAC:AC:15:A2:CF:C1:EC
1: (-60dBm) CH:11 MAC:2E:AA:8E:DB:4C:31
*2: catalan (-67dBm) CH:6 MAC:30:DE:4B:9F:81:E8
3: TEG-0AO (-88dBm) CH:6 MAC:2A:0F:EB:50:A7:46
Connecting to AP
Set hostname to:ESPSomfyRTS
**
Successfully Connected to WiFi!!!!192.168.0.200 (-63dbm)
MDNS Responder Started: serverId=FC0384
Connected to SSDP
SSDP Client Started...
App Version:2.3.0
No longer using NVS
Reading header at 0
version:17 len:56 shadeSize:272 shadeRecs:6 groupSize:184 groupRecs: 0 pos:56
Applying radio settings Setting Data Pins RX:12 TX:13
Setting SPI Pins SCK:18 MISO:19 MOSI:23 CSN:5
Radio Pins Configured!
Successfully set up the radio
Enabled receive on Pin #12 Timing: 1
Initializing RX Queue
Check github for updates...
I can reach github from my LAN. Is there a URL itās trying to reach I can try?
Yes the url is https://github.com/rstrouse/ESPSomfy-RTS
The software first sends a HEAD to this url to determine if the site is up.
No problem making that HEAD or GET request from my LAN.
Iāll re-flash and see how it goes. Thanks for the help.
$ curl --head https://github.com/rstrouse/ESPSomfy-RTS
HTTP/2 200
server: GitHub.com
date: Sun, 21 Jan 2024 19:31:01 GMT
content-type: text/html; charset=utf-8
vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, Accept-Encoding, Accept, X-Requested-With
etag: W/"be9202d8b9ba5b60e53e6c6bfa9b6ebe"
cache-control: max-age=0, private, must-revalidate
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: no-referrer-when-downgrade
content-security-policy: default-src 'none'; base-uri 'self'; child-src github.com/assets-cdn/worker/ gist.github.com/assets-cdn/worker/; connect-src 'self' uploads.github.com www.githubstatus.com collector.github.com raw.githubusercontent.com api.github.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com cdn.optimizely.com logx.optimizely.com/v1/events api.githubcopilot.com objects-origin.githubusercontent.com *.actions.githubusercontent.com wss://*.actions.githubusercontent.com productionresultssa0.blob.core.windows.net/ productionresultssa1.blob.core.windows.net/ productionresultssa2.blob.core.windows.net/ productionresultssa3.blob.core.windows.net/ productionresultssa4.blob.core.windows.net/ productionresultssa5.blob.core.windows.net/ productionresultssa6.blob.core.windows.net/ productionresultssa7.blob.core.windows.net/ productionresultssa8.blob.core.windows.net/ productionresultssa9.blob.core.windows.net/ github-production-repository-image-32fea6.s3.amazonaws.com github-production-release-asset-2e65be.s3.amazonaws.com insights.github.com wss://alive.github.com; font-src github.githubassets.com; form-action 'self' github.com gist.github.com objects-origin.githubusercontent.com; frame-ancestors 'none'; frame-src viewscreen.githubusercontent.com notebooks.githubusercontent.com; img-src 'self' data: github.githubassets.com media.githubusercontent.com camo.githubusercontent.com identicons.github.com avatars.githubusercontent.com github-cloud.s3.amazonaws.com objects.githubusercontent.com secured-user-images.githubusercontent.com/ user-images.githubusercontent.com/ private-user-images.githubusercontent.com opengraph.githubassets.com github-production-user-asset-6210df.s3.amazonaws.com customer-stories-feed.github.com spotlights-feed.github.com objects-origin.githubusercontent.com *.githubusercontent.com; manifest-src 'self'; media-src github.com user-images.githubusercontent.com/ secured-user-images.githubusercontent.com/ private-user-images.githubusercontent.com github-production-user-asset-6210df.s3.amazonaws.com gist.github.com; script-src github.githubassets.com; style-src 'unsafe-inline' github.githubassets.com; upgrade-insecure-requests; worker-src github.com/assets-cdn/worker/ gist.github.com/assets-cdn/worker/
set-cookie: _gh_sess=A1ocKcQiBjXXjUOhUft9sUWibcXxBB41UtQ7U6hd4xKRVkTX7jVafgEd9ronl0bsvl6CsolfhfN5z9mn8CQYhf1LFNXKF%2FVpoG7SCXLyw7igAchKE2WL%2FfOi6OFCFgDXVEjCSCpRvkdNzyh%2B1xfCfht6djBJreGxFwXFn6oLXnAhyHPB11jGdSzmk86%2FhjtU95SchfupbQ8FoY0EEtXNjKlNXr4lYnQbWYoilbkDMcvUP3OFunfX%2Fcl2r6nx9dh6ZdcbK5MrfYH9UswiaOngmg%3D%3D--WFYz0X2fY%2FiYmNUq--ungRIX8l9f6ya2eVxsqE8A%3D%3D; Path=/; HttpOnly; Secure; SameSite=Lax
set-cookie: _octo=GH1.1.1475529378.1705865461; Path=/; Domain=github.com; Expires=Tue, 21 Jan 2025 19:31:01 GMT; Secure; SameSite=Lax
set-cookie: logged_in=no; Path=/; Domain=github.com; Expires=Tue, 21 Jan 2025 19:31:01 GMT; HttpOnly; Secure; SameSite=Lax
accept-ranges: bytes
x-github-request-id: C2F2:189F:A02EADA:A5E0B62:65AD70F5
Well, not much luck.
I flashed the current version v2.3.0 and configured my network, but then once rebooted it hung again on fetching from github as before. I then tried a version earlier (v2.2.4) and same behavior. I then went back to the version before github update (v2.1.9) and that installed and ran, but then restoring from backup it gets a bit confused. Perhaps an incompatible backup format?
$ cat 'ESPSomfyRTS 2024-01-20T18_20_23.backup'
17, 56, 272, 6, 184, 0, 69, 116, 74,FC0384
2,true , 0, 102722,Living Room Left , 0, 0, 56, 15190, 12190, 7000, 100, 5208382, 0, 0, 0, 0, 0, 0, 125, 0, -1.00000, -1.00000, 0.00000, 0.00000,false,false, 1, 1, 0, 0, 0, 0
3,true , 0, 102723,Living Room Right , 0, 0, 56, 15190, 12190, 7000, 100, 5273918, 0, 0, 0, 0, 0, 0, 91, 0, -1.00000, -1.00000, 0.00000, 0.00000,false,false, 1, 2, 0, 0, 0, 0
4,true , 0, 102724,Nook Left , 0, 0, 56, 10770, 9770, 7000, 100, 5339454, 0, 0, 0, 0, 0, 0, 18, 0, -1.00000, -1.00000, 0.00000, 0.00000,false,false, 1, 3, 0, 0, 0, 0
5,true , 0, 102725,Nook Center , 0, 0, 56, 13000, 10140, 7000, 100, 5404990, 0, 0, 0, 0, 0, 0, 19, 0, -1.00000, -1.00000, 0.00000, 0.00000,false,false, 1, 4, 0, 0, 0, 0
6,true , 0, 102726,Nook Right , 0, 0, 56, 10770, 9770, 7000, 100, 5470526, 0, 0, 0, 0, 0, 0, 23, 0, -1.00000, -1.00000, 0.00000, 0.00000,false,false, 1, 5, 0, 0, 0, 0
7,true , 0, 102727,Kitchen , 0, 0, 56, 9050, 7550, 7000, 100, 1049647, 0, 0, 0, 0, 0, 0, 70, 0, -1.00000, -1.00000, 0.00000, 0.00000,false,false, 1, 6, 0, 0, 0, 0
"v2.3.0","ESPSomfyRTS","pool.ntp.org","PST8PDT,M3.2.0,M11.1.0",true
1,true ,"192.168.0.200","192.168.0.1","255.255.255.0","192.168.0.1","192.168.0.1", 0, 0, 0, 0, -1, 23, 18
true , 0, 56, 18, 5, 23, 19, 13, 12, 433.420, 99.97, 47.60, 10
My ESP32 does show an error on boot, but not enough of an ESP hacker to know what that means.
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13836
load:0x40080400,len:3608
entry 0x400805f0
E (251) psram: PSRAM ID read error: 0xffffffff
I tried another ESP32, but itās the same dev board revision (probably bought two at the same time). Same results.
Not sure what else to try now, other than order different ESP32 boards.
Which board do you have? A PSRAM read error on boot is normal for some boards.
Wait a minute are you flashing with SomfyController.esp32.bin and SomfyController.littlefs.bin? You cannot flash the s3, s2, or c3 files to a WROOM.
The dev version v2.3.1 is progress. Able to get past the updating from github, and restored, but the blinds are just not responding. Something to do with rolling code?
Hereās where v2.3.1 got past the check github:
Initializing RX Queue
Check github for updates...
Check Internet Success: 10578ms
[HTTPS] GET... code: 200
[HTTPS] GET... code: 200 - -1
SSDP: urn:schemas-rstrouse-org:device:ESPSomfyRTS:1 - true
Connected to SSDP...
Loading file /index.html
I then restored like this:
And now looks good:
Seems like the radio is working:
Now I need an SDR to see if Iām transmitting!
Interesting. That was going to be my next suggestion. v2.3.1 is in pre-release but I am about to release it soon.
The one difference in those two versions related to this is an update to the esp32 core. The psp usage was also trimmed a bit. It is interesting that it took a full 10 seconds to return the HEAD from github.
Double check your wiring to make sure the TX pin is still connected. If it is then the likely issue for the transmit are the rolling codes.
If you click on the Set Rolling Code for your shades and set them to the following you may not need to pair them again. Restoring a v2 backup file into a v1 firmware probably overwrote the rolling codes
Living Room Left = 126
Living Room Right = 92
Nook Left = 19
Nook Center = 20
Nook Right = 24
Kitchen = 70
I realized I was still on my 2nd ESP32 board, so I swapped back and installed v3.2.1, set my SSID/password, and then restored shades and radio settings from the backup fiile.
Then it all worked perfectly! I had noticed a comment on v3.2.1 about github update and decided to try. Looks like v3.2.1 is now current version.
Iām a bit curious why going back to the old board worked. Is the MAC address of the board used with pairing to the blinds?
Sorry for all the posting noise and I want to thank you for all the help ā and for the project, of course. I really appreciate it.
Cheers,
It worked because the rolling codes are stored in a different location than the filesystem. It keeps it all straight in non-volatile storage that does not get overwritten when the firmware is flashed. The new board did not contain these stored values and restoring the new file to the old firmware likely wrote misaligned values to that location. In versions 2+ the software deals with the situation of additional data in the backup file that it knows nothing about.
v2.3.1 has been waiting on some changes in the HA components which I finished up last weekend. It would be wise to install the released version of the firmware if you have not already.
No worries on the noise but glad you got it all working!