Compile fails saying the pin in the lambda isn't defined
Windyo opened this issue · comments
I might just not be great at this, sorry.
Steps Followed
- downloaded https://github.com/dbuezas/esphome-cc1101/blob/main/cc1101.h
- put it in the /config/esphome/
- added ESP32 board to ESPHome
- added content from YAML to config file
- renamed elements as we're not using the same board.
YAML
esphome:
name: esphome-web-dde34c
friendly_name: ESPHome - Faro Radio
includes:
- cc1101.h
libraries:
- SPI
- "SmartRC-CC1101-Driver-Lib"
esp32:
board: esp32doit-devkit-v1
framework:
type: arduino
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "REDACTED"
ota:
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Esphome-Web-Dde34C"
password: "muD8LhuLQ3Qp"
sensor:
- platform: custom
lambda: |-
auto my_sensor = new CC1101(
GPIO18, // SCK
GPIO19, // MISO
GPIO23, // MOSI
GPIO5, // CSN
GPIO13, // GDO0
200, // bandwidth_in_khz
303.875 // freq_in_mhz
);
App.register_component(my_sensor);
return {my_sensor};
sensors:
id: transciver
internal: true
remote_transmitter:
- pin: GPIO13 # This is GDO0
carrier_duty_percent: 100%
remote_receiver:
- pin: GPIO13 # 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
binary_sensor:
- platform: remote_receiver
name: Garage
raw:
code: [415,-300,370,-300,375,-300,378,-300,378,-300,379,-300,405]
button:
- platform: template
name: Garage
on_press:
- lambda: get_cc1101(transciver).beginTransmission();
- remote_transmitter.transmit_raw:
code: [415,-300,370,-300,375,-300,378,-300,378,-300,379,-300,405]
- lambda: get_cc1101(transciver).endTransmission();
I can't get the file to compile, it fails after a minute or so complaining for example "error: 'GPIO18' was not declared in this scope".
Any help appreciated.
Error Log
/config/esphome/esphome-web-dde34c.yaml: In lambda function:
/config/esphome/esphome-web-dde34c.yaml:39:9: error: 'GPIO18' was not declared in this scope
GPIO18, // SCK
^~~~~~
/config/esphome/esphome-web-dde34c.yaml:39:9: note: suggested alternative: 'GPIO'
GPIO18, // SCK
^~~~~~
GPIO
/config/esphome/esphome-web-dde34c.yaml:40:9: error: 'GPIO19' was not declared in this scope
GPIO19, // MISO
^~~~~~
/config/esphome/esphome-web-dde34c.yaml:40:9: note: suggested alternative: 'GPIO'
GPIO19, // MISO
^~~~~~
GPIO
/config/esphome/esphome-web-dde34c.yaml:41:9: error: 'GPIO23' was not declared in this scope
GPIO23, // MOSI
^~~~~~
/config/esphome/esphome-web-dde34c.yaml:41:9: note: suggested alternative: 'GPIO'
GPIO23, // MOSI
^~~~~~
GPIO
/config/esphome/esphome-web-dde34c.yaml:42:9: error: 'GPIO5' was not declared in this scope
GPIO5, // CSN
^~~~~
/config/esphome/esphome-web-dde34c.yaml:42:9: note: suggested alternative: 'GPIO'
GPIO5, // CSN
^~~~~
GPIO
/config/esphome/esphome-web-dde34c.yaml:43:9: error: 'GPIO13' was not declared in this scope
GPIO13, // GDO0
^~~~~~
/config/esphome/esphome-web-dde34c.yaml:43:9: note: suggested alternative: 'GPIO'
GPIO13, // GDO0
^~~~~~
GPIO
/config/esphome/esphome-web-dde34c.yaml:48:24: error: could not convert '{my_sensor}' from '<brace-enclosed initializer list>' to 'std::vector<esphome::sensor::Sensor*>'
return {my_sensor};
^
*** [/data/esphome-web-dde34c/.pioenvs/esphome-web-dde34c/src/main.cpp.o] Error 1
========================= [FAILED] Took 532.71 seconds =========================
OK, I think I have it figured out because the logs get filled with data.
For anyone trying this, the lambda function doesn't need the "GPIO" prefixes, and as such you can just pass
18, // SCK
19, // MISO
23, // MOSI
5, // CSN
13, // GDO0
200, // bandwidth_in_khz
303.875 // freq_in_mhz
);
I'm having other issues with what I want to do but that's another subject.
Going further it looks like my above assumption was wrong.
In the case of my board (ESP32 DevKit V1), the GPIO pin numbers and the actual pin numbers don't align.
If I assume that cc1101.h takes in pin number as a var, I gotta update the values to be the actual pin numbers.
That would explain the completely erratic behavior I saw earlier today.
SchematicsforESP32.pdf
I'll update tomorrow if I get this working.
Alright so good news, it compiles now.
Bad news, I see no data whatsoever that makes any sense. I'll re read the spec again and see wtf i'm doing wrong, but if someone comes across this and has an idea please ping me :D
Hey, it looks like you are really close already!
Sorry I can't help, I haven't used this with an esp32 yet.
Are you sure the frequency is correct? Where did you get the raw codes from?
Consider that he cc1101 boards are optimized for specific frequencies (the ones I saw 433 or 868). Too far from that and the signal strength will be weak
Hey, for now I'm not sure of anything, I don't see anything that makes sense in the logs. Literally I see the transciver sending data for no reason, and receiving stuff that isn't correlated with what I expect at all.
TBH I'm wondering if the pins I set are correctly ingested during compile.
The cc1101 I have is branded 404, but according to another reddit user they used it for the same purpose as I did without issues, so I'm focusing on that.
Let's just say that if I get the code compiled, and information I can make sense out of, I consider this a success. If it works, it's even better, but it's a bonus.
Try selecting the right board in the platform (e.g lolin-s2-mini) so the pin numbers are correctly mapped. Then you can use the numbers as written in the silk layer (just the number without "gpio" prefix
I think it's the right board (I checked the reference, a few pictures, etc). It's not the same provider, the listed board is by DO-IT and mine is from SP-COW, but all pins and outputs look the exact same.
I updated the numbers to the new target values and am currently compiling again, i'll update midday when I've had a chance to try a few things.
Thanks for the pointer and the links.
Alright, good news bad news time.
Good news - I'm sure I have the wiring right, because I got the idea to find the pin aliases
https://github.com/espressif/arduino-esp32/blob/master/variants/doitESP32devkitV1/pins_arduino.h
Which means for anyone that is using my board, the code is
code mapping
lambda: |-
auto my_sensor = new CC1101(
SCK, // SCK
MISO, // MISO
MOSI, // MOSI
SS, // CSN
A17, // GDO0
600, // bandwidth_in_khz
303.87 // freq_in_mhz
);
App.register_com
The bad news is I don't see anything at all on the receiver, so I'm going to have to play with options a bit and see if I can at least see something at 433Mhz as that's what the radio is meant for originally, and if yes, i'll see if I can get it working with 333.
Note that pin A17 can be pretty much anything as long as it complies with board requirements. I chose A17 because originally it was D13 for the Somfy ones, but that ended up being a touch pin.
Try the advanced yaml, you can change freq and bandwidth on the fly and see the rssi live
Yeah that's what I'm doing now - I had used it, except it didn't show any swtiches in Home Assistant, so I'm reocmpiling from scratch. I noticed ESPHome has a tendency to not factor in all changes if you don't force it to start over clean.
I'll update tomorrow. thanks for the help.
OK i'm really confused.
This is my YAML.
esphome:
name: esphome-web-dde34c
friendly_name: ESPHome - Faro Radio
includes:
- cc1101.h
libraries:
- SPI
- "SmartRC-CC1101-Driver-Lib"
esp32:
board: esp32doit-devkit-v1
framework:
type: arduino
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "RQ7s2V/M8ZCRUjH8Sy1fAyzcfktbfFCH8XCgsz2I41g="
ota:
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Esphome-Web-Dde34C"
password: "muD8LhuLQ3Qp"
sensor:
- platform: custom
lambda: |-
auto my_sensor = new CC1101(
SCK, // SCK
MISO, // MISO
MOSI, // MOSI
SS, // CSN
A17, // GDO0
600, // bandwidth_in_khz
303.87 // freq_in_mhz
);
App.register_component(my_sensor);
return {my_sensor};
sensors:
id: transciver_1
name: "RSSI"
unit_of_measurement: dBm
entity_category: diagnostic
# you can have multiple transcivers in the same board
# with more than 2, an esp8266 will get out of RAM. You'll need to remove the logger and reduce the recevier buffer size to 200
number:
- platform: template
max_value: 812
min_value: 58
step: 1
mode: slider
optimistic: true
unit_of_measurement: "kHz"
name: BW
on_value:
then:
- lambda: get_cc1101(transciver_1).setBW(x);
- platform: template
# min_value: 300
# max_value: 348
min_value: 303.875
max_value: 464
# min_value: 799
# max_value: 928
step: .001
mode: box
optimistic: true
unit_of_measurement: "MHz"
name: FREQ
on_value:
then:
- lambda: get_cc1101(transciver_1).setFreq(x);
switch:
- platform: template
name: "RSSI"
entity_category: diagnostic
lambda: return get_cc1101(transciver_1).rssi_on;
turn_on_action:
lambda: get_cc1101(transciver_1).rssi_on = true;
turn_off_action:
lambda: get_cc1101(transciver_1).rssi_on = false;
remote_transmitter:
- id: transmitter_1
pin: A17 # This is GDO0
carrier_duty_percent: 100%
remote_receiver:
- id: receiver_1
pin: A17 # 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:
- rawI don't see any configuration options in HA at all whatsoever, though. Did I do something wrong ?
Please edit the post and format the yaml using ```yaml
done
NVM, turns out my instance was slow updating, I see the fields now =="
I'm still getting TONS of noise though.
I will look at this again tomorrow with the objective of loering noise so I can more easily determine what the codes of the remote are (if I do in fact detect them)
Thanks for your help.
It's extremely hard to find the right signal in a noisy environment. This visualizer tool makes it a bit easier:
https://github.com/dbuezas/esphome-remote_receiver-oscilloscope
I'm going to close this issue because the original problem is solved and I feel the documentation I provided enables future users to solve it the same way I did. I'll open another issue regarding my use case, which to be honest is probably not linked to your implementation of the library, but maybe you can help. :)