Somfy motor doesn't react to transmissions

[nymanjens]

Thanks for this amazing project!

I have a similar problem as https://github.com/rstrouse/ESPSomfy-RTS/issues/4. The receiving end seems to work perfectly. But the transmissions from the CC1101 don't get any reaction on the device [when pairing].

I've tried different ports as in https://github.com/rstrouse/ESPSomfy-RTS/issues/4, and I'm using the latest version v1.4.2 with the increased burst from 4 to 7 in https://github.com/rstrouse/ESPSomfy-RTS/commit/dce0ae0c04cbe0340c52a55811d8fb0204c6a13f. The CC1101 is definitely sending something because my loudspeakers pick up on both the Somfy remote and the CC1101 when it is transmitting.

My hardware:

• ESP32 board: az-delivery-devkit-v4
• CC1101 board: E07-M1101D-SMA
• Somfy motor for draperies

My thoughts:

• The prog command may need even more than 7 repeats maybe. To get the Somfy motor into pairing mode, I have to press the program button on my remote for some seconds. Definitely longer than I hear signal being transmitted by the CC1101.
• Maybe my CC1101 is broken, and I should just get another one

Could you maybe add an optional repeat argument to the /shadeCommand REST API? Then (if I'm understanding the code correctly), I could experiment myself by sending the prog command (curl "http://espsomfyrts.local/shadeCommand?shadeId=1&command=Prog&repeat=20") and see if it the motor reacts.

As an extra bonus, it could also (IIUC) make this project an alternative for getting the Somfy remote in the first place, because you can also use the REST API to send the initial UpDown command and then Prog to pair the motor from factory default directly to the CC1101. I tried this, by the way (without the repeat option), but nothing happened, possibly because of some other issue.

[nymanjens]

Update: I managed to compile the firmware with the following diff:

--- a/Web.cpp
+++ b/Web.cpp
@@ -899,7 +899,7 @@ void Web::begin() {
         server.send(500, _encoding_json, F("{\"status\":\"ERROR\",\"desc\":\"Shade not found to pair\"}"));
       }
       else {
-        shade->sendCommand(somfy_commands::Prog, 7);
+        shade->sendCommand(somfy_commands::Prog, 30);
         shade->paired = true;
         shade->save();
         DynamicJsonDocument doc(512);
@@ -945,7 +945,7 @@ void Web::begin() {
         server.send(500, _encoding_json, F("{\"status\":\"ERROR\",\"desc\":\"Shade not found to unpair\"}"));
       }
       else {
-        shade->sendCommand(somfy_commands::Prog, 7);
+        shade->sendCommand(somfy_commands::Prog, 30);
         shade->paired = false;
         shade->save();
         DynamicJsonDocument doc(512);

I can hear that it's now sending commands during ~5 seconds, which is more than the ~3 seconds I need to get it into pairing mode. But unfortunately, it didn't help :-/.

Do you have any thoughts on what the cause might be? If not, I guess I'll just order another CC1101 and try again.

[rstrouse]

Adding repeat is a pretty good idea. I will incorporate the ability to set the repeats. I am more inclined to think that you either have a transceiver that is not transmitting or the pin assignment is not correct. I had one in the pile of E07-M1101Ds that would not transmit. It took me a while until I was smart enough to throw it away and stop picking it up and trying to code with it.

Other than double checking your wiring. I am certain that the code to transmit is doing its thing. I have two on my desk talking to each other right now.

[rstrouse]

Hey a couple of other things. I have run into 80 bit shades. If you set the shade to 80 bits does it receive the prog command? In that instance the remote was a Telis 16. The other thing that I have seen is when all the pairing slots are full and the shade can no longer accept another remote.

Under the logs tab when you press on the remote is it reporting that it is sending 80 bit commands?

[rstrouse]

I just pushed the ability to identify the number of repeats on the API and I also fixed an issue with the 80-bit timing that I found in the process. I am not ready to push this into a release just yet but if you pull the changes you will get a fix for the 80-bit transmit as well as the ability to set the target on the api. I implemented it exactly as you suggested above.

curl "http://espsomfyrts.local/shadeCommand?shadeId=1&command=Prog&repeat=20"

[nymanjens]

I just pushed the ability to identify the number of repeats on the API

Amazing response time! Thanks! I built this locally and pushed it. The repeat parameter works (but still no luck getting the motor to react).

In that instance the remote was a Telis 16. The other thing that I have seen is when all the pairing slots are full and the shade can no longer accept another remote.

This one is brand new, with only one remote paired, so that can't be it in my case.

If you set the shade to 80 bits does it receive the prog command?

Nothing happens with 80 bits either. The remote is 56 bits according to the logs:

[{"encKey": 165,
  "address": 10173223,
  "rcode": 86,
  "command": "Down",
  "rssi": -47,
  "bits": 56,
  "sync": 4,
  "pulses": [2528,2526,2510,2499,4863,1258,1290,1291,1301,603,682,1266,1320,1264,672,620,656,639,657,618,1320,615,678,618,673,1265,1300,1281,657,621,668,634,1286,643,647,637,661,1275,1298,1291,1294,1266,671,622,1307,1275,1298,630,665,622,656,635,664,1270,1309,1269,655,640,655,619,670,634,1312,617,673,611,660,1273,1300,1279,1320,615,653,644,647,637,661,1274,673,613,1311,617,676,1266,648,645]
},
{"encKey": 166,
  "address": 10173223,
  "rcode": 87,
  "command": "Up",
  "rssi": -42,
  "bits": 56,
  "sync": 4,
  "pulses": [2535,2495,2541,2491,4840,1290,1292,1267,1321,609,686,1254,669,635,1286,1293,1284,646,643,633,660,640,667,1267,1311,1273,651,639,1283,644,654,639,658,620,669,1258,1314,1279,666,616,650,637,1312,1268,1313,621,669,1260,1304,624,682,1266,1293,637,661,1275,1299,630,672,1271,1286,1293,659,615,653,643,1299,628,665,1274,1309,618,674,1265,1297,1283,1314,1254,1307,1270]
},
...
]

I had one in the pile of E07-M1101Ds that would not transmit.

I'll order another one and see if it works.

[nymanjens]

(I just redid all the wiring with new cables, without any luck)

[rstrouse]

Yeah this is starting to look like your transceiver is receiving but not sending. Do you have the TX set to 10dBm? That device cannot send at 12dBm. Another thing to check is your power supply.

[nymanjens]

Do you have the TX set to 10dBm?

Yep

Another thing to check is your power supply.

Tried with a different power supply (3A) and different cable. Same problem.

I have another E07-M1101D being delivered in the next days. I'll keep you posted ;-).

[rstrouse]

Just to be sure it looks like you have this set to the following pins.

1 GND  - BLK
2 VCC  - RED
3 RX   - ORA - GPIO13
4 CSN  - BRN - GPIO5
5 SCLK - GRY - GPIO18
6 MOSI - YEL - GPIO23
7 MISO - WHT - GPIO19 
8 TX   - PUR - GPIO14

What are your radio settings? If you have TX set to GPIO12 then the pin you have connected is not correct. This should be GPIO14 or move the purple wire toward the orange wire 1 place. That would explain no TX.

[nymanjens]

Just to be sure it looks like you have this set to the following pins.

Yep, that matches my wiring diagram :-).

What are your radio settings?

If you have TX set to GPIO12 then the pin you have connected is not correct

I've tried multiple pins for the TX wire, and always updated the radio settings accordingly :-)

[rstrouse]

I was really hoping for bad aim on the TX pin. At this point it has to be the transceiver.

[nymanjens]

The new CC1101 arrived, but weirdly, it's having the exact same issue. Also they are not able to pick up each others' commands.

[rstrouse]

Is there anything weird about the devkit C with regard to gpio? The firmware uses gpio register writes to transmit because it needs to pulse at 640 microseconds per symbol.

[rstrouse]

Do you know which Espressif chip is on that board? Btw I have that exact USB hub.

EDIT: You should be able to add a shade without even pairing it and it should still send commands to the other transceiver.

[nymanjens]

I just tried some other pins:

• GPIO 12
• GPIO 14
• GPIO 26
• GPIO 27
• GPIO 17
• GPIO 2

but to no avail.

Do you know which Espressif chip is on that board?

The enclosure just says AZ-Delivery ESP32-WROOM-32. I think this is the datasheet

[nymanjens]

Btw I have that exact USB hub.

:-D

[rstrouse]

Funny but they never really call out which WROOM chip is running on the board. Is it the single or dual core model. It appears all of the ones I have are dual core models. I can't imagine that there would be two transceivers that cannot transmit. So that leaves the ESP32.

If you look at line 1643 in Somfy.cpp you will see where it writes out the registers for GPIO TX. Do you see anything in the serial console that could be a clue?

I wonder if chaning the REG_WRITE(GPIO_OUT_WITS_REG, pin) to digitalWrite(this->config.TXPin, 1) and REG_WRITE(GPIO_OUT_WITC_REG, pin) to digitalWrite(this->config.TXPin, 0) would make a difference. Is it possible that the GPIO registers are not available on this version?

[nymanjens]

Do you know which Espressif chip is on that board?

Using esptool.py --port /dev/ttyUSB0 flash_id, I actually get a bit more info: ESP32-D0WDQ6-V3 (revision 3)

[nymanjens]

I just tried with a slightly different board: Dev kit V1 (seems to match this spec with "ESP32-D0WDQ6 (revision 1)" as CPU. Same problem.

Which board(s) did you use?

[nymanjens]

The serial console output is quite uneventful?

Sending Shade Command
Received:{"shadeId":1,"command":"my"}
CMD:My ADDR:270714 RCODE:30 REPEAT:1
Enabling receive on Pin #13
Client 0 joining room 0
Sending Shade Command
Received:{"shadeId":1,"command":"my"}
CMD:My ADDR:270714 RCODE:31 REPEAT:1
Enabling receive on Pin #13
Sending Shade Command
Received:{"shadeId":1,"command":"down"}
CMD:Down ADDR:270714 RCODE:32 REPEAT:1
Enabling receive on Pin #13

[nymanjens]

I wonder if chaning the REG_WRITE(GPIO_OUT_WITS_REG, pin) to digitalWrite(this->config.TXPin, 1) and REG_WRITE(GPIO_OUT_WITC_REG, pin) to digitalWrite(this->config.TXPin, 0) would make a difference. Is it possible that the GPIO registers are not available on this version?

The diff below compiles and uploads successfully, but still nothing gets picked up by the other receiver or the motor.

diff --git a/Somfy.cpp b/Somfy.cpp
index 6778f74..dafa220 100644
--- a/Somfy.cpp
+++ b/Somfy.cpp
@@ -1627,41 +1627,41 @@ void Transceiver::sendFrame(byte *frame, uint8_t sync, uint8_t bitLength) {
   uint32_t pin = 1 << this->config.TXPin;
   if (sync == 2 || sync == 12) {  // Only with the first frame.
     // Wake-up pulse & Silence
-    REG_WRITE(GPIO_OUT_W1TS_REG, pin);
+    digitalWrite(this->config.TXPin, 1);
     delayMicroseconds(9415);
-    REG_WRITE(GPIO_OUT_W1TC_REG, pin);
+    digitalWrite(this->config.TXPin, 0);
     delayMicroseconds(9565);
     delay(80);
   }
   // Hardware sync: two sync for the first frame, seven for the following ones.
   for (int i = 0; i < sync; i++) {
-    REG_WRITE(GPIO_OUT_W1TS_REG, pin);
+    digitalWrite(this->config.TXPin, 1);
     delayMicroseconds(4 * SYMBOL);
-    REG_WRITE(GPIO_OUT_W1TC_REG, pin);
+    digitalWrite(this->config.TXPin, 0);
     delayMicroseconds(4 * SYMBOL);
   }
   // Software sync
-  REG_WRITE(GPIO_OUT_W1TS_REG, pin);
+  digitalWrite(this->config.TXPin, 1);
   delayMicroseconds(4450);
-  REG_WRITE(GPIO_OUT_W1TC_REG, pin);
+  digitalWrite(this->config.TXPin, 0);
   delayMicroseconds(SYMBOL);
   // Data: bits are sent one by one, starting with the MSB.
   // TODO: Handle the 80-bit send protocol
   for (byte i = 0; i < bitLength; i++) {
     if (((frame[i / 8] >> (7 - (i % 8))) & 1) == 1) {
-      REG_WRITE(GPIO_OUT_W1TC_REG, pin);
+      digitalWrite(this->config.TXPin, 0);
       delayMicroseconds(SYMBOL);
-      REG_WRITE(GPIO_OUT_W1TS_REG, pin);
+      digitalWrite(this->config.TXPin, 1);
       delayMicroseconds(SYMBOL);
     } else {
-      REG_WRITE(GPIO_OUT_W1TS_REG, pin);
+      digitalWrite(this->config.TXPin, 1);
       delayMicroseconds(SYMBOL);
-      REG_WRITE(GPIO_OUT_W1TC_REG, pin);
+      digitalWrite(this->config.TXPin, 0);
       delayMicroseconds(SYMBOL);
     }
   }
   // Inter-frame silence
-  REG_WRITE(GPIO_OUT_W1TC_REG, pin);
+  digitalWrite(this->config.TXPin, 0);
   delayMicroseconds(30415);
 }

[rstrouse]

Yeah that was a longshot. So weird the serial console is indicating that it getting to the point where it is sending the frame. This is the simplest part of the entire program.

[rstrouse]

I assume that it is picking up signals from your remote. How can it not transmit?

[rstrouse]

I have a whole bunch of these https://www.amazon.com/dp/B08246MCL5?psc=1&ref=ppx_yo2ov_dt_b_product_details

And a couple of WT32-ETH01 modules.

[rstrouse]

Let's get a baseline using these pins. I just do not understand this. The chip you are using is exactly the same as the one I am using according to the website. And there have been a few users that have used the LAN boards other than the WT32-ETH01. I know of one wESP32 and one Olimex. We have to be missing something simple.

SCLK = GPIO18
CSN  = GPIO05
MOSI = GPIO23
MISO = GPIO19
TX   = GPIO32
RX   = GPIO35

[nymanjens]

Let's get a baseline using these pins.

I can't set the TX pin to anything above GPIO31 in the UI. But I changed the RX pin to otherwise match your list. Same behavior.

[nymanjens]

Another data point: If I put a multimeter on the TX pin, I do measure 1.5-3V values while it is executing e.g. the following command:

http://somfyB.local/shadeCommand?shadeId=1&command=ud&repeat=20

and then when the command is done, it goes back to 0V.

As far as I can tell, this is saying that the TX pin is likely doing its job propely.

[rstrouse]

I forgot about the pin 32 debate and whether it truly can be used for output. I removed it from the dropdown list so it wouldn't be an issue.

It certainly sounds like there is no issue with the pin. Is it possible that there are 2 transceivers with the same failure mode? I suppose it might be, but it is highly unlikely. The software does use a couple of libraries so the libraries could be different. To remove that suspicion, you could flash the bin and not compile and link.

[nymanjens]

Update: I dug up an Olimex-EVB board, flashed the latest image from Github (without self-compiled stuff). I used the pins in the wiki. But I'm still getting the same behavior as on all the other boards: Receiver works perfectly, sending doesn't seem to do much.

[rstrouse]

Do me a favor just swap the send and receive pin connections. Do not change the configuration just change the pins. Don't do this on the Olimex do it on the wifi version.

[rstrouse]

I am so sorry! I completely mixed up GDO0 and GDO2. I had it correct at one point on my instruction sheet then another user pointed out that the table was wrong and I mis-understood them thinking the graphic was wrong. As a result, I changed the graphic to match the incorrect table.

Essentially you are sending on the GDO2 pin, which doesn't work because it can only be input and receiving on GDO0 which does work since it can be either input or output. Because of my mixup the GDO0 and GDO2 pins should have been reversed in the documentation. It should send on GDO0 and receive on GDO2.

Again sorry I got this so messed up. What is odd is I built 2 more of these since the doc edits and still did it right both times. I guess I was in autopilot. But when I checked your config, I checked it against the docs which was wrong.

[nymanjens]

I quickly swapped them on one of my boards, and the very first command worked immediately! I'll do some more testing when I have more time.

Thanks so much for your help investigating this!

Again sorry I got this so messed up.

No worries. The funny thing is that I actually thought at multiple times about whether TX and RX were in the right order because it's so easy to forget to switch them, but then I dismissed it because I thought RX was used for receiving the signals (which worked) + the instructions are very clear on this.

[nymanjens]

I checked in detail, and TX seems to work perfectly. The two transceivers are now picking up each others' signal!