Documentation for all flags?

Site Feedback
1

Hi everyone, I was updating to the latest version using Platform IO.
I created my own *_env.ini file for further updates, but I faced some difficulties regarding the flags.

Is there a place where you list all the possible flags (like Gateway_Name=“xxx”) with the possible values, or type and the effect it has?
for exemple, using esp32, I saw the LED flags

LED_RECEIVE=LED_BUILTIN'
LED_RECEIVE_ON=LOW'
LED_INFO 
LED_RECEIVE 
LED_SEND

I couldn’t find any place where you explain the effects and also what kind of values it it supposed to take.

It would be great to have a document explaining each flag and explanation

thank you so much!

2

Hi Combatistor,

while I don’t have exhaustive answers for all your LED queries, I have found out the following so far:

• LED_SEND and LED_RECEIVE macro has been replaced by LED_SEND_RECEIVE (with release of 0.9.7)
• System commands (ESP only) | OpenMQTTGateway v0.9.9
• Disable blue led on esp32-dev - #2 by DigiH

with me using the latter to avoid the constant blue LED blinking :wink:

Hope this helps a bit.

3

Thanks for the tip!
Actually my point is not about LEDs only, just to guide more the user with his own build.
It would be great to keep everything in the docs consistent. There are not so many examples already, so when you try to understand you struggle a bit.

4

I see your point. We could have a script that retrieves all the macro along with their comment and create a .md file.

1 Like
5

That would be great!
I find the way to create your own binaries a bit confusing, so many things and so little explanation. I know you’re not really suppose to change so many things, but having more information would be useful

6

This is how I go about creating my binary environments in my personal *_env.ini file. Might help you and others, or might also encourage others to chip in with their solutions so I might get new ideas as well.

I take the environment definition from platformio.ini for the correct board and functionality I want, in this example the BLE gateway for an ESP32

[env:esp32dev-ble]
platform = ${com.esp32_platform}
board = esp32dev
board_build.partitions = min_spiffs.csv
lib_deps =
  ${com-esp.lib_deps}
  ${libraries.wifimanager32}
  ${libraries.ble}
  ${libraries.decoder}
build_flags =
  ${com-esp.build_flags}
  '-DZgatewayBT="BT"'
  '-DLED_SEND_RECEIVE=2'
  '-DLED_SEND_RECEIVE_ON=0'
  '-DGateway_Name="OpenMQTTGateway_ESP32_BLE"'

I then go through the appropriate config_*.h file, in this case config_BT.h, and read through all the comments for the various definitions there, and add the ones I want to personalise in my environment. For my setup I want

# define TimeBtwRead 55555 //define default time between 2 scans

to be 20000

and

# define pubBLEManufacturerData false // define true if you want to publish the manufacturer's data (sometimes contains characters that aren't valid with receiving client)

to be true

So I add these to the environment

[env:esp32dev-ble]
platform = ${com.esp32_platform}
board = esp32dev
board_build.partitions = min_spiffs.csv
lib_deps =
  ${com-esp.lib_deps}
  ${libraries.wifimanager32}
  ${libraries.ble}
  ${libraries.decoder}
build_flags =
  ${com-esp.build_flags}
  '-DZgatewayBT="BT"'
  '-DLED_SEND_RECEIVE=2'
  '-DLED_SEND_RECEIVE_ON=0'
  '-DTimeBtwRead=20000'
  '-DpubBLEManufacturerData=true'
  '-DGateway_Name="OpenMQTTGateway_ESP32_BLE"'

Since I have multiple environment definitions in my personal *_env.ini file, which share common definitions like using manual WiFi setup, the WiFi credentials, MQTT server details - defined in the User_config.h file … I define these at the beginning of my *_env.ini

[wifi]
build_flags =
  '-DESPWifiManualSetup=true'
  '-Dwifi_ssid="XXSSIDXX"'
  '-Dwifi_password="XXPASSWORDXX"'
  
[mqtt]
build_flags =
  '-DMQTT_SERVER="192.168.X.XX"'
  '-DMQTT_USER="XXUSERXX"'
  '-DMQTT_PASS="XXPASSWORDXX"'

and can then easily add these to all gateway environments. For the above example

[env:esp32dev-ble]
platform = ${com.esp32_platform}
board = esp32dev
board_build.partitions = min_spiffs.csv
lib_deps =
  ${com-esp.lib_deps}
  ${libraries.wifimanager32}
  ${libraries.ble}
  ${libraries.decoder}
build_flags =
  ${com-esp.build_flags}
  '-DZgatewayBT="BT"'
  '-DLED_SEND_RECEIVE=2'
  '-DLED_SEND_RECEIVE_ON=0'
  '-DTimeBtwRead=20000'
  '-DpubBLEManufacturerData=true'
  '-DGateway_Name="OpenMQTTGateway_ESP32_BLE"'
  ${wifi.build_flags}
  ${mqtt.build_flags}

Nicely building up personalised environments in the separate *_env.ini file, which can then easily be copied over to any new OMG version in the future.

The key for me was going through all the relevant config files and also diffing the config files whenever a new OMG version comes out to see what options might have changed or been added.

2 Likes
7

Thanks for sharing @DigiH your setup seems pretty similar to mine. I maintain 2 separate ini files for my setup, prod_env.ini for my production devices, and test_env.ini for my test devices. As I’m constantly playing with stuff, I lost track of the configuration of my production devices a few times.

I also use a custom version string for all my devices, Family_Room-v0.9.9beta-1-gfb93463[development], which is the ENV setting, OMG Release and branch.

Lastly, I go into the main platformio.ini and move all the release/sample environments to a separate ini file to speed up the startup of VSC. I found my older MacBook Air takes about 10 minutes to start VSC with the OMG workspace as it is prepping the environments, and by removing all the release/sample environments from the config it now starts really quickly.

PS Having automated collection of all the build/define flags sounds interesting, but would it work with external libraries ?

8

We could scan the libraries also and group the macro listing accordingly

9

Thanks for the additional tips @NorthernMan54. I’ve so far had a separate section in my ini file, but individual files should probably be cleaner and more manageable.

Removing all the environments in platformio.ini isn’t really necessary for a faster VSC startup on my main setup, but it surely makes the project tasks list a lot clearer :slight_smile:

@1technophile - Sounds like a great idea to then have all the definitions in one place in the documentation.

10

Humm

grep "define" * | grep -v defined | wc
738 4648 47275

738 rows…

grep "define" * | grep -v defined | awk -F: '{ print $1 }' | sort | uniq -c

145 User_config.h
2 ZactuatorFASTLED.ino
1 ZgatewayBLEConnect.h
1 ZgatewayBLEConnect.ino
13 ZgatewayBT.ino
13 ZgatewayIR.ino
3 ZgatewayRFM69.ino
1 ZgatewayRS232.ino
7 ZmqttDiscovery.ino
17 config_2G.h
5 config_ADC.h
6 config_AHTx0.h
4 config_BH1750.h
5 config_BME280.h
37 config_BT.h
10 config_DHT.h
11 config_DS1820.h
43 config_FASTLED.h
4 config_GFSunInverter.h
7 config_GPIOInput.h
10 config_GPIOKeyCode.h
10 config_HCSR04.h
8 config_HCSR501.h
6 config_HTU21.h
3 config_INA226.h
137 config_IR.h
19 config_LORA.h
8 config_M5.h
11 config_ONOFF.h
8 config_PWM.h
35 config_RF.h
24 config_RFM69.h
18 config_RS232.h
10 config_SHTC3.h
19 config_SRFB.h
5 config_Somfy.h
4 config_TSL2561.h
6 config_WeatherStation.h
42 config_mqttDiscovery.h
10 main.ino
10 zzHTTPUpdate.h

11

With an automated parser, would need to have comments added to each that would be used as a description in the documentation.

12

Yes we will need some structure for the comments so as to have them retrieved properly, not sure if some tools like Doxygen can do this