BSB-LAN
BSB-LAN copied to clipboard
fredlcore
(New) configuration options that should be included into web-based configuration
Here I would like to list all configurable parameters/options that should be added to the web-based configuration at some point. No need to do this right now, because if I understand correctly, each newly added batch of parameters increases the EEPROM version number of which we only have 254(?). So these could be added at a time when we have to make changes to the list of parameters anyway.
ENABLE_ESP32_OTAWIFI(Olimex boards can switch between WiFi and EthernetESP32_USE_SD(Olimex boards can either use (small portion of) SPIFFS or SD cardONE_WIRE_BUS(enableOneWireBus already exists as a variable, but is not configurable in webinterface)DHT_BUSBME280
if I understand correctly, each newly added batch of parameters increases the EEPROM version number of which we only have 254(?)
Yes, you right. So you right one more time: it is better to add some options at one time than one-by-one adding.
@dukess and @1coderookie, can you think of other settings that we have added in the last couple of months that are missing in this list? Once it's "complete", could you add these parameters to the configuration, @dukess? No need to add the code that replaces the ifdefs, just to get the configuration up to date.
Will think about it, but right now only the MQTT-clientID-issue/solution pops up in my head (https://github.com/fredlcore/BSB-LAN/pull/376) - maybe that should be settable via Webconfig also..?
ENABLE_ESP32_OTA - can be in Webconfig WIFI - leave as definition because different #include is used. In other case we should think about HAL development. ESP32_USE_SD - leave as definition for same reason as above. ONE_WIRE_BUS - can be in Webconfig. But we can use zero value of One_Wire_Pin as off state and non-zero as on-state. DHT_BUS - DHT_Pins already in Webconfig. Or we should to add additional parameter for DHT on/off? Empty value will disable DHT. BME280 - can be in Webconfig
Will think about it, but right now only the MQTT-clientID-issue/solution pops up in my head (#376) - maybe that should be settable via Webconfig also..?
MQTTDeviceID already presented in Webconfig.
Thanks for your quick feedback, you two! As for WiFi, you are right, that won't be able to configure via WebIF. Once we provide pre-compiled binaries, we'll have to create several versions then (or focus just on one of them). As for the sensors: Can we use zero value as "off" for 1Wire, DHT and BME280 respectively? I think it makes sense that if the value is empty, then the function is off. Saves us several knobs to further configure...
About the sensors: "0" for OFF would be ok for me, but then a) for DHT&OneWire the pin number(s) if connected and b) for BME (I2C) the amount of sensors attached, so that one can change config fully using webconfig, right? Or isn't that possible? Cuz @dukess wrote "ONE_WIRE_BUS - can be in Webconfig. But we can use zero value of One_Wire_Pin as off state and non-zero as on-state".
As for the sensors: Can we use zero value as "off" for 1Wire, DHT and BME280 respectively? I think it makes sense that if the value is empty, then the function is off. Saves us several knobs to further configure...
Yes, we can.
so that one can change config fully using webconfig, right? Or isn't that possible?
I think we can do it, but we need some experiments with BME library.
Right now we have "enableOneWireBus" variable which looks useless and can be replaced with "One_Wire_Pin" without any quirks.
Patches: https://github.com/dukess/bsb_lan/commit/064a582c848412c4251a3926462d9488c31ecc29 and https://github.com/dukess/bsb_lan/commit/072550ea5ebd3cb7ee2dfc1c4f5a4a70b31dc4ef
Thanks for the patches and the explanation; since @1coderookie has BME280 sensors running(?), maybe he can help with the experiments?
It might be good if also the related settings of the debug function (and other functions with related settings) from the config file like "bool show_unknown = true;" etc could be changed using the webinterface.
Hmm. Debug options already can be changing via web interface. Or you mean new debug options?
Yes, sorry, I wasn't explicit on that enough: You are right, most of the related settings (monitor, verbose etc) are already possible to set also, but not the setting "bool show_unknown = true;" to show/hide error7-parameters which would be nice to have also. E.g. if you make a complete query /0-10000 to check the availability or the setting of parameters in general and you want to save the output (what I personally like to do and sometimes I also ask users to send me that output for troubleshooting etc), then it would be nice to not have all the error7 parameters listed also.
Did it: https://github.com/fredlcore/BSB-LAN/pull/399/commits/5165c94a2f9dedb90624ccb5a1de0d1d5408a672
Should we maybe wait until we have a few more parameters to add to the webinterface? Because now we would "waste" one of the 255 possible changes in the EEPROM layout that we have available, isn't it? Or could we change the EEPROM layout counter from one byte to two bytes? Then we wouldn't have to think about it anymore.
We are not clairvoyants :) , but we need to think about whether the appearance of new options is possible in the near future. If not, then we can safely add this option.
P.S. 240 versions enough to us for 20 years even we will add one parameter every month.
Could you also add a web-config option for the bus pins? For the moment, we won't need this, but once we provide pre-compiled binaries, people would have to be able to change the pins via web-interface.
Why not? I see no problem for implement this.
fredlcore @.***> 31 октября 2021 г. 9:53:09 написал:
Could you also add a web-config option for the bus pins? For the moment, we won't need this, but once we provide pre-compiled binaries, people would have to be able to change the pins via web-interface. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
Yes, that would be great! Not that I know of any non-debugging use right now, but if we're working on the EEPROM layout, it's best to add it right away...
I think we actually would need (pretty much) everything from the config.h changeable using the webconfig when we wanna switch to the precompiled binaries, right..?
Well, I had hoped that we could do away with some settings as well as take away some of the very special configuration options (such as fixed device family/variant etc.), but I think these would have been the last ones(?) we didn't have already, so I thought we can just add them as well...
Good idea. Maybe we should then have an option for basic and advanced settings? Because I think half of the options (at least) is not going to be used by 90% of the users ;)...
We wouldn't have to store this in EEPROM, it could just be a CGI variable or a URL command such as /CE (configuration extended) or so...
If we want divide configuration for "basic settings" and "advanced settings" we should to add one more field in options table like "flags" field in cmdtbl and build configuration page depending on flags states.