Open MrBLJ opened 1 year ago
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)
Mhh, looking at d1mini pinout d8 is the correct csn and not sure how to change that
oooh, wait, d1 mini is a 8266, right? that doesn't have NVS! you need to use a different storage
(and I pushed a change for the deprecation warning, but that's just that, a waning)
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.
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
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 :
Continuing my investigation. I've tried :
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.
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.
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.
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 ?
@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.
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!
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
The emitted signal seems to be centered on 433.45MHz :
Could this be an issue ?
I'll try tweaking the command to try sniffing the packages.
Current wiring :
I have a doubt about D2 and D4. Could anyone confirm it's correct ?
@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.
@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.
Hi @grigorgeous. Thanks a lot for your insights !
Hi @grigorgeous. Thanks a lot for your insights !
- 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.
- 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?
Well, we're definitely going somewhere. Remote is operationnal. So far, here is what I can confirm :
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 .
@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.
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).
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.
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).
What would be the process to remove remote SOMFY_REMOTE_TWO for example ?
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 :
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 :
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 ?