duplicate decoder.h when building both BT and RTL_433
Describe the bug Building with enabled BT and RTL_433 fails. The errors start with
...OpenMQTTGateway/main/ZgatewayBT.ino:57:1: error: 'TheengsDecoder' does not name a type; did you mean 'UseExtDecoder'?
TheengsDecoder decoder;
According me, the root cause is that both the libraries TheengsDecoder and rtl_433_ESP are using decoder.h
To Reproduce Steps to reproduce the behavior:
- Prepare environment, which builds both BLE (with internal decoding - should be the default, if not explicitly set to use external decoder) and RTL_433. Like the snippet from this: extract of the environment definition
[com]
esp32_platform = [email protected]
[platformio]
default_envs = btrtl
[env:btrtl]
platform = ${com.esp32_platform}
board = esp32dev
board_build.partitions = partitions/min_spiffs.csv
lib_deps =
${com-esp32.lib_deps}
${libraries.ble}
${libraries.smartrc-cc1101-driver-lib}
${libraries.rtl_433_ESP}
${libraries.decoder}
build_flags =
${com-esp32.build_flags}
'-DPRIVATE_CERTS="true"'
'-DZgatewayRTL_433="rtl_433"'
'-DZradioCC1101="CC1101"'
'-DRF_CC1101="CC1101"'
'-DRF_MODULE_GDO0=12'
'-DRF_MODULE_GDO2=27'
'-DZgatewayBT="BT"'
- Observe the beginning of the errors
...OpenMQTTGateway/main/ZgatewayBT.ino:57:1: error: 'TheengsDecoder' does not name a type; did you mean 'UseExtDecoder'?
TheengsDecoder decoder;
Expected behavior Successful build
Environment (please complete the following information):
- OpenMQTTGateway version used development
- Library version related to the problem - described in platformio.ini decoder and rtl_esp_433
Additional context Renaming the decoder.h in TheensgDecoder library lead to successful build. The steps to rename are:
- define platform like this (use different from decoder library name, and point to the modified TheengsDecoder source) in this example environment definition, the name of the decoder library is changed to BLEdecoder, and the modified TheengsDecoder is in local path :
[com]
esp32_platform = [email protected]
[platformio]
default_envs = btrtl
[libraries]
BLEdecoder = symlink:///tmp/decoder
[env:btrtl]
platform = ${com.esp32_platform}
board = esp32dev
board_build.partitions = partitions/min_spiffs.csv
lib_deps =
${com-esp32.lib_deps}
${libraries.ble}
${libraries.smartrc-cc1101-driver-lib}
${libraries.rtl_433_ESP}
${libraries.BLEdecoder}
- Change forked TheengsDecoder to rename decoder.h to BLEdecoder.h I renamed like the commit message in this commit https://github.com/peshovec/OpenMQTTGateway/commit/4d7d7de3679c8809f1bdf7f2ac1a58dd8f63b520
- In OpenMQTTGateway change main/ZgatwayBT.ino to include the renamed BLEdecoder.h (as per the mentioned commit)
And the next thing you will discover is the with BLE and rtl_433 together you don't have enough resources for both :(
Same as https://github.com/1technophile/OpenMQTTGateway/issues/1652
Apologize - missed the existing issue. @NorthernMan54 although still not uploaded (waiting the arrival of the cc1101 module), already hit the resource constrains:) Not enough flash:) And i had to tweak the partition table. Even now (without rtl_433, just with BLE, RF, RF2 and pilihght) i am already in the instability zone. For example the web ui is not working. If i have to look at the web console i had to disable the BT (via mqtt publish) Eventually i will leave just the modules i need. Right now i am still exploring, so having to disable module at runtime is acceptable in my case.
This may be feasible if LilyGo or another manufacturer add a sx127x chip to one of these
This is the latest thing I’m playing with. It has 8mb of psram so the dual should be doable
PS - the screen is this project https://github.com/NorthernMan54/esp32_balboa_spa/tree/LVGL-4848S040CIY1
Is #1529 related?
This issue is stale because it has been open for 90 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.