WIP: Config experiment

[rjwats]

• Make configuration accessible, and manageable outside the framework core.
• Allow notification of configuration changes with an observer pattern.

[rjwats]

Do you ever experience these issues with FreeRTOS.h ? I sometimes just make a few changes and the first compile throws this on almost every service file. I have to go through the header files as add FreeRTOS.h seemingly at random. I made the changes from this feature, and am now back tracking to see what caused it.

BTW - I've tracked this down to the auto-formatter messing around with the import ordering. WiFi.h must be included before AsyncTCP.h for some reason, as follows:

#include <WiFi.h> #include <AsyncTCP.h>

I have just merged a fix to the clang format configuration file.

[rjwats]

@justoke

I've made more progress on this, the notifier is working in the branch now, let me know if this looks like this approach will work for you (again there's some temporary hacky code in the demo project which demonstrates the feature).

Last thing to tackle is factoring out the config classes. The idea is so you can read and write (configure) an instance of say "WiFiSettings" against the "WiFiSettingsService". This approach may make more sense where you want to update a setting granularity. Such as setting the NTP "time zone" or the OTA "enable" flag without wanting to serialize/deserialize a JSON structure.

You may not have that immediate requirement - but I feel like it rounds off this feature change nicely.

[justoke]

This looks like a good solution. If I understand correctly, you would add an event handler for any service whose settings you were potentially consuming and then on callback go and get the settings via the corresponding settings service?

String config; _esp8266React->getSecuritySettingsService()->fetchAsString(config); 

The requirement to access settings - either for modification or as a consumer that sits outside the settings service is bordering on essential in some cases.

For example, I have added some settings to my DemoProject like a custom hostname which I want to set under the WiFi settings e.g. MC-23AGFC01 also. So if I can access the WiFi setting for this from DemoProject.cpp, then ideally I don't need to access the WiFi settings UI, as this hostname will be unique for all devices and I want to set it the first time the device boots up and never from the UI. I use a convention like "hostname" : "DEFAULT" as the initial setting and then configure on startup - the settings is applied to both the WiFi settings and DemoProject settings. Of course having to remember to do this across services is not ideal, but then again sometimes the same setting has context in more than one place.

The other point around this - once the settings have been done, then the device can be considered deployed and the need to access settings is not likely for long periods. In this scenario I'm wondering if the esp8266 services could be shutdown - with only a single endpoint that would allow them to be restarted via some sort of MQTT message or even a schedule.

[rjwats]

That's the idea, you can get the callback react however you want - possibly fetching the new settings back in the form you require (String, JsonObject or maybe template "settings object" ).

I'm currently seeing if it's feasible to return the settings as an object so you could do something as follows:

void DemoProject::onWiFiSettingsUpdated() { WiFiSettings wifiSettings = _esp8266React->getWiFiSettingsService()->fetch(); Serial.print("WiFiSettings updated, hostname is now:"); Serial.println(wifiSettings.hostname); } 

This may allow you to be clever about synchronising changes where facets of your application need to share core settings. At the moment I'm thinking you may be able to call fetch() and update() with these objects (copy constructed? eek!). Hoping it doesn't make the code harder to understand, though I may have to factor out a Serializer class to keep things clean.

A WiFiSettings object for example might look like:

class WiFiSettings { public: // core wifi configuration String ssid; String password; String hostname; bool staticIPConfig; // optional configuration for static IP address IPAddress localIP; IPAddress gatewayIP; IPAddress subnetMask; IPAddress dnsIP1; IPAddress dnsIP2; }; 

I'm not totally sold on this last bit, it may be a step to far, but we'll only know when we see it. This is all reliant on memory, but with ~24k free it doesn't look like too much to ask - we'll see.

I've got some time on Saturday to finish looking at this - it's been a really busy week for me.

[justoke]

That seems like it could work, without introducing too much complexity. It helps to take an objective view on what all these features really mean and how much value they add. After all you obviously had an idea about how this would simply setting up and maintaining a hardware device.

The balance has to be somewhere between the end application having the essential settings and the overhead the configuration services represent to the device. Too much code and memory for the settings, might mean the app is starved of resources.

Btw, I have committed my fork with MQTT and the OTA pull functionality. It's not working i.r.o the MQTT settings as I removed the global Config settings I had and for some reason the MQTT client isn't able to get the MQTT connection settings from the MQTTSettingsService. However, if you take a look at the layout and folder organisation - it is a hybrid of the config-experiment, proddy's MQTT service and client and my OTA update. When you have time for a call let's go over it and decide what's in and what's not.

Thank you for your efforts and time on this.

[rjwats]

Will merge "config-experiment2" instead.

[justoke]

I'll merge once config-experiment2 is done and get my fork working with it and take stock of things. G