List of Config options that users can define

[aviateur17]

From PR #216:

"My idea: I think we should start a list of configs that the user can define. Then we can add a quick bit of documentation to the config file about how local vs. global configs work, as well as the list of configs that can be defined locally. Then I'd like to condense the configs a bit and remove seldom-used options like the MQTT topics and static IP configs (they'll be moved to the list), plus move the WiFi credentials and MQTT info closer to the top. I'll think about the blurb and try to get those changes submitted in the next couple days."

[DangarStu]

As a new user I give this a bit thumbs up and would love to help. I'm going to start a tutorial document that can hopefully live in the Wiki to help other new users but I believe a bit of a refactor of the user-configurable options would be great too. For example, I believe (I could be wrong!) the follow to configurations are very similar in their function, but very different in their naming:

#define GTWY_MAC 0x03 //Address of the nearest gateway

and

#define LORA_NEIGHBOR_1 0x00 // Address of LoRa neighbor #1

I get that sensors and gateways have different roles but it's amazing how much little things like this can throw a complete new user.

Another thing I've been doing is making a document with all the correct settings for my different ESP devices. Is there currently any mechanism to contribute these to a separate include file named after the device and then just include the device you have rather than manually configuring all the pins? It would be great to crowd source a library of device configurations to live in the project.

Stu

[aviateur17]

Could consolidate all the lines with pin definitions into one section of the conf file and then surround the lines with #ifndef/#endif as example below:

#ifndef PINCONF

#define LORA_SS    GPIO_NUM_NC
#define LORA_RST   GPIO_NUM_NC
#define LORA_DIO   GPIO_NUM_NC
#define LORA_BUSY  GPIO_NUM_NC

...

// UART data interface pins (if available)
#define RXD2 GPIO_NUM_1
#define TXD2 GPIO_NUM_2

#endif

Then supply other conf files for each board and in those conf files #define PINCONF so that those lines are used instead of the files in the node_conf or gateway_conf file.

board pin config file could be called something like
pin_hallard_shield_conf.h

Would contain all the default pin definitions for the Hallard Shield and thus replace the pin definitions in the node_conf or gateway_conf file.

Hope that makes sense.

[timmbogner]

@aviateur17 First off, thanks for breaking this out to its own topic... I was obviously a bit optimistic about my time-frame in the original comment.
The folks who make RadioLib have started RadioBoards, a project to catalog configurations for specific LoRa boards. If possible, I think it would make sense for us to try to incorporate this library into FDRS before starting our own database. I know this only covers SPI configs and not I2C and UART. My thought is to either A) Dig deep into how Arduino saves pin assignment macros in the board definitions and try to get the other pin number from those, or B) Maintain our own list but still use RadioBoards for the LoRa pins.

@DangarStu Again, I really appreciate nuanced feedback about confusing aspects of the project! I've thought about the term "MAC" being a little off-putting for some users. It makes (limited) sense to anyone already familiar with networking, but I assume it's gibberish to a lot of newcomers. Also, when I named GTWY_MAC I was at a point in the project where I was more concerned about brevity in naming my macros. Around when I implemented the macro names like LORA_NEIGHBOR_1 I had given up of saving time/space in the interest of clarity. It would definitely make sense to re-visit some of those more vague macro names. Suggestions are welcome!