Error during compiling!

[2225damjaich42]

Hi. Something went wrong during the custom component installation. I get an error message:

Compiling /data/ds-heater/.pioenvs/ds-heater/src/main.cpp.o src/main.cpp:22:1: error: 'q7rf' does not name a type q7rf::Q7RFSwitch *q7rf_q7rfswitch; ^ src/main.cpp: In function 'void setup()': src/main.cpp:217:3: error: 'q7rf_q7rfswitch' was not declared in this scope q7rf_q7rfswitch = new q7rf::Q7RFSwitch(); ^ src/main.cpp:217:25: error: expected type-specifier before 'q7rf' q7rf_q7rfswitch = new q7rf::Q7RFSwitch(); ^ src/main.cpp:217:25: error: expected ';' before 'q7rf' *** [/data/ds-heater/.pioenvs/ds-heater/src/main.cpp.o] Error 1

[2225damjaich42]

--

[baltov]

I solved it as: rename switch.py -> init.py remove line 352 in q7rf.cpp //ESPLOGCONFIG(TAG, " CC1101 CS Pin: %u", this->cs->get_pin()); Now I can install it

[2225damjaich42]

Thank you for your work! I can not rename the switch.py to init.py because during the compiing the q7rf service is missing, but i have created a new emty file (init.py), and it worked. Now i really can compile it, and i see the switch in HASSIO, but now i cant check the cc1101s states. I think because we delete the logger config line. And somehow the pairing service is still missing. Without it i cant pair the transciever with the furnace.........

[nistvan86]

Sorry, for some reason I didn't get any notifications for this issue.

It's very likely ESPHome's API changed and the declaration of custom components works differently now. The last known version I was tested is 1.15.3 as mentioned in the readme which is over a year old now. I need to upgrade my devices at one point, but haven't got the time to do so. I was planning to update this component then. If you are in hurry, you might want to compile a device firmware with this older ESPHome version. You can grab an older release from Docker Hub: docker pull esphome/esphome:1.15.3

The Python file is essential since it describes the parameters of this component so the ESPHome native firmware code generator knows how to translate the YAML section to native C++ calls. My assumption is that this was reworked at some point.

[nistvan86]

Committed an update onto the main branch which fixes compatibility with ESPHome v2021.10.3. https://github.com/nistvan86/esphome-q7rf/commit/f91331e8a89d1b68103d6d03b6caafb76c1aabe8 Please pull and try again.

[2225damjaich42]

I am really grateful for your work! Now i can pull the code, and the new switch showed up in HA, but after switching it on, nothing happening. :( The logging only show the switch turn on lines, and that is all. No lines in connenctions with the cc1101 module. Another problem is, that the native API service not showing up in HA, and without it, i can't really do anything.

I tried with 2 different rf module, and different nodemcu-s, but the effect is the same. In the next days, i will try on a different hardware, maybe it wil help.

[nistvan86]

The pairing service registration doesn't happen if the CC1101 cannot be initialized. Those lines should be at the top of the log where the configuration is listed.

[msuvar]

Thank you for your work! I can confirm that now I am able to install the code, the new switch is now visible in HA, but there is no communication from CC1101 and no Q7RF service in Developer mode, in order to try the pairing. If I toggle the switch, only this line appears in ESPHome log: [22:16:57][D][switch:013]: 'Q7RF switch' Turning ON.

The other lines (with Sending state, Handling prioritized message and Sending message) does not appears in the log. I am using a Wemos D1 mini board, but the GPIO pins are the same with the ones on the NodeMCU board. Can you check where is the problem, in the code?

[msuvar]

This is my ESPHome log, maybe it will help you to debug the issue... Many thanks again!

INFO Reading configuration /config/esphome/q7rf.yaml... INFO Starting log output from q7rf.local using esphome API INFO Successfully connected to q7rf.local [22:16:35][I][app:099]: ESPHome version 2021.10.2 compiled on Nov 8 2021, 19:54:43

[22:16:35][C][wifi:352]: Local MAC: 68:C6:3A:F4:B1:B0 [22:16:35][C][wifi:353]: SSID: [redacted] [22:16:35][C][wifi:354]: IP Address: 192.168.0.137 [22:16:35][C][wifi:356]: BSSID: [redacted]

[22:16:35][C][wifi:359]: Signal strength: -53 dB ▂▄▆█ [22:16:35][C][wifi:363]: Channel: 11 [22:16:35][C][wifi:364]: Subnet: 255.255.255.0 [22:16:35][C][wifi:365]: Gateway: 192.168.0.1 [22:16:35][C][wifi:366]: DNS1: 78.96.7.88 [22:16:35][C][wifi:367]: DNS2: 95.77.94.88 [22:16:35][C][spi:101]: SPI bus: [22:16:35][C][spi:102]: CLK Pin: GPIO14 [22:16:35][C][spi:103]: MISO Pin: GPIO12 [22:16:35][C][spi:104]: MOSI Pin: GPIO13 [22:16:35][C][spi:106]: Using HW SPI: YES

[22:16:35][C][logger:234]: Level: DEBUG [22:16:35][C][logger:235]: Log Baud Rate: 115200 [22:16:35][C][logger:236]: Hardware UART: UART0

[22:16:35][C][q7rf.switch:354]: CC1101 CS Pin: 15 [22:16:35][C][q7rf.switch:356]: Q7RF Device ID: 0x6ed5 [22:16:35][C][q7rf.switch:357]: Q7RF Resend interval: 60000 ms [22:16:35][C][captive_portal:150]: Captive Portal: [22:16:35][C][ota:082]: Over-The-Air Updates: [22:16:35][C][ota:083]: Address: q7rf.local:8266 [22:16:35][C][ota:086]: Using Password. [22:16:35][C][api:134]: API Server: [22:16:35][C][api:135]: Address: q7rf.local:6053 [22:16:35][C][api:139]: Using noise encryption: NO [22:16:57][D][switch:013]: 'Q7RF switch' Turning ON. [22:17:47][D][switch:013]: 'Q7RF switch' Turning ON. [22:18:24][I][ota:102]: Boot seems successful, resetting boot loop counter.

[2225damjaich42]

Yesterday somehow i solved it... I don't know how exatly, but doesn't matter. First i needed to compile the sketch from python enviroment (Yesterday morning, i wasn' know exatly what is it... :) ), where i saw that something went wrong with the cc1101 module. There was an error about the version number, and the partnum section. After searching on google about that issue, i find that the chip version changed from 0x14 to 0x04. I don't know what that mean, but i changed the the version number on line 19, 41, and 53 in the q7rf.cpp file. After that the cc1101 module resetted succesfully, and it can send the proper signals when i turned off/on the switch. The next issue was with the pairing process. It appered in the developers tools services, but there was an error during the calling. It was because of the switch name. Can not register the service if the name has a '-' caracter in it. I shortened the name, and everything is working as should. Thank you again nistvan86 for your work, and your help with my issues!!!!!

[nistvan86]

Glad to hear it's working now.

There's someone I'm exchanging mails who had similar issues (chip version was different and had to remove the check; service name seems to have a required format in HA which can become non callable if the node name contains illegal characters). I'm trying to make these better in the next version (probably just dump the version number and part number into the log but don't expect anything; I'll also check how can I correctly register the pairing service so it won't depend on the naming). Until that I leave this open.

Out of curiosity, which thermostat brand and type you had success with?

[2225damjaich42]

It is a Q8RF with 2 thermostat. I've paired only one.

[nistvan86]

Released a new version on the main branch which hopefully solves all these issues.

Also took the opportunity to reorganize the repository so it's now compatible with the external components definition of ESPHome, so it's not necessary anymore to manually clone the git repository (check the readme section for an example).

The previous version is accessible on a tag if needed: 2021-11-04