Correct way for multiple pages autoconnect

[FRANAIRBUS]

Hello, I would like to know your opinion on the correct way to create several pages with autoconnect.

My application has several pages with different global variables to deal with in my cake.

PAGE1, data1, data2 ......
PAGE2, data3, data4 ......
PAGE3 ........

I have always worked with the mqttRSSI_FS.ino example and it has worked well for me, but I don't want to continue loading parameters.json separately.
I would like to upload everything from ota with a single .bin file

I am now using the mqttRSSI.ino example but I would like to check that it is the correct way without uploading separate files. for now it works and I have not had to load the .json separately

my reduced example:

 
  #include <AutoConnect.h>
  //.......

  #include "PAGE1.h"
  #include "PAGE2.h"

  void setup() {
  //.......

    FlashFS.begin(FORMAT_ON_FAIL);

    portal.config(acConfig);
    portal.begin();

    PAGE1_SETUP();
    PAGE2_SETUP();
  }

  void loop() {

  #ifdef ARDUINO_ARCH_ESP8266
    MDNS.update();
  #endif

    portal.handleClient();  ////////////////////////////////// PORTAL PORTAL

    Serial.println(DATA1);  //PAGE1
    Serial.println(DATA8);  //PAGE2
  }

  /////////////////////////////// PAGE1.h

  const char* PARAM_PAGE1 = "/page1.json";
  const char* AUX_SETTING_PAGE1 = "/page1_setting";
  const char* AUX_SAVE_PAGE1 = "/page1_save";
  .static const char AUX_mqtt_setting1[] PROGMEM = R"raw(
  [
    {
    "title": "PAGE1",
    "uri": "/page1_setting",
    "menu": true,
    "element": [
      {
        "name": "style",
        "type": "ACStyle",
        "value": "label+input,label+select{position:sticky;left:120px;width:230px!important;box-sizing:border-box;}"
      },
      {
        "name": "DATA1",
        "type": "ACInput",
        "value": "",
        "placeholder": "Msql server",
        "label": "DATA1"
      },

      // DATA2, DATA3, DATA4 ........

      {
        "name": "save",
        "type": "ACSubmit",
        "value": "Save&amp;Start",
        "uri": "/page1_save"
      },
      {
        "name": "discard",
        "type": "ACSubmit",
        "value": "Discard",
        "uri": "/"
      }
      ]

    },
    {
      "title": "PAGE 1 SAVE",
      "uri": "/page1_save",
      "menu": false,
      "element": [
        {
          "name": "caption",
          "type": "ACText",
          "value": "<h4>Parameters saved OK:</h4>",
          "style": "text-align:center;color:#2f4f4f;padding:5px;"
        },
        {
          "name": "HOME",
          "type": "ACSubmit",
          "value": "HOME",
          "uri": "/_ac"
        },
        {
          "name": "Reset",
          "type": "ACSubmit",
          "value": "Reset Board",
          "uri": "/_ac/reset"
        }
      ]
    }
  ]
  )raw";


  String DATA1; // DATA2, DATA3, DATA4 ........


  void getParams1(AutoConnectAux& aux1) {

    DATA1 = aux1[F("DATA1")].value;
    DATA1.trim();
    DATA2 = aux1[F("DATA2")].value;
    DATA2.trim();
  // ..........
  }

  String loadParams1(AutoConnectAux& aux1, PageArgument& args1) {
    (void)(args1);
    Serial.print(PARAM_FILE1);
    File param1 = FlashFS.open(PARAM_PAGE1, "r");
    if (param1) {
      if (aux1.loadElement(param1)) {
        getParams1(aux1);
        Serial.println(" loaded");
      } else
        Serial.println(" failed to load");
      param1.close();
    } else
      Serial.println(" open failed");
    return String("");
  }



  String saveParams1(AutoConnectAux& aux1, PageArgument& args1) {

    AutoConnectAux& page1_setting = *portal.aux(portal.where());
    getParams1(page1_setting);

    File param1 = FlashFS.open(PARAM_PAGE1, "w");
    page1_setting.saveElement(param1, { "DATA1, DATA2, DATA3...." });
    param1.close();

    return String();
  }

  void PAGE1_SETUP() {
    
    ///////////////////////////// PAGE 1

    if (portal.load(FPSTR(AUX_mqtt_setting1))) {
      PageArgument args1;
      AutoConnectAux& page1_setting = *portal.aux(AUX_SETTING_PAGE1);
      loadParams1(page1_setting, args1);

      portal.on(AUX_SETTING_PAGE1, loadParams1);
      portal.on(AUX_SAVE_PAGE1, saveParams1);
    } else
      Serial.println("load error");
  }


  //////////////////////////////////// PAGE2.h

  //....................

another way I imagine that using autoconnect elements but I can't get the data of the variables to be global or to be printed when restarting without hitting the save or read buttons.

Elements.ino

but in this last one I can't get the variables to be loaded from native when restarting, they are recorded but they are not printed in a loop without giving the load button first or saved.

In short, there are always many paths and ways to get to the same point and I would like to know your opinion on the best way to make a program with many pages and variables.

I am putting the pages as simple libraries for later use on demand

page 1 msql
page 2 mqtt
page 3 thermostat
page 4 relay
page 5 homekit
pages 6,7,8......

thank you very much in advance for guiding me on the correct structure

[Hieromon]

Hello @FRANAIRBUS, After all, I think you have found already the ideal structure.

I am putting the pages as simple libraries for later use on demand

That's exactly. The question we need to address is, "So how do we implement that?"

• AutoConnectAux described JSON will be incorporated and integrated into the BIN after going through the build process.
• However, they are separated from the processing logic in the source code and are self-contained for each custom web page.
• Then, the AutoConnectElements values that are ubiquitous on each page will need to be maintained across pages.
• Their values must be read from EEPROM as initial values and distributed to each element of the corresponding AutoConnectElements ubiquitous to each page --- i.e., the scope of their values is global.
• And each custom web page is instantiated at the occurrence of an HTTP request to the URL it has -- exactly as you say, on-demand.

OK, let's try to implement ... and before we -- you and me -- do that, I want to make sure I understand what you mean by one of your mentions.

I can't get the variables to be loaded from native when restarting

By native you mean the last recorded settings that should be restore from EEPROM at restart?

FYI
The most crucial part of the above structure is how to achieve page instantiation on demand. My idea is to use a 404 handler and a 302 response. I will try to implement the skeleton now, so please wait a bit. However, it is not always successful.

[FRANAIRBUS]

Thank you @Hieromon

If I want the variable "input2" to be printed in a loop once restarted and not only when I hit save or load, I guess I need some loader on restart in the example Elements.ino

    //AutoConnectInput& input2name = elementsAux2["input2"].as<AutoConnectInput>();
    //aux2["validated"].value = input2.isValid() ? String() : String("Input data pattern missmatched.");
    //input2 = input2name.value;

}

void loop() {
  portal.handleClient();

Serial.println(input);
Serial.println(input2);
delay(1000);

}

https://github.com/Hieromon/AutoConnect/blob/master/examples/Elements/Elements.ino#:~:text=AutoConnectInput%26%20input%20%3D%20elementsAux,missmatched.%22)%3B

but let's forget this.
if the correct structure is the initial following the example mqttRSSI.ino

As for by demand, at the moment I am doing it in a very archaic way :) .

void AAC_SETUP() {

     acpage_conf();

    if (otaon == "1"){

        //confon = "0";
        config.ota = AC_OTA_BUILTIN;   // OTA OTA OTA OTA
        yield();
        Serial.println("OTA HABILITADO ");
    }

    else {   
    
    acpage_server(); 
    acpage_sensor(); 
    acpage_alarmas();
  }

and the idea was to do it with or without adding libraries to the compilation since I am rebuilding all the code.

by the way I miss a serial monitor with sending commands in acpage. I found a case of homekit that I have to do a storage reset via soft.

[Hieromon]

@FRANAIRBUS
Hmm, I understood that you were asking for a framework-like program structure to handle multiple custom web pages, but apparently that is not your concern.
I guess your prime concern is that you want to dynamically change the behavior of various HomeKit IOs according to the settings updated on the custom web page, even while executing the loop() function. Is it right?

If so, once again, let's organize the work we should be doing.
To begin with, Elements.ino is not suitable for the structure you are looking for. Saving and loading the settings is sufficient at boot time and when changes are made. It is simply a matter of placing it in a scope that is accessible from anywhere in the program as you mention. The instance of that global variable need not be an instance of AutoConnectElemets. The procedure we should implement and control is not when to load the previous settings. On the other hand, I think your efforts to get hints from mqttRSSI.ino about the loading and saving procedure for the settings were not in vain.

I have already started implementation in line with my above comment. However, as I infer from your reply, I have a feeling that my destination is wrong.
What should be pursued is not how to handle multiple pages, it is how to know asynchronously when AutoConnectElements values are updated on the custom web pages. In other words, the structure you are looking for is not a loop structure. It is clearly an event-driven model. But you are trying to achieve that with a loop structure, which is why you are in a maze.

Is what you're looking for related to something raised in another topic in Discussions #503?
It is not implemented yet, but a new mechanism to fire a callback when the AutoConnectButton is clicked. No HTTP page transition occurs and the sketch receives the changed values of AutoConnectElements asynchronously. Of course, your sketch can receive the changed value asynchronously, even while the loop() function is running.
Is this close to what you are looking for?

[FRANAIRBUS]

@Hieromon

Modification I have gone a bit by the branches, the initial question of the discussion is for the following:

My latest addition is
LH_AC_HOMEKIT.h

I already have

LH_AC_RELE.h
LH_AC_PUSHBUTTONS.h
LH_AC_BLYNK.h
LH_AC_MSQL.h
LH_AC_PROBES.h
LH_AC_.......

so by adding just one line to LH_AC_APP.ino

I already have a software according to my needs working

EXAMPLE: LH_AC_APP.ino + LH_AC_RELE.h + LH_AC_PUSHBUTTONS.h + LH_AC_BLYNK.h + LH_AC_MSQL.h

So I have 4 relays with pushbuttons that work with apple homekit, and I can also turn them on with BLYNK app, and I can also know how long they are on and how many times they are pressed with MQSL, GRAFANA, HOMEBRIDGE, GOOGLE, etc ...... just adding a couple of lines of code and you're up and running with everything you want. :)

I think we are more on track with your first idea.

I am not interested in turning on a led with a button in an html and homekit that is an extra complement to make my hardware more versatile but not the basis of my project.

Main project is a standard hardware board designed so that it can be all in one depending on the configurations or conditions that we give it

Principal is an intelligent industrial thermostat capable of sending data by different methods according to the client's needs, mqtt, mqsl and other aggregates, sms, email, etc... grafana.... blink.... etc. They have been working correctly for a long time time with my code

In this you can choose
4 relays
type of probe (dht, ds, smoke sensors, open door contact, pressure, etc.)
types of shipments and communications with other systems such as modbus protocol.

Next phase that is allowed to manage and not only be visualization, in this sense of managing remotely I mean being able to cause a defrost, change the setpoint or other specific functions such as whether compressor off fan off, yes or no. There are many parameters that I already have implemented, such as changing defrost times every x minutes, setpoint differentials or conditions such as this relay closing and activating it when this happens and others at an industrial and specific level.

This particular equipment works autonomously but sends data for viewing via Wi-Fi and will soon receive data to change parameters.

This is intended to be done through an external and centralized database where the client will have their role and privileges, although it would not be bad to see this on the local web server as well.

I think my problem is more that I have always tried to make my code as adapted as possible to other systems including any development board instead of focusing on my hardware.

that is why my hardware could be modified and turned into any other product
4 simple relays and pushbuttons for lighting (homekit, google etc)
use it as a garage door opener
as temperature and humidity sensor
irrigation system
and others at the domestic level just by loading the . bin correct.

but my work is more focused on an industrial level, so its approach to macros is more appropriate and striking

I think your approach is correct when you say that I'm going crazy with loops and I should focus more on events

i have been sending data from my thermostats to blynk for client app and to 2 msql simultaneously for grafana logs etc. the next step should be a webapp of my own.

el ejemplo de if para cargar ota acpage lo vera como absurdo y seguramente lo sea pero mi codigo lo tenia preparado para trabajar tambien en esp8266 1M y aparte de no poder usar ota si lo tengo activado en el menu este sufre de problemas de buffer igual que si pongo mas de 12 variables en cada autoconect page asi que me las he tenido que ir arreglando con condiciones if para no abuzar del buffer

in other words, all crazy with little programming knowledge :)

Your Acbotton implementation is correct and necessary. I did it with the variable because I only needed it for testing and not for the client to turn it on on the web page.

    if (COMAND == "POWER1 ON"){
        Serial.println("RECIBE COMAND: " + COMAND);
        encender1 = 0;
        COMAND = "";
    }

    if (COMAND == "POWER1 OFF"){
        Serial.println("RECIBE COMAND: " + COMAND);
        encender1 = 1;
        COMAND = "";
    }

Ultimately my system is
configure initial data in the local system according to the needs of hardware use

Load pages and menus on demand according to uses if possible with the same .bin

-Send data to a centralized or specific database of the client for treatment, history, configurations.

-receive remote configuration changes if online

-autonomous work even if it is offline.

million dollar question
Am I on the right track or should I jump off a bridge and rethink everything even more and better?

[Hieromon]

@FRANAIRBUS Well, maybe your code will become the spaghetti if you continue to enhance it as it is now? Maybe you need to say goodbye to your current program structure and do some refactoring. So, let me ask the following a few questions to clarify this:

1. You claim to have already proven code. It's like a kind of edge device driver with various sensing and telemetry interfaces. Input from various probes such as relays, pressure sensors, door switches, and MODBUS. Telemetry to mqtt, MySQL, etc. Are you shoving them all into one LH_AC_App.ino or do you have a different LH_AC_App.ino for each application?
2. What is in LH_AC_RELE.h, LH_AC_PUSHBUTTONS.h, LH_AC_MSQL.h, etc.? Is it a JSON definition for a custom web page? Or is it the accompanying logic?
3. If you have segregated function blocks for each sensor/telemetry, can you post a representative one?

I feel that your subject could be solved by making more use of the object oriented paradigm.
Integrate the process governing edge device sensing and telemetry with a custom web page to separate its block from the main loop. The block (i.e., the C++ class) is self-sustaining and also owns a set of variables necessary for its own processing.
The main loop simply calls that function block continuously. It does not need to involve global variables. (Of course, it does get involved in the kinds of variables that affect the system as a whole, such as module reboots, etc.) Essentially, it only needs to interact with the edge device interface and the custom web page with AutoConnect.
Even the storage and recovery of the various parameters needed for edge devices and telemetry should depend on that function block. This can be done by storing them in LittleFS files with different file names for each device and telemetry. This way, they will not interfere with each other. The function block itself will have its initial values as factory default settings.
The custom web page is then instantiated from the JSON definition at just a request time for that URL is made. This reduces memory consumption.
This is the program structure I envision. How about you?

million dollar question
Am I on the right track or should I jump off a bridge and rethink everything even more and better?

Unfortunately I do not have the answer to that question. However, there is two things I always keep in mind in order to find new discoveries. They are both people I respect very much.

It is by logic that we prove, but by intuition that we discover. (H. Poincare)
The science without the art is likely to be ineffective; the art without the science is certain to be inaccurate. (D. E. Knuth)

And now, I feel we must share the same will -- Roma no se hizo en un dia.

[FRANAIRBUS]

@Hieromon wauuu I'm Canarian not Italian so better in potatoes with mojo :)

Interesting phrases (H. Poincaré), (DE Knuth).

1 Answer to his first question:
I am integrating everything in the same .ino

2 Answer to your second question:
LH_AC_.....h is usually the 2 things the custom page parameters, configuration and logic.

Has a working example 4RELE + MSQL + HOMEKIT in my repository.

This is simple though you can already choose whether you want to use it with msql and homekit or disable it. I have not yet been able to rebuild all my previous code to add thermostat and others.

but the idea and structure proposed is that.

Thank you

[Hieromon]

@FRANAIRBUS Thank you for invitation. I joined to LH_AC_4RELE_HOMEKIT-SQL Repo.
I took a quick look at your code, and in my opinion you're already close to the finish line. The intent that I can read from your implementation is exactly what I have commented on this comment. And I believe it conforms to the abstract image I have envisioned.

I have drawn the following simple diagram that combines your conception with my technical insights. It is still abstract and incomplete, but it will serve as a compass so that we do not lose sight of each other's goals.

I have already started to implement this diagram. Its implementation defines and introduces several new concepts as follows:

1. Edge Devices: It is a generic term for devices that interface with Edge in an abstruct concept. Specially, it includes GPIO-connected elements, MQTT Broker, MySQL DB (usually, MySQLconnector), MODBUS IO, and data sources for Grafana, etc.
2. Edge: A general term for this framework that we will try to implement this time. The entity consists of one or more Edge Unified, Edge Driver corresponding to Edge Device one-to-one, Edge Data for persisting data dependent on Edge Device, AutoConnectAux's JSON definitions with its request handlers, the equivalent of the Edge Driver is what you have already envisioned as the LH_MQTT_ and LH_HOMEKIT_ functions, etc.
   Edge is just a concept, and its entity is a set of Edge Unified and Edge Driver.
3. Edge Unified: Actual C++ Class. This is the core component of this implementation. The sketch calls the EdgeUnified::begin(), EdgeUnified::process(), and EdgeUnified::end() functions of Edge Unified instance to form an event loop process between Edge Driver and AutoConnectAux request handler. EdgeUnified class will call back Edge Driver according to EdgeUnified::begin(), EdgeUnified::process(), and EdgeUnified::end(). EdgeUnified::onError() function to break an event loop with notification to Edge Driver.
4. Edge Data: A set of various parameters required to drive the Edge Device, a receiver of data generated by the Edge Device,
   and various commands and parameters to be communicated to the Edge Device. Its entity is a C++ struct structure. Edge Data exchanges the necessary data between the Edge Driver and the AutoConnectAux handler with each other. It is the AutoConnectElements value, parameters and input/output data for the Edge Device. It's the wall where you felt the need to globalize and stopped.

I previously mentioned that an event-driven model would be suitable, but I am now convinced that Edge framework can be implemented with an event-loop model.
So, I said again, you have already reached just before the finish line. I'm guessing you wondered about how data is exchanged between the AutoConnectElements value and the HOME-KIT devices in a loop() function -- "Is this the optimal structure? really?". Its code will be intricate and less maintainable to look at. Its logic is like a line running randomly in all directions. In other words, it's not beautiful. As a result, you succeeded in getting me to draw the diagram above. The words left by H. Poincaré and Dr. D.E. Knuth are still true. Logic without beauty is inaccurate, accurate logic can be discovered by intuition.

I have a favor to ask you: as the Edge framework implementation progresses, we will need to refer to and review each other's code. Can I use your LH_AC_4RELE_HOMEKIT-SQL repository as a stage for that? That way, I can put the Edge framework into a library format and you can incorporate the Edge drivers into the repository. Issues can be shared and discussions can continue. What do you think?
Of course, I am willing to publish the Edge framework in my repository for public use. Please let me know your availability.

Thank you.

[FRANAIRBUS]

You have imagined the concept like me.

modbus:
I just have to create a LH_AC_MODBUS.h
Look at the documentation of, for example, a frequency converter.
place the modbus address of the RPM parameter, in a custom page place address and that's it.
We will have a flexible modbus bridge that sends the data for its parameterization wherever you want.

Modbus-wifi to wifi-Modbus
Modbus-tcp or simply collect data from the device and send to (mqtt, sql....)
etc

[FRANAIRBUS]

@Hieromon

hahaha I don't know if he's criticizing me for better or for worse :)
I suppose that many times they are things of the translator.

my programming knowledge is limited and self-taught for that reason I understand that they are not beautiful and I appreciate your time

I am very happy that he understands my approach and that with his knowledge and that of the community we can improve. for that reason you have my consent to publish my repository with the changes you consider necessary.

As it is an initial code, it has no comments and some words are in Spanish. I did it yesterday quickly so you could see it. My previous iot thermostat code, although functional, was crazy spaghetti, that's why I'm renewing it.

By the way, I want to put in the following versions that the homekit elements are on demand with a menu to choose if you want 1 relay or 2,3,4 or the temperature function so that it does not deliver what is not used

even so the homekit complement is for domestic use and only that in the globalization of the system one more complement for more particular use, in practice the optimization will be based more on an industrial level

As for your scheme, I have to look at it better and translate certain words and sit down with a little more time, but I think I understand it and it is very close to what we are looking for.

Thank you very much for your interest and a great honor for your publication.

[Hieromon]

@FRANAIRBUS I am not criticizing you. I felt that you hesitated to reserve many global variables. I admired your sensitivity. My native language is Japanese, so I apologize if my poor English misled you. But you have given me inspiration for the Edge framework. Thank you.

I have been careful to keep AutoConnect as simplified an interface as possible. Still, it is a bit difficult as an Arduino library. Instead, I prioritized flexibility and extensibility, and Edge might be similarly challenging for users.

I will now decide on the specifications for the Edge framework. I intend to keep the API as simple as possible and to allow users to divert the Edge Driver as much as possible from their existing code. I need your help to do this.

place the modbus address in a custom page and voila.
we will have a flexible modbus bridge that sends the data for its parameterization wherever you want

I agree completely.
So, LH_AC_MODBUS.h is the Edge Driver, and EdgeUnified joins LH_AC_MODBUS.h and AutoConnectAux pages.
The sketch only calls EdgeUnified in setup() and loop(). The user is freed from the complex control of global variables involved in event loops; LH_AC_MODBUS.h (i.e., EdgeDriver) can access AutoConnectInput and AutoConnectRadio values directly via EdgeData. This is the benefit and advantage of the Edge framework and what we are aiming for.

[FRANAIRBUS]

Perfect and without problem in everything that can help so it will be.

Do not worry about criticism, if so they are always constructive
I really appreciate your assessment

[FRANAIRBUS]

Good afternoon @Hieromon

I'm impatient to test your AC_Edge code,

What do you need and how can I help you? you tell me and I will be happy to help just tell me the steps you want to take and they will be done.

regards

[FRANAIRBUS]

hi @Hieromon
I have been looking at your diagram more carefully and I have been able to imagine and understand it quite well, it is wonderful to see how a simple draft is very well detailed, congratulations if you can do that with a draft I imagine what you can achieve with everything.

Tell me what the next steps are, I will be happy to collaborate.

a bright image.

[Hieromon]

@FRANAIRBUS

in the example it uses millis, in the case of using a timer it would be like this?

void startGPIO() {
 gpio.data.pin = LED_BUILTIN;
 pinMode(gpio.data.pin, OUTPUT);
 digitalWrite(gpio.data.pin, !LED_ACTIVE);
 timer_BUILTIN.setInterval(BUILTIN_timer * 60000L, processGPIO(void));
}
void processGPIO() { 
   digitalWrite(gpio.data.pin, !digitalRead(gpio.data.pin));
}

Or would we call it better from the beginning?
timer_BUILTIN.setInterval(BUILTIN_timer * 60000L, Edge.attach(gpio);

What's timer_BUILTIN?, Is it an instance of something the library exported?
Anyway, I can't say for sure since I don't know what timer_BUILTIN is, but my guess is that none of the methods you have suggested would be suitable.

EdgeUnified forms an event loop by itself, which is why you need to call the EdgeUnified::process() function within the loop() function. Are you saying that your use case requires processing by a timer interrupts independent of its event loop?
If so, it would look something like this:

void startGPIO() {
  gpio.data.pin = LED_BUILTIN;
  pinMode(gpio.data.pin, OUTPUT);
  digitalWrite(gpio.data.pin, !LED_ACTIVE);
  timer_BUILTIN.setInterval(BUILTIN_timer * 60000L, [&]() {
    digitalWrite(gpio.data.pin, !digitalRead(gpio.data.pin));
  });
}

void processGPIO() {
}

void endGPIO() {
  timer_BUILTIN.stopTimer();
  digitalWrite(gpio.data.pin, !LED_ACTIVE);
}

NOTE
Depending on the capabilities of the timer library, the following code as shown above may result in a compile error. For example, you cannot do it with an obsolete library like this one.

timer_BUILTIN.setInterval(BUILTIN_timer * 60000L, [&]() {
  digitalWrite(gpio.data.pin, !digitalRead(gpio.data.pin));
});

Also, when implementing asynchronous processing with interrupts in addition to timers, keep two things in mind:

1. Ticker and some public timer libraries are not thread-safe. If they are not thread-safe, they can lead to heap area corruption and raise exceptions. Since there is no periodicity or pattern in the occurrence of such exceptions, it is very difficult to determine the cause.
2. If processing by an interrupt handler (ISR) is to be incorporated, that ISR should be excluded from the call to EdgeUnified::process(). Other peripheral interrupts are delayed while the ISR is executing. In particular, delayed WiFi interrupts crash the ESP8266 CPU. Note that EdgeUnified, AutoConnect, and ESP8266WebServer use an event loop model to avoid this situation.
   If event handling by an interrupt is really required, the ISR creates a flag for interrupt occurrence and pools minimal data from the interrupt source. The onProcess callback should be structured to detect interrupts using the INTERRUPTION-FLAG made by ISR and retrieve data from the pool.

These considerations are general and not specific to EdgeUnified.

[FRANAIRBUS]

¿Qué es timer_BUILTIN?, ¿Es una instancia de algo que exportó la biblioteca?
De todos modos, no puedo decir con certeza ya que no sé qué es timer_BUILTIN, pero supongo que ninguno de los métodos que ha sugerido sería adecuado.

timer_xxxx it's the name of ticker
xxx_timer it's the name of ACimput

aux["pin"].as().value = gpio.data.pin;
return String();

I understand that then millis should be used.

my specifications and thoughts are that in my program if we use an LH_AC_MySQL the send time parameter is configurable from the custom page.

Actually I think that all the parameters of each function must be called and written from the custom page.

example: some clients will need data to be sent every 1 minute and others every 15 minutes.

LH_AC_modbus will have other timing specifications for its own loop

then

// AutoConnectAux handler. Transfer EdgeData to AutoConnectElement values
String auxGPIOSetting(AutoConnectAux& aux, PageArgument& args) {
  aux["pin"].as<AutoConnectInput>().value = gpio.data.pin;
  aux["cycle"].as<AutoConnectInput>().value = gpio.data.cycle;
  return String();
}

// AutoConnectAux handler. Obtain AutoConnectElement values, copy to EdgeData
String auxGPIOApply(AutoConnectAux& aux, PageArgument& args) {
  gpio.data.pin = aux["pin"].as<AutoConnectInput>().value.toInt();
  gpio.data.cycle = aux["cycle"].as<AutoConnectInput>().value.toInt();
  return String();
}



void processGPIO() {
  if (millis() - gpio.data.tm > cycle) {
    digitalWrite(gpio.data.pin, !digitalRead(gpio.data.pin));
    gpio.data.tm = millis();
  }
}

or

void processGPIO() {
  if (millis() - gpio.data.tm > cycle) {
    XXXX(void);
    gpio.data.tm = millis();
  }
}

[Hieromon]

@FRANAIRBUS

my specifications and thoughts are that in my program if we use an LH_AC_MySQL the send time parameter is configurable from the custom page.
Actually I think that all the parameters of each function must be called and written from the custom page.
example: some clients will need data to be sent every 1 minute and others every 15 minutes.

You have pointed out two things that could improve the current EdgeUnified spec. So, here is my suggestion on this.

1. Is it possible to hide the data transfer code between the custom web page handler and EdgeDriver from the sketch?

   As you have already noticed, its transfer logic is a boilerplate code sequence. This is because in many use cases, EdgeData data members correspond one-to-one to AutoConnectElemets placed on custom web pages. In other words, if the transfer of values between the EdgeData member and the AutoCoonnectElement can be handled within EdgeUnified, the user can save the trouble of creating a sketch.
   I considered the possibility of achieving this, but the static typing that is the C++ language characteristic would not allow it. Or rather, it is possible, but the binary size after building would be too large to fit in the Flash area, even with ESP32. It's easy to do this in dynamically typing languages like JavaScript and Python, though.
   As a result, I came to the conclusion that I had no choice but to accept it, even if it was just a bunch of boilerplate code.

2. So, can the user change the cycle time of the EdgeDriver while the EdgeUnified event loop is running?

   Can be done. The EdgeUnified event loop is different from the AutoConnect event loop and the two event loops can coexist. In other words, the value of AutoConnectInput can be referenced in the EdgeDriver's onProcess routine immediately after it's entered in her web browser on the client. In fact, the mqtt.hpp code does just that and will help you, I think. The mqtt.hpp module dynamically changes the publish interval on the MQTT_SETTINGS page, even after the start of MQTT message publishing.

Or we can explore another possibility. For example, in the above example, add an enhanced specification that EdgeDriver has a cycle that calls processGPIO. It's like this:

// EdgeData definition
typedef struct {
  int     pin;
} GPIO_t;

// Declare EdgeDriver for GPIO
EdgeDriver<GPIO_t>  gpio(startGPIO, processGPIO, endGPIO);  // Edge device drivers

// Candidate for extended specification.
// Set and get the execution interval of processGPIO.
void gpio.setInterval(unsigned long tm);
unsigned long gpio.getInterval(void);

// In AutoConnectAux handler
String auxGPIOApply(AutoConnectAux& aux, PageArgument& args) {
  gpio.data.pin = aux["pin"].as<AutoConnectInput>().value.toInt();

  // Use setInterval, An interval value will take effect immediately.
  gpio.setInterval(aux["cycle"].as<AutoConnectInput>().value.toInt());

  return String();
}

// AutoConnectAux handler. Transfer EdgeData to AutoConnectElement values
String auxGPIOSetting(AutoConnectAux& aux, PageArgument& args) {
  aux["pin"].as<AutoConnectInput>().value = gpio.data.pin;

  // Use getInterval, Obtain the current interval and set to AutoConnectInput as default value.
  aux["cycle"].as<AutoConnectInput>().value = String(gpio.getInterval());

  return String();
}

EdgeDriver::setInterval & EdgeDriver::getInterval
The EdgeUnified::process function calls the onProcess routine according to the setInteval value. EdgeUnified measures elapsed time to call the onProcess routine with milliseconds. No sketch is required.
How about this?

---

Next, please tell me a little more about the following quote you mentioned.

LH_AC_modbus will have other timing specifications for its own loop

Each of the multiple devices connected to the one MODBUS connection has a different cycle time, how should you code that? Is that what you mean?

[FRANAIRBUS]

interesting :)

no, each of the modbus devices have the same time so to speak. it is a network that responds to a certain time.

let's imagine it in another way

2 MySQL servers

server 1 with 1 configuration page server, api, user ,,,,,

server 2 with 1 configuration page server2, api2, user2 ,,,,,

The idea is:
server 1 msql 15 seconds to 1 day....
server 2 mqtt 2 seconds
server 3 blynk app 2 seconds (or 2.5 seconds the server really doesn't care)
server homekit state every 1 second. (This is the most complicated or not, the difference is that if I activate a physical button on the iPhone screen, it should refresh almost immediately. Or if I activate from the button on the screen, the state should be reflected immediately.

the hardware has its limitations and the program does not have to use everything, although I think it can work with many at the same time

I have worked with thermosato, blynk, mysql, homekit almost all with 1 second. and real-time loop buttons "loop minus the delay". but after testing I had to create some simple protection condition to avoid stack overflow.

float MySQL_timer = timerMySQL.toFloat();
    if (MySQL_timer <= 0.06 ){
      MySQL_timer = 0.06;
    }
    else {
      MySQL_timer = timerMySQL.toFloat();
    }
   
    timer_MySQL.setInterval(MySQL_timer * 60000L, LH_MySQL_LOOP); 

In any case, I have never needed to change the delivery time with immediate effect. (configuration sending time) the response time is something else.

the configuration was applied until now after saving the parameter and rebooting

[Hieromon]

Hmmm, I have incorporated the use cases you mentioned from the beginning, the current EdgeUnified prototype has already implemented them.

server 1 msql 15 seconds to 1 day....
server 2 mqtt 2 seconds
server 3 blynk app 2 seconds

Each device is a different EdgeDevice instance, and an EdgeDriver is defined for each EdgeDevice and integrated into EdgeUnified.
Here is an example as pseudo code. In practice, EdgeDriver code should be paired with AutoConnectAux handlers and JSON definitions into the one source code files, and the source files should be split for each device.

typedef struct {
  String username;
  String connection;
  String servername;
  unsigned long tm;
  unsigned long interval;
} MySQL_t;

EdgeDriver<MySQL_t> mysql1(startMySQL, processMySQL1, endMySQL);
EdgeDriver<MySQL_t> mysql2(startMySQL, processMySQL2, endMySQL);

// If you want to have MySQL server instance-specific data, you can also define like this:
typedef struct {
  String username;
  String connection;
  String servername;
  unsigned long tm;
  unsigned long interval;
  struct {
    int id;
    int seq;
  } server2;
} MySQL_t;

void processMySQL2() {
  int id = mysql2.data.server2.id;
  int seq = mysql2.data.server2.seq;
}

void processMySQL1() {
  if (mysql1.data.tm - millis() > mysql1.data.interval) {
    mysql1.data.interval = millis();
    String sendData = mysql1.data....; 
    some_common_procedure(mysql1.data.servername, sendData);
  }
}

void processMySQL2() {
  if (mysql2.data.tm - millis() > mysql2.data.interval) {
    mysql2.data.interval = millis();
    String sendData = mysql2.data....; 
    some_common_procedure(mysql2.data.servername, sendData);
  }
}

// Or
mysql1.setInterval(aux["interval1"].as<AutoConnectInput>().value.toInt());
mysql2.setInterval(aux["interval2"].as<AutoConnectInput>().value.toInt());

void some_common_procedure(String& server, String& httpRequestData) {
  HTTPClient http;
  if (http.begin(wifiClient, server)) {
    http.addHeader("Content-Type", "application/x-www-form-urlencoded");
    int httpResponseCode = http.POST(MySQLAPI + httpRequestData);
    Serial.printf("HTTP-POST Response:%d\n",  httpResponseCode);
    http.end();
  }
  else
    Serial.println("Failed to open http session");
}

typedef struct {
  String devicername;
  String auth;
} BLYNK_t;

void startBlynk(void) {
  Blynk.begin(blynk.data.auth);
}

void processBlynk() {
  Blynk.run();
}

EdgeDriver<BLYNK_t> blynk(startBlynk, processBlynk, endBlynk);

main.ino

// Attach EdgeDrivers
Edge.attach({ mysql1, mysql2, blynk });

// For MySQLs, AUX handlers can be shared even on different pages.
Edge.join({ MYSQL1_PAGE1, mysql_aux_set }, { MYSQL1_PAGE2, mysql1_aux_get });
Edge.join({ MYSQL2_PAGE2, mysql_aux_set }, { MYSQL2_PAGE2, mysql1_aux_get });

// For BLYNK
Edge.join({ BLYNK_AUTH_PAGE1, blynk_auth_set }, { BLYNK_AUTH_PAGE2, blynk_auth_get });

Edge.process();

I don't quite understand what you are concerned about. Especially...

the hardware has its limitations and the program does not have to use everything, although I think it can work with many at the same time

What exactly does it represent for you? To me it seems to be an IO module or routine event loop responsible for multiple device IOs. That event is not triggered by an external event, just a timer interval, EdgeUnified already does that.

[FRANAIRBUS]

wow nothing nothing seeing that structure doesn't worry me at all.

understand that I don't have as much programming experience as I would like and sometimes I have trouble interpreting certain new words or concepts
but it's fine, I'm not worried about anything. I really like the structure.

to realize .....
one of those calls is the main one? I explain

the main setup declares the pins as inputs or outputs and by means of state variables each program retrieves it and treats it

EJEMPLO:

  int turn_on1 = 0;
  int latest1 = 0;
  int status1 = 0;

void LH_GLOBAL_SETUP(){


  pinMode(PIN_SWITCH1, OUTPUT);
  digitalWrite(PIN_SWITCH1, LOW);

  pinMode(PIN_SWITCH2, OUTPUT);
  digitalWrite(PIN_SWITCH2, LOW);

  pinMode(PIN_SWITCH3, OUTPUT);
  digitalWrite(PIN_SWITCH3, LOW);

  pinMode(PIN_SWITCH4, OUTPUT);
  digitalWrite(PIN_SWITCH4, LOW);

  pinMode(BUTTON1, INPUT_PULLUP); 
  pinMode(BUTTON2, INPUT_PULLUP); 
  pinMode(BUTTON3, INPUT_PULLUP); 
  pinMode(BUTTON4, INPUT_PULLUP);  



  }

void LH_RELE_STATE(){

  
  //RELE 1

    status1 = digitalRead(BUTTON1); 
  
    if(status1 && latest1 == 0) 
    {
      turn_on1 = 1 - turn_on1;
      delay(500); 
    }
  
    latest1 = status1; 

    if(turn_on1) 
    {
      digitalWrite(PIN_SWITCH1, LOW); 
      //Serial.println ("RELE1_OFF");
    
    }
  
    else 
    {
      digitalWrite(PIN_SWITCH1, HIGH); 
      //Serial.println ("RELE1_ON");
    
    }  

}

void LH_RELE_STATE() I know you do this differently, I'm 10 years late hehe

then
mqtt calls

state 1
treats it and returns it if you wish
turn_on1 = 1;

same with the declaration of probes

temperature1
humidity1

This main setup will have a probe type change through autoconnect element and its respective void

probe1 = dht1 : = t1 & h1
or
probe1 = ds : = t1
or
probe1 = pressure:
or
MQ135:
.....

Or do you propose it in another way?

good job @Hieromon

[Hieromon]

@FRANAIRBUS
I am now reviewing the code in the repository you invited me to. Using this as a reference, I will program the following EdgeDriver.

• GPIO
• MySQL
• MQTT

It also programs main.ino, which contains one EdgeUnified that integrates the three EdgeDrivers of above.
How about you take a look at it and we both discover the functionality that EdgeUnified should take on?
I have a regular job so I don't spend too much time on it, but I think I can write it in 3 or 4 days if you give me a little time.

[FRANAIRBUS]

No problem, as I told you, you have me here for whatever you need.

[FRANAIRBUS]

hello @Hieromon

I am advancing in the program:

but i found this...

when i use an ACSelect this doesn't work

void getParams_PROBES(AutoConnectAux& aux_PROBES) {

  PROBETYPE1 = aux_PROBES[F("PROBETYPE1")].value;
  PROBETYPE1.trim();

but this yes

void getParams_PROBES(AutoConnectAux& aux_PROBES) {

  //PROBETYPE1 = aux_PROBES[F("PROBETYPE1")].value;
  //PROBETYPE1.trim();

  AutoConnectSelect& acPROBETYPE1 = aux_PROBES["PROBETYPE1"].as<AutoConnectSelect>();
  PROBETYPE1 = acPROBETYPE1.value();
  CALT1 = aux_PROBES[F("CALT1")].value;
  CALT1.trim();
  CALH1 = aux_PROBES[F("CALH1")].value;
  CALH1.trim();

So for ACImput I imagine each of the 2 works, which one should I use?

  AutoConnectImput& acCALT1 = aux_PROBES["CALT1"].as<AutoConnectImput>();
  CALT1 = acCALT1.value;
  
  CALT1 = aux_PROBES[F("CALT1")].value;
  CALT1.trim();

my lack of knowledge does not let me see the difference

Thank you

[Hieromon]

@FRANAIRBUS

PROBETYPE1 = aux_PROBES[F("PROBETYPE1")].value;

AutoConnectSelect has no a value member. It is the value function that retrieves the selected value (which corresponds to the option in the HTML select tag), not the value member. Perhaps you are confusing C++ with other scripting languages.

[Hieromon]

@FRANAIRBUS I pushed the EdgeUnified library. Visit EdgeUnified-eval repository.
Documentation is inadequate and I am currently in the process of writing it up. In the meantime, please refer to the examples and consider how your sketch code fits in.
I have prepared two different split-source file structures that achieve the same functionality as MQTT-GPIO example. One is a partitioning model that conforms to the C++ standard. The other is the "#include LH_XXX.h" method you are envisioning. It is aware of your goal of "simply include existing sketches and assemble the necessary components".

C++11 does not support modules like JavaScript or Python. it was implemented starting with C++20. Thus we cannot use the module syntax in the Espressif toolchain. I have provided an example using the namespace syntax, but this is not the proper usage of the C++ standard. If you are envisioning a module import like JavaScript or Python, that would be something to reconsider. Please consider it.

So, the EdgeUnified-eval repository is available for Discussions. Please go there for matters that need to be discussed and submit issues to Issues.

[FRANAIRBUS]

Hi, I don't think there is much of a problem adapting to the standard, in fact it was planned to make the change.

I understand what you indicate in this comment

The other is the "#include LH_XXX.h" method you are envisioning. It is aware of your goal of "simply include existing sketches and assemble the necessary components".

that it is better to adapt to the standard by example https://github.com/Hieromon/EdgeUnified-eval/tree/main/examples/mqtt

and that the example
https://github.com/Hieromon/EdgeUnified-eval/tree/main/examples/yamqtt
is only for adaptation to a single file?

Thank you for including the 2 examples.

we will start the adaptation and tests for your new library