Receive frequency is available as a compiler directive and as real time command.
Could you please show an example of ini file?
In the codebase, the compiler directive is here
And in your ini it would be a build_flag
‘-DCC1101_FREQUENCY=433.92’
I’ve just received what appears to be the same board from aliexpress. The “Upload from the Web” appears to work correctly, I get the “Connect your phone…” prompt, connect and get the setup page, but it resets after a minute or two before I can complete the wifi setup.
Any ideas why or if there’s a way around this?
@billschs I’m not a expert on that method of setting the WIFI credentials, if you try again and enter the information quickly does that work ?
I looked at the code and you have 120 seconds until the screen times out.
120 seconds isn’t really enough time. It starts counting as soon as it puts up the wifi access point. Takes time for it to show up on the phone or tablet, then to open the settings page. I’ve almost completed the form using the tablet (large buttons allow faster typing), but it still isn’t enough time. I was hoping there was some command to modify the configuration after I’d gotten the access point and password entered. Haven’t had enough time to get past choosing the access point, setting the password, and entering the server IP.
We may need to increase this. As a workaround I would suggest to copy/paste the longest string to earn some time.
I don’t understand why there’s a timeout at all. As this is a first boot setup, I would think that hitting the reset or unplugging-replugging would serve the same purpose.
During normal operation, if we don’t have a Wifi connection at the start, the WifiManager portal is triggered. This could happen either during a change of Wifi credentials by the user, an electrical outage, a router stopped, change…
Instead of having the ESP stuck into a reboot loop, we trigger the portal (as not all ESP have a button to leverage the reset credential function) to enable users to change the credentials.
The timeout enables a wifi connection after the wifi manager portal triggers again. This enables us to cover the use cases related to a temporary stop on which we need the gateway to reconnect.
The impact of removing this timer will be to have users stuck in case of a change of Wifi/MQTT credentials outside of the gateway and have to reconnect the gateway to a USB port.
The impact of increasing this time will be more time for the users to set up credentials but also a longer reconnection time in case of disconnections.
Ok, that makes sense. Is there any way to use the USB serial interface to change behavior or for setup? When I fire up terminal software I can see what the board is doing, but it doesn’t appear to look at the port for any input.
The best way to change the behavior would be through platformio by adding this macro to an environment:
'-DWifiManager_ConfigPortalTimeOut=180'
180 being the time.of the portal in seconds
Thanks for the assist. As I’m now building it instead of using the binary I’ll just set things the way I want them in User_config.h. Originally thought I might get away with not having to build it as VSC on linux doesn’t always play nice with me. 
1 Like
Hmm, as I said, VSC doesn’t like me. Did a git clone of the current code, added a prod_env.ini with:
[platformio]
default_envs = lilygo-rtl_433
Edited User_config.h to set SSID/password, gateway, etc. Set mqtt host IP, username/password.
Builds & uploads, boots, connects to mqtt server, sends regular status messages, but doesn’t seem to see any of the 433 MHz devices. Serial monitor shows this:
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
N:
************* WELCOME TO OpenMQTTGateway **************
N: OpenMQTTGateway Version: version_tag
N: WiFi ok with manual config credentials
N: OpenMQTTGateway modules: []
N: ************** Setup OpenMQTTGateway end **************
W: MQTT connection…
N: Connected to broker
N: Send on /SYStoMQTT msg {“uptime”:8,“version”:“version_tag”,“freemem”:261716,“mqttport”:“1883”,“mqttsecure”:false,“tempc”:55,“freestack”:6072,“rssi”:-41,“SSID”:“CPRAD1”,“BSSID”:“9C:3D:CF:D0:F0:30”,“ip”:“10.1.10.24”,“mac”:“0C:8B:95:A9:EA:54”,“modules”:[]}
Does VSC hate me or did I do something silly?
The clue is here - N: OpenMQTTGateway modules: []
This is normally populated with the configured gateway modules
Am thinking that your default_envs = lilygo-rtl_433 is not being recognized.
You may want to copy the lilygo-rtl_433 environment ( and rename ) to your prod_env.ini
PS In my setup I try to avoid playing with User_config.h, and run an prod_env.ini to include all the settings
I agree with @NorthernMan54 here, once you copy the lilygo-rtl_433 environment ( and rename ) to your prod_env.ini add the following build_flags:
'-DESPWifiManualSetup=true'
'-Dwifi_ssid="YOURSSID"'
'-Dwifi_password="YOURPASSWORD"'
'-DMQTT_SERVER="192.168.XX.XX"'
'-DMQTT_USER=""'
'-DMQTT_PASS=""'
'-DMQTT_PORT="1883"'
to set your WiFi and MQTT credentials.
This way you can also carry your whole environment settings over to future new versions of OMG without always having to fiddle with the User_config.h again.
Yes. Messed up prod_env.ini. Found my problem and fixed. Also did as @DigiH suggested and 'git restore’d User_config.h, putting all the changes into build flags. Am a bit close now, as the rtl_433 modules are being setup:
N: ZgatewayRTL_433 setup done
N: Switching to RTL_433 Receiver: 433.92Mhz
N: OpenMQTTGateway modules: [“LilyGo_SSD1306”,“rtl_433”]
N: ************** Setup OpenMQTTGateway end **************
W: MQTT connection…
N: Connected to broker
N: Send on /SYStoMQTT msg {“uptime”:11,“version”:“version_tag”,“freemem”:159320,“mqttport”:“1883”,“mqttsecure”:false,“tempc”:54.44444,“freestack”:4696,“rssi”:-38,“SSID”:“CPRAD1”,“BSSID”:“9C:3D:CF:D0:F0:30”,“ip”:“10.1.10.169”,“mac”:“0C:8B:95:A9:EA:54”,“actRec”:3,“mhz”:433.92,“RTLRssiThresh”:-82,“RTLRssi”:-119,“RTLAVGRssi”:0,“RTLCnt”:0,“RTLOOKThresh”:90,“modules”:[“LilyGo_SSD1306”,“rtl_433”]}
but still end up with everything connected and no rtl_433 data.
Can you post your whole individual renamed lilygo-rtl_433 environment - passwords etc. XXed out of course - and let us also know how you then build and upload it?
It’s all in prod_env.ini. I get the same result whether or not I copy the lilygo-rtl_433 env here or just let it pull from environments.ini.
; Build overrides
[platformio]
; without the following EVERYTHING gets built
default_envs = lilygo-rtl_433
; exact copy of lilygo-rtl_433 from environments.ini
platform = ${com.esp32_platform}
board = ttgo-lora32-v21
; ~/.platformio/packages/framework-arduinoespressif32/variants/…/pins_arduino.h
board_build.partitions = min_spiffs.csv
lib_deps =
${com-esp.lib_deps}
${libraries.wifimanager32}
${libraries.ssd1306}
${libraries.rtl_433_ESP}
build_flags =
${com-esp.build_flags}
; *** OpenMQTTGateway Config ***
;‘-UZmqttDiscovery’ ; disables MQTT Discovery
‘-DvalueAsATopic=true’ ; MQTT topic includes model and device
‘-DGateway_Name=“OpenMQTTGateway_lilygo_rtl_433_ESP”’
; *** OpenMQTTGateway Modules ***
‘-DZgatewayRTL_433=“rtl_433”’
‘-DZradioSX127x=“SX127x”’
; *** ssd1306 Display Options ***
‘-DZdisplaySSD1306=“LilyGo_SSD1306”’
; ‘-DLOG_TO_LCD=true’ ; Enable log to LCD
; ‘-DJSON_TO_LCD=true’
; ‘-DLOG_LEVEL_LCD=LOG_LEVEL_NOTICE’
; ‘-DDISPLAY_IDLE_LOGO=false’
; ‘-DDISPLAY_METRIC=false’
custom_description = For ESP32, Gateway using RTL_433_ESP and RadioLib
custom_hardware = ESP32 LILYGO LoRa32 V2.1
; my local defines
‘-DGateway_Name=“OpenMQTTGateway”’
‘-DESPWifiManualSetup=true’
‘-Dwifi_ssid=“XXXX”’
‘-Dwifi_password=“XXXXXXXXXX”’
‘-DMQTT_SERVER=“10.1.10.23”’
‘-DMQTT_USER=“XXXXXX”’
‘-DMQTT_PASS=“XXXXXXXX”’
‘-DMQTT_PORT=“1883”’
I personally do away with default_envs, as I prefer using the Platformio Project Tasks on the left side of VSC - the little alien icon - PROJECT TASKS.
You could also comment out line 16 in Platformio.ini
; environments.ini
to only show your personal environments in the project tasks.
Then in your personal prod_env.ini you should have your one complete environment, like
[env:lilygo-rtl_433_MINE]
platform = ${com.esp32_platform}
board = ttgo-lora32-v21
; ~/.platformio/packages/framework-arduinoespressif32/variants/.../pins_arduino.h
board_build.partitions = min_spiffs.csv
lib_deps =
${com-esp.lib_deps}
${libraries.wifimanager32}
${libraries.ssd1306}
${libraries.rtl_433_ESP}
build_flags =
${com-esp.build_flags}
; *** OpenMQTTGateway Config ***
;'-UZmqttDiscovery' ; disables MQTT Discovery
'-DvalueAsATopic=true' ; MQTT topic includes model and device
'-DGateway_Name="OpenMQTTGateway_lilygo_rtl_433_ESP"'
; *** OpenMQTTGateway Modules ***
'-DZgatewayRTL_433="rtl_433"'
'-DZradioSX127x="SX127x"'
; *** ssd1306 Display Options ***
'-DZdisplaySSD1306="LilyGo_SSD1306"'
; '-DLOG_TO_LCD=true' ; Enable log to LCD
; '-DJSON_TO_LCD=true'
; '-DLOG_LEVEL_LCD=LOG_LEVEL_NOTICE'
; '-DDISPLAY_IDLE_LOGO=false'
; '-DDISPLAY_METRIC=false'
'-DESPWifiManualSetup=true'
'-Dwifi_ssid=“XXXX”'
'-Dwifi_password=“XXXXXXXXXX”'
'-DMQTT_SERVER=“10.1.10.23”'
'-DMQTT_USER=“XXXXXX”'
'-DMQTT_PASS=“XXXXXXXX”'
'-DMQTT_PORT=“1883”'
then in the PROJECT TASKS you should only (if you commented out the environments.ini line) see env:lilygo-rtl_433_MINE expand it with the > and select Build, then Upload.
If you are using a user and password and SSL for your MQQT broker you might have to set the port to 8883.
Trying to figure out what happened here.
Just to make sure that the hardware was still behaving, I loaded the prebuilt binary from the web again, copying and pasting the settings so I got the important ones changed before it timed out. Came up fine.
Went back to the local folder, used git to confirm everything matched the files on github except my custom .ini, to which I’d added ‘.disabled’ so it wouldn’t get picked up. Built just the rtl_433 version using Project Tasks per @DigiH , installed that and it came up working WITHOUT my entering the credentials. I assume the related object file was up to date and didn’t rebuild?
Then re-enabled my custom .ini by removing the ‘.disabled’ from it’s name, rebuilt again using Project Tasks and everything is working just fine.
Puzzled at this point, but happy it’s working. I did notice that the default build didn’t define OMG_VERSION (it comes up saying “OpenMQTTGateway Version: version_tag”), so I added the definition. Just happy it works, but not sure why it didn’t work before. Wild guess is I’d probably fixed the problem earlier but didn’t clean the build environment so not everything recomplied.
In any case, many thanks to all for the assistance getting this working.
3 Likes