Compile error : esphome v2023.2.4 + Doubt about wiring

[MrBLJ]

Hi,

First, thanks a lot for the detailed article and configs you shared. I'm having trouble compiling with ESPHome.

Here's the error message I'm getting :

In file included from src/main.cpp:34:
src/somfy_cover.h:16:3: error: 'NVSRollingCodeStorage' does not name a type; did you mean 'RollingCodeStorage'?
   16 |   NVSRollingCodeStorage *storage;
      |   ^~~~~~~~~~~~~~~~~~~~~
      |   RollingCodeStorage
src/somfy_cover.h: In constructor 'SomfyESPCover::SomfyESPCover(const char*, const char*, uint32_t)':
src/somfy_cover.h:21:5: error: 'storage' was not declared in this scope
   21 |     storage = new NVSRollingCodeStorage(name, key);
      |     ^~~~~~~
src/somfy_cover.h:21:19: error: expected type-specifier before 'NVSRollingCodeStorage'
   21 |     storage = new NVSRollingCodeStorage(name, key);
      |                   ^~~~~~~~~~~~~~~~~~~~~
/config/esphome/d1mini-02.yaml: In lambda function:
/config/esphome/d1mini-02.yaml:59:37: warning: 'void esphome::cover::Cover::stop()' is deprecated: stop() is deprecated, use make_call().set_command_stop() instead. [-Wdeprecated-declarations]
   59 |           ((SomfyESPCover*)id(somfy))->stop();
      |                                     ^
In file included from src/esphome/core/controller.h:14,
                 from src/esphome/components/api/api_server.h:4,
                 from src/esphome/components/api/api_connection.h:6,
                 from src/esphome.h:3,
                 from src/main.cpp:3:
src/esphome/components/cover/cover.h:146:8: note: declared here
  146 |   void stop();
      |        ^~~~
Archiving /data/d1mini-02/.pioenvs/d1mini-02/lib67b/libESP8266WiFi.a
*** [/data/d1mini-02/.pioenvs/d1mini-02/src/main.cpp.o] Error 1

It looks like ... well actually I'm not so sure what I'm looking at, but a few google searches make me think it's related to newer versions of ESPhome having differents requirements than the one you're using with your config.

Btw, mine is looking like so :

esphome:
  name: d1mini-02
  friendly_name: d1mini_02
  includes:
    - components/somfy_secrets.h
    - components/somfy_cover.h
  libraries:
    - EEPROM
    - SPI
    - SmartRC-CC1101-Driver-Lib@2.5.6
    - Somfy_Remote_Lib@0.4.1

esp8266:
  board: d1_mini

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

captive_portal:

cover:
  - platform: custom
    lambda: |-
      auto somfy_remote = new SomfyESPRemote();
      somfy_remote->add_cover("somfy", "auvent", SOMFY_REMOTE_AUVENT);
      App.register_component(somfy_remote);
      return somfy_remote->covers;
    covers:
      - id: "somfy"
        name: "Somfy Cover"

switch:
  - platform: template
    name: "PROG"
    turn_on_action:
      - lambda: |-
          ((SomfyESPCover*)id(somfy))->program();
  - platform: template
    name: "STOP"
    turn_on_action:
      - lambda: |-
          ((SomfyESPCover*)id(somfy))->stop();

I do have somfy.h and somfy_secrets.h placed inside a folder name components in my esphome folder.

As a sidequestion, since I'm pretty sure it's going to cause issue as well : I've read (numerous times) your article, and you shared the link to a repo with wiring instructions related to a d1 mini board. Can I use the same wiring with your code ? Booting with D8 (CSN) on high crashes the D1 mini. Is that something I should be worried about ?

[evgeni]

Hmm, I'll try to to compile with a newer esphome later, but the error looks more like it can't find the lib, weird.

As for wiring, I have no d1mini to test, but if the pin doesn't work use a different one and maybe configure that in the lib (I'll have a look if that's needed)

[evgeni]

Mhh, looking at d1mini pinout d8 is the correct csn and not sure how to change that

[evgeni]

oooh, wait, d1 mini is a 8266, right? that doesn't have NVS! you need to use a different storage

[evgeni]

(and I pushed a change for the deprecation warning, but that's just that, a waning)

[MrBLJ]

Wow, thanks for you prompt feedback ! You're right, D1 is a 8266 board. For what it's worth, I've successfully used a CC1101 module with esphome on this board, with the following code. Note that CSN has been changed to D3

esphome:
  name: d1_mini-01
  friendly_name: d1_mini-01
  includes:
    - components/cc1101.h
  libraries:
    - SPI
    - "SmartRC-CC1101-Driver-Lib"
esp8266:
  board: d1_mini

sensor:
  - platform: custom
    lambda: |-
      auto my_sensor = new CC1101(
        D5, // SCK
        D6, // MISO
        D7, // MOSI
        D3, // CSN
        D1, // GDO0
        D2, // GDO2
        200, // bandwidth_in_khz
        433.92 // freq_in_mhz
      );
      App.register_component(my_sensor);
      return {my_sensor};
    sensors:
      id: transciver
      internal: true

remote_transmitter:
  - pin: D2 # This is GDO2
    carrier_duty_percent: 100%

remote_receiver:
  - pin: D1 # This is GDO0
      # on the esp8266 use any of D1,D2,D5,D6,D7,Rx
      # Don't use D3,D4,D8,TX, boot often fails.
      # Can't be D0 or GPIO17 b/c no interrupts
    dump:
      - raw

# Enable logging
logger:
  level: VERBOSE

# Enable Home Assistant API
api:
  encryption:
    key: "S5HEFkRsuzyqGVKdh/+SWK2rWQhR/++mxeFmZN166t8="

ota:
  password: "ff9f65c88d29824c7da5e094bfdb2dd3"

wifi:
  ssid: "XX"
  password: "XX"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Nodemcu-01 Fallback Hotspot"
    password: "L8xyO3JZbDTx"

web_server:
  port: 80

captive_portal:

I'm not able to understand your remark able NVS yet. I'll do some digging to understand what's going on.

[evgeni]

To store the rolling codes for the shutters, we need some storage. The library supports two backends: EEPROM and NVS: https://github.com/Legion2/Somfy_Remote_Lib/#rolling-code-storage NVS is a ESP32-only backend (but much nicer to work with than EEPROM).

To use EEPROM storage you'll have to edit https://github.com/evgeni/esphome-configs/blob/devel/somfy_cover.h to follow the storage setup like in https://github.com/Legion2/Somfy_Remote_Lib/blob/main/examples/CC1101/CC1101.ino

[MrBLJ]

Thanks a lot for those resources, this is most helpful. I have an okay understanding with what's going on, the downside being that I have close to zero knowledge in C++. Anyway. I've modified the file to my best ability :

#include "esphome.h"
#include <EEPROMRollingCodeStorage.h> // Replaced #include <NVSRollingCodeStorage.h>
#include <ELECHOUSE_CC1101_SRC_DRV.h>
#include <SomfyRemote.h>

#define EMITTER_GPIO 2
#define EEPROM_ADDRESS 0 // Added
#define CC1101_FREQUENCY 433.42

#define COVER_OPEN 1.0f
#define COVER_CLOSED 0.0f

class SomfyESPCover : public Cover {
private:
  SomfyRemote *remote;
  EEPROMRollingCodeStorage *storage; // Replaced NVSRollingCodeStorage *storage;

public:
  SomfyESPCover(const char *name, const char *key, uint32_t remoteCode)
      : Cover() {
    storage = new EEPROMRollingCodeStorage(EEPROM_ADDRESS); // Replaced new NVSRollingCodeStorage(name, key);
    remote = new SomfyRemote(EMITTER_GPIO, remoteCode, storage);
  }

  CoverTraits get_traits() override {
    auto traits = CoverTraits();
    traits.set_is_assumed_state(true);
    traits.set_supports_position(false);
    traits.set_supports_tilt(false);
    return traits;
  }

  void sendCC1101Command(Command command) {
    ELECHOUSE_cc1101.SetTx();
    remote->sendCommand(command);
    ELECHOUSE_cc1101.setSidle();
  }

  void control(const CoverCall &call) override {
    if (call.get_position().has_value()) {
      float pos = *call.get_position();

      if (pos == COVER_OPEN) {
        ESP_LOGI("somfy", "OPEN");
        sendCC1101Command(Command::Up);
      } else if (pos == COVER_CLOSED) {
        ESP_LOGI("somfy", "CLOSE");
        sendCC1101Command(Command::Down);
      } else {
        ESP_LOGI("somfy", "WAT");
      }

      this->position = pos;
      this->publish_state();
    }

    if (call.get_stop()) {
      ESP_LOGI("somfy", "STOP");
      sendCC1101Command(Command::My);
    }
  }

  void program() {
    ESP_LOGI("somfy", "PROG");
    sendCC1101Command(Command::Prog);
  }
};

class SomfyESPRemote : public Component {
public:
  std::vector<esphome::cover::Cover *> covers;

  void setup() override {
    // need to set GPIO PIN 4 as OUTPUT, otherwise no commands will be sent
    pinMode(EMITTER_GPIO, OUTPUT);
    digitalWrite(EMITTER_GPIO, LOW);

    ELECHOUSE_cc1101.Init();
    ELECHOUSE_cc1101.setMHZ(CC1101_FREQUENCY);

    EEPROM.begin(4); // Added : Initialize EEPROM
  }

  void add_cover(const char *name, const char *key, uint32_t remoteCode) {
    auto cover = new SomfyESPCover(name, key, remoteCode);
    covers.push_back(cover);
  }
};

This compiles and, lo and behold, it does not crash the ESP even with d8 used for CSN. Commands seem to be working, according to the logs :

[10:12:29][D][cover:170]: 'Somfy Cover' - Publishing:
[10:12:29][D][cover:176]:   State: OPEN
[10:12:29][D][cover:186]:   Current Operation: IDLE
[10:12:34][D][cover:076]: 'Somfy Cover' - Setting
[10:12:34][D][cover:086]:   Command: CLOSE
[10:12:34][I][somfy:047]: CLOSE
[10:12:35][D][cover:170]: 'Somfy Cover' - Publishing:
[10:12:35][D][cover:178]:   State: CLOSED
[10:12:35][D][cover:186]:   Current Operation: IDLE
[10:12:40][D][cover:076]: 'Somfy Cover' - Setting
[10:12:40][D][cover:080]:   Command: STOP
[10:12:40][I][somfy:058]: STOP

I've setup the esphome webserver, everything looks fine :

Now, obviously, there's still an issue. Following the article you wrote, I use a SDR to sniff the signals of my original remote.

rtl_fm -M am -f 433.42M -s 270K | ./am_to_ook -d 10 -t 2000 - | ./decode_somfy

The signals of the remote are catched and successfully logged :

It's not the case for the esp : nothing happens on the SDR side when I press the buttons on the webserver (although the command is successfully sent).

So, I fired up airspy to check what's going on. When a button on the remote is pressed, there are some well defined spikes that I can see :

With, the CC1101, something is happening but the spike is tiny :

Does it looks like a hardware problem ? I'm using kinda the same board as yours :

[MrBLJ]

Continuing my investigation. I've tried :

• Using a different CC1101 module (same model).
• Using a different board (D1 mini as well).
• Using a different ESP8266 board (Nodemcu v2).

The amplitude of the signal is a bit better, but still very weak compared to the one obtained with the remote. I've looked into the repo of LSatan for inputs, but so far I've found nothing. I'll post an update if I make some progress.

Note : I'm using dupont connectors for wiring. Maybe I should try soldering everything.

[MrBLJ]

Update : the plot thickens.

I tried using the ESP as a remote for the the shutter with the current state of things : nope, did not work.

~~The strange thing is, I can't sniff signals with my SDR anymore: Might be because I'm on a laptop currently, it's plugged in and I'm using an extension cord. _rtltest does not highlight major packet loss. I'm on wsl also, so I might need to use a proper linux install to debug things.

sudo rtl_fm -M am -f 433.42M -s 270K | ./converters/am_to_ook -d 10 -t 2000

Gives me (strange outputs), when I add the somfy part, no output at all.~~

Edit : fixed the above, I switched to using rtl_433; Works out of the box. It's not catching anything from the esp though.

At the very list, this is interesting if not a bit frustrating ^^. Guess I'm learning some stuff afterall.

[ftpproxy]

I had the same problem, not seeing any packets going out. Today I updated esphome and the device to esphome v2023.4.2 and the issuse was gone without changing anything to the code. Shutters working now flawlessly.

[MrBLJ]

I came back to this after a while, and followed @ftpproxy's advice. Unfortunately, the issue remains the same. @ftpproxy, could you specify the type of emitter you're using ?

[grigorgeous]

@MrBLJ I have the same problem -- ESP32+CC1101 just doesn't send anything after I press "PROG" on the webserver according to my SDR. Have you figured out how to fix it? Everything works expect this final part.

[grigorgeous]

I came back to this after a while, and followed @ftpproxy's advice. Unfortunately, the issue remains the same. @ftpproxy, could you specify the type of emitter you're using ?

Hey, I've just finally resolved this issue! I had the same problem -- SDR kept silent all the time. In order to connect ESP32 to CC1101 I used breadboard and the same wires from Amazon with black connectors. At first, I wanted to connect everything beautifully, so that the ESP32 could be disconnected from the board without resoldering if it becomes dead. After many attempts I decided to solder everything directly to ESP32 using wires only, and that did the trick! I see you're using the same wires with black connectors I used, so this solution might help you as well. Cheers!

[MrBLJ]

Hey @grigorgeous . Thanks a lot for your feedback ! I went the same way and ordered an esp32 which I received yesterday. I'll try soldering the wires directly, since it's still the same situation for me. I'm struggling with the wiring though, I think I messed up and ordered a development board that doesn't have the right pins (can't find MOSI for example):

edit : Messed with the wiring, and I have something that seems to be working using dupont connectors. At least, it's emitting something now :

I'm still unable to sniff anything using : rtl_fm -M am -f 433.42M -s 270K | ./am_to_ook -d 10 -t 2000 - | ./decode_somfy

1. The emitted signal seems to be centered on 433.45MHz : Could this be an issue ?

2. I'll try tweaking the command to try sniffing the packages.

3. Current wiring : I have a doubt about D2 and D4. Could anyone confirm it's correct ?

[grigorgeous]

@MrBLJ Wiring looks just fine. Try soldering it directly, this should do the trick. However, I cannot sniff anything with rtl_fm, too. I want to sniff codes because my ESP32 breaks my remote for some reason. Say, I programmed one office blind with PROG, then a group of other blinds in the living with PROG2, but when I open/close living room blinds it also triggers office blinds. Then, my remote also starts to mess blinds. I presume the problem is in codes (I used 0x123456 and 0x654321) which differs from the ones in my remote. WDYT? But I need to figure out how to sniff these codes first.

[grigorgeous]

@MrBLJ Ok, I've resolved the issue with sniffing. Installing rtl_433 with apt was a mistake -- it is very outdated. I had to build rtl_433 from the source, and it's catching and decoding my remotes now as it should.

[MrBLJ]

Hi @grigorgeous. Thanks a lot for your insights !

1. I'm soldering the wires today, and will report in case of significative improvement. edit: Done soldering. No visible improvement in signal strength, as displayed in Airspy. I still can't sniff the signal with rtl_433.
2. I've reinstalled rtl_433 the way you described : Same result. Could you share the command you used, and other parameters you modified to get it working ?

[grigorgeous]

Hi @grigorgeous. Thanks a lot for your insights !

1. I'm soldering the wires today, and will report in case of significative improvement. edit: Done soldering. No visible improvement in signal strength, as displayed in Airspy. I still can't sniff the signal with rtl_433.
2. I've reinstalled rtl_433 the way you described : Same result. Could you share the command you used, and other parameters you modified to get it working ?

Soldering didn't resolve sniffing issue for me, it resolved "PROG" issue on my web interface. It didn't work, it started to work. As for rtl_433, I used the following: 1. Clone github repo. 2. Run do_build.sh script. 3. Install additional libraries if compilation fails (was librtlsdr-dev in my case). 4. Executable will be located in rtl_433/build/src folder -> run it using the following command: ./rtl_433 -M am -f 433.42M -s 270K

Initially it took like few minutes to load all the protocols but it was much faster next time. Hope it helps.

P.S.: Can you show your wiring result?

[MrBLJ]

Well, we're definitely going somewhere. Remote is operationnal. So far, here is what I can confirm :

1. Using an E07-M1101D as emitter is a viable solution.
2. No luck with D1 mini or NodeMCU. Switching to ESP32 seems to halve solved the issue.
3. Board used : ESP32DEVKIT1.
4. Wiring as follow :
5. Soldering on the board :
6. Soldering on the E07-M1101D :
7. Signal is sniffed using rtl_433, following @grigorgeous instructions above :

I'll using the ESP on my blinds tonight. Quick question though, if the ESP crashes/stop working, can I still pair my original remote ?

edit : something I just realized. The remote ID defined in esphome (0x123456) is not the same as the one found by rtl-sdr (563412). Thaht might be something to look into in order to troubleshoot your issue @grigorgeous .

[grigorgeous]

@MrBLJ I'm glad my suggestions helped! :) As for codes, yesterday I checked codes sent by multiple remotes and ESP32 I have, they all send different codes. I don't really know what's the point of setting it in ESPHome then. By the way, my issue might be related to something different (probably not an issue at all; more like an unexpected behavior). So, basically, when I try to sort of reprogram the OFFICE button, it adds blinds to the existing one instead of changing it. Looks like I was adding more and more blinds to this button making a mess.

[grigorgeous]

Ok, I've just changed the code in somfy_secrets.h for my OFFICE blinds, and it helped to reset it. I reprogrammed it successfully keeping in mind the above-mentioned reprogramming logic -- blinds are always added on top of other blinds; in order to remove blinds, you should add same blinds again instead of trying to add others.

One more thing -- I've added "traits.set_supports_stop(true);" line in CoverTraits at somfy_cover.h. It brings "stop" button back to HomeAssistant (it's required starting 2023.5.0 version, check https://github.com/esphome/esphome-docs/pull/2944 for more).

[MrBLJ]

I have successfully paired two devices, so I can finally say that everything is working finally ! Many thanks to @grigorgeous, i could not have done it without you !

For anyone interested, check my previous post for details about how it should be setup.

[MrBLJ]

Ok, I've just changed the code in somfy_secrets.h for my OFFICE blinds, and it helped to reset it. I reprogrammed it successfully keeping in mind the above-mentioned reprogramming logic -- blinds are always added on top of other blinds; in order to remove blinds, you should add same blinds again instead of trying to add others.

One more thing -- I've added "traits.set_supports_stop(true);" line in CoverTraits at somfy_cover.h. It brings "stop" button back to HomeAssistant (it's required starting 2023.5.0 version, check esphome/esphome-docs#2944 for more).

1. I'm not sure I understand the first part, lets say my two remotes are, in somfy secrets :

define SOMFY_REMOTE_ONE 0x123456

define SOMFY_REMOTE_TWO 0x654321

What would be the process to remove remote SOMFY_REMOTE_TWO for example ?

2. I haven't edited somfy_cover.h yet, and I'm running 2023.5.4, but I have the stopbutton in the UI, and it's working properly : Where you referring to something else ?