Berry: Exception> 'internal_error' - no more slots for webserver hooks

[lennycb]

Hello everyone,
Can someone explain the error to me?

Are the hooks being limited?

How can I work around this?

Thanks!

[s-hadinger]

Berry needs to keep track of all webhooks because of Arduino limitations. The compile constant WEBSERVER_REQ_HANDLER_HOOK_MAX sets the maximum number of slots, 16 by default.

Either increase this compile time constant or try to reduce the number of webserver.on() calls

[lennycb]

Okay, first of all, thank you very much for the input.

I'm using several Berry files in the program, each of which contains webserver.on() twice. The error message appears when I add a sixth file. So, a total of 12 webserver.on() occurrences.

Do the remaining four come from the original Tasmota code?

A quick note about the program. There are several "submenus," each with its own file (e.g., Umluft_ui.be).

Each of these files contains the following code (the file has also been adapted):

def web_add_handler()
webserver.on("/Umluft_ui", / -> self.page_Umluft_ui(), webserver.HTTP_GET)
webserver.on("/Umluft_ui", / -> self.page_Umluft_ctl(), webserver.HTTP_POST)
end

Can I write this differently so that I comply with the Arduino restrictions?

[s-hadinger]

Maybe let me explain the problem first. The Arduino framework accepts only a single parameter to web hooks: a callback address of a C function. Also it does not provide any way to remove or change a web hook when it's set up.

The problem is that you can't generate distinguish callback addresses of C functions at runtime through scripts. So the callbacks must be pre-populated and used as they are needed.

The whole "dance" needed to create the callbacks is there:

https://github.com/arendst/Tasmota/blob/1e74d6fd4dfa26d4e3e4ff05a12acf59edd9b9bb/lib/libesp32/berry_tasmota/src/be_webserver_lib.c#L45-L92

So increasing the number of hooks is not that simple, and needs to add more code.

[s-hadinger]

One idea would be to have only 1 or 2 hooks (one for GET and ont for POST) and dispatch yourself within your code.

[lennycb]

Okay, but sorry for the questions. I'm just starting out with Berry.
This is how I understand it now:

Before a submenu (e.g., http://192.168.8.130/Umluft_ui?) is called, the following MUST be defined in the code:

def web_add_handler()
  webserver.on("/Umluft_ui", / -> self.page_Umluft_ui(), webserver.HTTP_GET)
  webserver.on("/Umluft_ui", / -> self.page_Umluft_ctl(), webserver.HTTP_POST)
end

Is that correct?

I would have assumed I could change this directly at runtime.
So something like this:

• I add the following code to the autoexec.be:

def variableHandler()
  var c = # how do I call this???
    if c == "/Umluft_ui"
      webserver.on("/Umluft_ui", / -> Umluft_UI.page_Umluft_ui(), webserver.HTTP_GET)
      webserver.on("/Umluft_ui", / -> Umluft_UI.page_Umluft_ctl(), webserver.HTTP_POST)
    elif c == "/Licht_ui"
      webserver.on("Licht_ui", / -> Licht_UI.page_Licht_ui(), webserver.HTTP_GET)
      webserver.on("/Licht_ui", / -> Licht_UI.page_Licht_ctl(), webserver.HTTP_POST)
    end
end

Then at least I would always have only 2 hooks, no matter how many submenus I have.
Is that what you meant with your last sentence?

[sfromis]

I think that it depends on details of what exactly you're doing. Your first post sounded like you have 6 different names like Umluft_ui and wanting to have both GET and POST for each, adding up to 12 webserver.on, as you want to have all 6 active at the same time. Such usage could be consolidated into calls like:
webserver.on('ui', /-> UI.select_ui, webserver.HTTP_GET)
webserver.on('ui', /-> UI.select_ctl, webserver.HTTP_POST)
That would require those select functions to recognize a parameter, and then call the relevant handler, based on URL's like: /UI?select=Umluft&someparm=value

In any case, you can do each of your webserver.on once only, as you cannot update them without restarting.

Not clear what you mean by that variableHanlder function you posted now, like when you'd call it, and if you can only have two values of c

[lennycb]

Sorry for the late reply...

I'll briefly explain what I'm trying to do:

• On the Tasmota main page, there's a button that leads to the first submenu
• This submenu should contain up to 10 buttons, each of which points to its own submenu (e.g., /Umluft_ui, /Licht_ui, etc.)
• The settings (e.g., time, speed, etc.) are to be configured in these submenus

To avoid confusion during programming, each submenu has its own file (e.g., Umluft_ui.be, Licht_ui.be, etc.)

I'm still very new to Berry Script and therefore still need this clarity :-)
Consequently, each of these files contains this code:

def web_add_handler()
  webserver.on("/Umluft_ui", / -> self.page_Umluft_ui(), webserver.HTTP_GET)
  webserver.on("/Umluft_ui", / -> self.page_Umluft_ctl(), webserver.HTTP_POST)
end

or

def web_add_handler()
  webserver.on("/Licht_ui", / -> self.page_Licht_ui(), webserver.HTTP_GET)
  webserver.on("/Licht_ui", / -> self.page_Licht_ctl(), webserver.HTTP_POST)
end

Now the problem is that with this approach, the slots of the web server hooks are insufficient.
Hence my idea to write the code globally in the autoexec.be so that every time the submenu is called (pressing the button), the correct webserver.on is triggered.
(variableHandler was just a name - it could also be variableWebserver)
Example:

def variableHandler()
var c = # how do I call this???
if c == "/Umluft_ui"
webserver.on("/Umluft_ui", / -> Umluft_UI.page_Umluft_ui(), webserver.HTTP_GET)
webserver.on("/Umluft_ui", / -> Umluft_UI.page_Umluft_ctl(), webserver.HTTP_POST)
elif c == "/Licht_ui"
webserver.on("Licht_ui", / -> Licht_UI.page_Licht_ui(), webserver.HTTP_GET)
webserver.on("/Licht_ui", / -> Licht_UI.page_Licht_ui(), webserver.HTTP_POST)
end
end

So c is the expression when the button for the /Umluft_ui submenu is pressed. This could then be evaluated and the correct webserver.on selected.
Unfortunately, I have no idea if that would work.

BUT, you write that webserver.on must be loaded at startup; otherwise, no update will occur. So, what you wrote above won't work.

I have no idea how to solve this.
Therefore, any help is welcome!

[sfromis]

Without details of how and when that variableHandler function is going to be used, and how many webserver.on needs to be registered at the same time, feasibility of that approach is hard to guess. If only 4 are needed, it should be doable.

Still, the key is that you should only register the same webserver.on name one time each boot. While it is recommended to do it at startup, it can also happen later, just don't do it again for the same name.

Note that whatever function you use with webserver.on will be the only relevant one for that name, meaning that the class/instance will have to already be ready before the webserver.on is called, and if you want to do it in later loaded classes, those will have to ensure that they are not making the webserver.on again, and you cannot discard a class instance if the function to be called depends on the class instance.

Thus, the simplest approach may be to initialize all your handlers at startup, and of course make sure that you that do not get to the max number. And no problem keeping the webserver.on in each class, as long as the class will only be loaded/instantiated once.

[lennycb]

@sfromis
Thank you for the detailed explanation. As I said, I'm very new to Berry.
So I (still) understand very little of what's been written.

Without details of how and when that variableHandler function is going to be used, and how many webserver.on needs to be registered at the same time, the feasibility of that approach is hard to guess. If only 4 are needed, it should be doable.

I described at the beginning what should happen.

The idea with "variableHandler" was just an idea of ​​how I could make the code around "webserver.on" dynamic.
Doesn't work, if I interpret the statements in the text correctly.

I'm also not sure how many webserver.on need to be registered at the same time. "When" and "where" this needs to happen are unclear to me.

All I know is that all ".be" files are loaded at boot time, and consequently, all the webserver.on files they contain are also registered.

This leads to the original error.

Perhaps I should rephrase the question:

How can I reduce the number of webserver.on registrations without losing functionality?

Please provide an example.

[sfromis]

The basics are important to have a common understanding of, like exactly how many different webserver.on you want to have on the device, as a maximum of what should work. You cannot substitute those after booting. If you want to be able to have more than the allowable max of around 10, you need a different URL strategy, and you cannot get around this by dynamically activating some, to replace others.

Assuming that you want "too many", what you could do would be to reduce the number you need to have, by using a different URL structure, like I already tried to explain:

I think that it depends on details of what exactly you're doing. Your first post sounded like you have 6 different names like Umluft_ui and wanting to have both GET and POST for each, adding up to 12 webserver.on, as you want to have all 6 active at the same time. Such usage could be consolidated into calls like:
webserver.on('ui', /-> UI.select_ui, webserver.HTTP_GET)
webserver.on('ui', /-> UI.select_ctl, webserver.HTTP_POST)
That would require those select functions to recognize a parameter, and then call the relevant handler, based on URL's like: /UI?select=Umluft&someparm=value

My usage of the word "consolidated" was an attempt to be more precise about being "dynamic". The point is that a different URL structure would allow the same webserver.on to be used to call different handlers, by having the identification of handler being based on a parameter in the query string part of the request, instead of being in the path. Then the broader handler would take what's in the select parameter, and then call the appropriate handler for each.

For context, URL structure is http://host/path?querystring, meaning that "path" is before the ?, and "query string" is the part after having a ?.

This way you might be able to get down to only two webserver.on, one for GET and one for POST, with the rest being managed by a paramter like select in my example URL structure above.

[lennycb]

@sfromis
OK, I think I get it.

In summary, it won't work in my case.
I don't have a query string to evaluate.
So I'll have to think of something else.

Here is another picture, maybe it makes the idea clearer:
On the left is the Tasmota main menu, in the middle is the first submenu and on the right are the settings.

[sfromis]

Well, a query string is not something you "have", it is something you create in a way useful to you. When you are adding buttons, the html you use will contain query string segments for the URL to be used.

As a illustrative example (not really a "recommendation"), here's a small bit of code creating two buttons on the Tasmota front page, using the same handler method, but getting a name and argument from what button was pushed.

class UIbutton

  var name1,name2,arg1,arg2

  def init()
    self.name1='testButton1'  self.arg1=123
    self.name2='testButton2'  self.arg2=456
    tasmota.add_driver(self)
  end

  def web_add_main_button()
    import webserver
    webserver.content_send(f"<p></p><button onclick='la(\"&button={self.name1}&arg={self.arg1}\");'>{self.name1}</button>")
    webserver.content_send(f"<p></p><button onclick='la(\"&button={self.name2}&arg={self.arg2}\");'>{self.name2}</button>")
  end

  def web_sensor()
    import webserver
    if webserver.has_arg('button')
      var button = webserver.arg('button')
      var arg = webserver.arg('arg')
      print(f'{button=} {arg=}')
    end
  end

end

ui = UIbutton()

When executed, and I click the two buttons, I'm getting:

button=testButton1 arg=123
button=testButton2 arg=456

It would be simple to have the web_sensor function call two different handler functions based on the "button" argument, and even have a further argument if useful.

You should be able to do similar things when you create your own web UI elements.