Handle the events in separate class

[Avilla83]

Hi, I am moving all the logic that handles the events in a separate class common to all the classes that use this logic. This should simplify the devices logic and focus on the single functionality. I am doing this to try to have a better understanding of the status of the class (e.g. relay ON vs OFF) and avoid mistakes in the event logic handling.

This logic will be present soon in my fork, what do you think about it?

[mistergreen]

Give it a try. Don't forget that you can assign a dependency on a device. A dependency is looking at the another device's ON/OFF state, like a relay is dependent on a pH sensor.

The messiest part of the web logic part, those long if else statements. Wish I could clean that up somehow.

[Avilla83]

Hi,

I have the scheduler on my fork (scheduler or master branches). The scheduler is a class called EventHandler and the devices using events are extending it.

I also worked a bit on PWM4 and AdafriutPWM8, AdafruitPWM8 now extends PWM4 and most of its logic is in common. This semplification allowed to have an easier serialization into json, so also PWM4 and AdafruitPWM8 can be stored in memory.

I plan to add storage for remaining classes (some inputs are not being stored), it should not be a big effort. The remaining storage problem is about the dependent devices, I need to figure out how to fix it, probably it is sufficient to change the deviceDelegate to insert devices with a given id. So currently no dependencies between devices is saved in memory.

I tested PWM4 and AdafruitPWM8 only looking at logs, I do not have real PWM controlled devices at the moment.

[mistergreen]

Oh, I thought you were going to make a Event system of dispatcher and observers. I see that separating the Events makes it easier to serialize.

[Avilla83]

I started with a publish subscribe idea but then I realized I had to do a rationalization of the events logic before. Then the storage on SPIFF part became easier, so now on the configuration_storage branch I added serialization and deserialization to all the devices. This means that all the devices should be recreated at reboot. Now I think to complete the storage stuff by adding the general settings (right now only ip, ntp server and local zone are stored).

I am also thinking to test ESPAsyncWebServer that may give more speed to the html part, also using the two ESP32 cores may be an option.

[Avilla83]

In my fork now all storage of settings should be done.

Here the changes in my master/configuration_storage (they should be aligned):

• all devices settings should be stored, I cannot test all the sensors and actuators but on the logs they seem to be stored and recovered correctly
• general settings (from settings page) are stored
• added IP configuration in settings page
• if the settings file cannot be read the controller starts in access point mode and so it allows to set IP and network settings. In AP mode the controller start with SSID "ESP32-WAAC" and password "aquarium", the used IP is 192.168.1.4.
• I tested the Access Point mode, I admit I had some issues to connect sometimes and I had to change the password and rebuild the code, I am not sure what went wrong but at the moment this should not be much a priority. In general this seems to me a step ahead in the configuration, what may be interesting could be the upload of an empty config JSON file so that eventually the user may write parameters directly there if access point mode does not work.

Next step I want to try is the ezTime library to allow setting of time zones instead of current time add/subtract. In addition ezTime can mange timed events (like setting alarms at defined time) and this may substitute the current event handling.

[Avilla83]

Don't mind about my comment on the example JSON file, I uploaded one in the Json folder

[mistergreen]

What do you mean by "Access Point mode'? Do you mean when the ESP32 restarts and tries to recreate the objects from the JSON file?

[Avilla83]

If the ESP32 does not have the JSON settings file starts as an access point so it does not try to connect to a WiFi network but instead it creates a WiFi network called ESP32-WAAC. At this point the user can connect to the ESP32-WAAC WiFi network, go to http://192.168.4.1 and access to the WACC settings. If the settings are saved then the WAAC tries to connect to the stored WiFi and IP settings.