Wind Sensor not sending update state to HA

[vobelic]

Hardware

ESP32

Firmware version

v2.4.2

Application version

v2.4.2

What happened? What did you expect to happen?

I noticed that wind sensor triggered shade close actions aren't (always?) being reported to HA. Not sure if this is more related to the ESPSomfy-RTS or ESPSomfy-RTS-HA? I would be able to discern where to exactly raise an issue if i would be able to reliably tell from ESPSomfyRST WebUI logs. However, the logs on the ESP itself aren't being saved when one is not logged in to the webui (intentionally i guess to go easy on the chip?), making this harder to track.

So my observation is that the HA integration does report the shade as closing but the wind sensor boolean isn't flipped. The weird thing is (but may be a coincidence), if i'm logged in to the ESPSomfyRST WebUI it all seems to work fine, and the Radio logs and the HA integration report as they should, both the "closing" and "wind sensor". Is this something perhaps that's a known issue?

I have a shade type "awning" setup and have registered both the Somfy Telis RTS remote as well as the wind sensor to the same shade.

How to reproduce it (step by step)

1. Open shade
2. trigger wind sensor
3. observe the triggered actions both by ESP and the HA integration
4. only the "closing" action for the entity will be reported, i.e. the "wind sensor" boolean won't be flipped

Logs

No response

[rstrouse]

I'll double check the state emits for the socket. It is probably not always sending this data on the state.

[rstrouse]

I double checked this function and it is working as advertised both when being sent between devices as well as from a simulated remote. Perhaps it you upload your backup I can restore and see if there is anything I am missing.

How are you triggering the windy condition. Are you using the virtual remote and does the display show a warning symbol for the awning?

[vobelic]

Here's the backup export: ESPSomfyRTS 2024-05-08T15_12_14.zip user: admin, password: admin

This is with ESPSomfyRTS WebUI inactive, i.e. browser tab/session from the browser is closed So I'm testing with the wind sensor physically, no virtual remote (the virtual remote properly sends the state trigger)

1. Have the awning opened
2. simulate the wind sensor by moving it to trigger the gyro/magnet
3. The awning motor gets the signal to close and does so, but the HA doesn't get either that it's closing nor that the wind boolean was flipped.
4. HA remains unaware that the awning is now closed

Now with ESPSomfyRST WebUI session active in a web browser:

1. Have the awning opened
2. simulate the wind sensor by moving it to trigger the gyro/magnet
3. now i see the exclamation mark, HA gets the wind sensor active as well as closing action.
4. HA is aware the awning is closed now (however the wind state remains permanently 'on', which is another issue, it should go to 'off' once the sensor isn't sending anything i guess)

I've tested this a couple of times.

[rstrouse]

The wind sensor state should remain on until the wind sensor reports that wind is no longer a factor. Typically these sensors do not report this condition right away.

Can you perform the first scenario then simply open the Web UI to see if ESPSomfy RTS got the frame from the wind sensor? There should be no bearing on whether the web ui is open or not. This is purely up to the ESP32 server to process these requests.

[vobelic]

That's the thing, when the WebUI is closed and I issue either a remote command (which is still seen in HA! i.e. that works fine in either scenario) or simulate the sensor, i see no logs in the ESPSomfy at all (when i open webUI afterwards), something i mentioned on the very beginning. So I can't confirm if the frame was received by ESPSomfy or not.

When i have the WebUI opened in front of me while hitting the remote buttons or the sensor, and looking at the logs it is received by ESPSomfy, both the Up/My/Down and Sensor events/frames are always seen. This indicates that the radio itself is working just fine.

[rstrouse]

When the wind sensor is triggered there will be an exclamation point on the awning as below. Without the configuration pages open no frames are logged. This is intentional since there is no place to put them without competing with the storage needed for the firmware and UI files. The frame data is very large and the resources on the ESP32 are very small in comparison.

This is also the reason serial logs are not kept on the device and those are considerably smaller. Either one would either exhaust the available resources or if just a small subset was persisted it would chew up the CPU cycles and eventually wear out the flash.

So I didn't mean to look in the transceiver logs to see whether it got a frame I meant to look to see whether the windy condition was triggered in the UI. What you will see is that exclamation point indicating that there is a windy condition. That is until the sensor sends clear messages indicating that there is no windy condition. (this is true for vibration sensors as well).

When a windy condition is detected the motor will retract the awning immediately even if the windy condition clears right away. Most motors will also suspend operation for a minute or two to make sure you don't extend the awning into a windstorm that just occurred. If you press the remote button a few times however it will override the windy lockout. At least this is what the Somfy documents say.

[vobelic]

I'm aware and suspected the reason for not logging it down, and it of course makes perfect sense. Never questioned that. However I think we need some debugging options that can be explicitly enabled to understand what's happening under the hood when it doesn't work.

As I'm saying once again, when i'm looking at the WebUI and triggering the wind sensor - it all works, i get the exclamation mark as you posted on the screenshot, i see the awning being closed in the browser and also the ESPSomfyRTS-HA integration properly reports the wind sensor trigger AND sees the awning being closed. It always works when i'm in the UI. I can only test some more to exclude the possibility i'm of being fooled by some other coincidence.

[rstrouse]

Open the transceiver logs and capture the frames from the sensor (not ones generated by the virtual remote). You should see something like the following. Press the copy command and paste that here. Perhaps there is something missing from the frame output of the sensor. Either way that will allow me to stand up a radio and broadcast the data.

EDIT: If you connect the USB cable to a computer and use esphome.io you can monitor the serial logs and see what is happening in from the serial prints.

[vobelic]

[{"encKey": 167,
  "address": 11047725,
  "rcode": 5918,
  "command": "Down",
  "rssi": -59,
  "bits": 56,
  "proto": 0,
  "valid": true,
  "sync": 4,
  "pulses": [8017,4002,3987,3991,3997,4009,3992,4003,4013,3986,4022,3989,1719,2512,2621,2472,2615,4816,1308,1267,1302,1265,672,611,1309,620,673,613,689,597,669,630,658,607,691,1244,681,604,691,594,694,587,688,621,1296,635,663,626,665,597,675,1262,1301,630,660,630,674,597,674,615,661,622,668,1257,1316,1270,686,588,1329,1252,1318,1270,657,630,664,621,670,613,664,623,1296,636,663,625,645,1276,1296,1269,682,605,1345,1231,1310,618,670,607,687,600,671,625,679,608,664,620,668,610,686],
  "time": "2024-05-08T19:49:08.058+0200"
},
{"encKey": 168,
  "address": 11047725,
  "rcode": 5919,
  "command": "Up",
  "rssi": -58,
  "bits": 56,
  "proto": 0,
  "valid": true,
  "sync": 4,
  "pulses": [4023,7975,4018,4002,4002,3997,3991,717,2513,2629,2474,2607,4809,1331,1245,1326,1267,1296,1254,696,610,661,614,1315,1276,664,625,670,603,679,615,1299,632,658,614,672,624,652,1285,671,602,1330,1240,673,607,690,619,666,609,1309,1267,680,607,666,618,1324,607,682,593,695,587,688,1249,694,610,1292,1269,681,606,1319,598,675,608,690,619,667,1258,1293,620,673,1259,1321,1263,689,593,1319,1257,668,632,1310,595,669,1259,690,594,1321],
  "time": "2024-05-08T19:49:46.479+0200"
},
{"encKey": 169,
  "address": 11047725,
  "rcode": 5920,
  "command": "Down",
  "rssi": -60,
  "bits": 56,
  "proto": 0,
  "valid": true,
  "sync": 5,
  "pulses": [4022,3992,3234,2531,2583,2507,2594,4829,1301,1267,1323,1251,1315,1260,670,603,1329,616,668,608,660,628,662,1252,1315,620,695,1236,1305,627,680,606,666,619,668,610,688,598,673,1250,1337,1242,1308,622,671,1254,1316,619,673,1239,1328,1256,666,622,1319,609,690,597,668,1257,690,595,1318,1266,1298,633,681,591,696,1252,664,622,669,605,681,607,1316,623,653,634,666,1277,645,615,1336,596,674,1258,672,624],
  "time": "2024-05-08T19:52:40.609+0200"
},
{"encKey": 160,
  "address": 9352673,
  "rcode": 0,
  "command": "Sensor",
  "rssi": -81,
  "bits": 56,
  "proto": 0,
  "valid": false,
  "sync": 4,
  "pulses": [1620,2461,2570,2433,2575,4717,1353,1207,1057,50,296,1522,706,572,722,580,708,585,701,598,699,657,1279,1230,708,595,685,605,704,569,1344,1252,688,598,1359,1211,717,581,708,595,534,25,173,742,1362,1224,651,634,1368,1224,685,587,727,574,705,587,1353,1227,1333,598,410,435,703,1284,625,596,1195,50,149,741,719,1206,706,671,631,579,1363,596,673,608,710,585,699,1232,308,334,688,612,1341,581,703,1219,698,606,1332,593,721,1194,717,576,707,26,640],
  "time": "2024-05-08T19:54:25.345+0200"
},
{"encKey": 160,
  "address": 8472032,
  "rcode": 65280,
  "command": "Sensor",
  "rssi": -82,
  "bits": 56,
  "proto": 0,
  "valid": true,
  "sync": 6,
  "pulses": [1190,2455,2571,2422,2576,2452,2342,25,228,4961,1346,1210,1369,1200,709,576,629,658,726,580,704,596,690,593,981,100,400,1604,686,597,722,582,707,576,1365,1234,405,1277,1095,50,270,1485,696,594,705,595,720,559,333,358,1371,1199,716,601,1349,1209,229,254,682,597,722,581,707,598,1342,1206,1370,581,708,1198,719,584,639,26,726,572,724,1210,703,597,699,594,1348,581,712,584,700,599,701,1207,701,599,1356,584,487,51,221,1422,730,571,1276,675,710,1199,702,611,100,151,1341],
  "time": "2024-05-08T19:54:25.615+0200"
}]

One thing to note, I could have sworn i've seen the sensor sending 80-S when i first installed it it. The physical remote was always 56-S however.

[rstrouse]

Hmmm... neither one of those sensor frames are mapped to the sensor that you have linked. For instance the one that was from 9352673 fails the checksum and is the wrong address. I assume that the address that is supposed to be linked was 9352672. However, there is another sensor command in there that is from 8472032 which is a valid frame.

[vobelic]

Damn, you are right, totally missed that. Uh, might have chased a totally wrong lead then, but a mystery remains how a totally wrong address was learned from the sensor, how can it spew frames with that many wrong IDs ...

[rstrouse]

The checksum is potentially fallible as as part of the definition of the protocol. You can get weird frames but in most cases they will just be ignored. It is up to the endpoints to verify the address and bits. In this case ESPSomfy RTS is doing exactly that and ignoring the invalid frames. However, when it comes to the linking instance it is simply looking for an address from the frame so it will accept it.

How are you triggering the sensor?

[rstrouse]

One thing I noticed on the sensor frames only, is that noise occurs in the pulses from the sensor. See any pulse that is < 300 or between 800 and 900. In the examples above these are almost always a < 300 condition. I don't have enough samples to make a determination as to whether this is a carrier drop or if it is just transmitting erroneous blips. These do not appear in the frames from the remote and represent near flawless frames, so it is likely coming from the transmitter on the sensor itself.

If you capture a log of many sensor frames we may be able to see a pattern that can be tuned out by moving the base frequency and/or narrowing/widening the interference.

[rstrouse]

@vobelic did you get this sorted out. If not capture some more frames from the sensor. In the output above it is sending some interference.

[vobelic]

Sorry, meanwhile I had an awning malfunction and couldn't try, it just got repaired the other day. I'll play around with the sensor and try to readjust the freq (I already had to do that on the beginning, it was hard to get the sensor ID to be even recogn. and thought i finally got it). Hopefully that's all there is to it and then i'll report here.

cheers!

[vobelic]

So I got the awning repaired and managed to tune it a bit better. The following are sensor entries, save the 3 last ones from the remote.

I think now the 9352672 is the proper sensor address, anything that I could tune? Base freq: 433.38 Rx bw: 104.19 Freq dev: 37.80

Here's the logs: https://pastebin.com/7pS795xk

[rstrouse]

Wow that sensor is dropping the carrier for about half of the frames. Your remote signals are very clean. Increase your frequency deviation to around 70kHz to see if we can smooth this out.

What is between the ESPSomfy RTS device and the location where the sensor is installed? Include metallic and electrical items. By chance is there a stucco wall? Remember that sensor is probably not more than a few feet from the motor.

[vobelic]

I moved the esp so only a glass pane of the balcony door should be between the esp and sensor (installed on the movable awning itself). Before that there was an outer brick wall in the path. I also noticed that the moment I instaled the sensor on the awning metallic frame it got worse...

Here's the read out after moving and setting freq dev to 70: https://pastebin.com/Qsi4f4P5

[rstrouse]

It looks like about half of the sensor reading frames are corrupted. Open up the scan frequency screen and trigger the sensor while scanning. Lets see if the center frequency is off. When it picks up the sensor it will find the highest RSSI for the sensor.

[vobelic]

Already did so, 433.38 was the freq detected using scan.

[rstrouse]

Is that the detected center from the sensor or a remote?

[vobelic]

Sensor, remote gets detected a tad bit higher

[rstrouse]

Lets try narrowing the bandwidth all the way down to 58.03 and see if we get any responses from the sensor.

[vobelic]

Hi, So I verified that the sensor gets discovered now on 433.44, it simply seems unstable as last time it constantly got discovered on 433.38. On that freq the remote doesn't work so I'm using 433.40 to get them both going. I also did try lowering the bw all the way down to 58.03 and the sensor still works (remote doesn't). I think I'll just leave it like this because without some spectrum scanner I could play like this for days. Repositioning the esp also helped as it's much better than before. I think there's no point in keeping this issue open as it's clearly an issue on the radio side and my initial suspicion was completely wrong. Thanks for the assistance though!

Cheers