Berry script adding a button to the configuration menu works but event isn´t working

[nobodyman1]

PROBLEM DESCRIPTION

I want to have an additional button in the config menu.
Therefore I tried the example Adding a button to the Main menu.
The button is visible in the config menu. But if I press the button nothing happens (no output in the log).
The button in the main menu works as expected.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues
• Searched the problem in discussions
• Searched the problem in the docs
• Searched the problem in the chat
• Device used (e.g., Sonoff Basic): ESP32C3
• Tasmota binary firmware version number used: 12.5.0
  • Pre-compiled
  • Self-compiled
• Flashing tools used: _____
• Provide the output of command: Backlog Template; Module; GPIO 255:

  Configuration output here:

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

• Provide the output of this command: Status 0:

  STATUS 0 output here:

• Set weblog to 4 and then, when you experience your issue, provide the output of the Console log:

  Console output here:

TO REPRODUCE

1. Insert the simplified script from documentation into berry scripting console.
2. Open config menu and press "Toggle Conf" button.
3. Open console and check log.

import webserver # import webserver class

class MyButtonMethods : Driver

  #- create a method for adding a button to the main menu -#
  def web_add_main_button()
    webserver.content_send("<p></p><button onclick='la(\"&m_toggle_main=1\");'>Toggle Main</button>")
  end

  #- create a method for adding a button to the configuration menu-#
  def web_add_config_button()
    #- the onclick function "la" takes the function name and the respective value you want to send as an argument -#
    webserver.content_send("<p></p><button onclick='la(\"&m_toggle_conf=1\");'>Toggle Conf</button>")
  end

  #- As we can add only one sensor method we will have to combine them besides all other sensor readings in one method -#
  def web_sensor()

    if webserver.has_arg("m_toggle_main")
      print("main button pressed")
    end

    if webserver.has_arg("m_toggle_conf") # takes a string as argument name and returns a boolean
      print("config button pressed")
    end

    end
  end
d1 = MyButtonMethods()
tasmota.add_driver(d1)

EXPECTED BEHAVIOUR

"config button pressed" visible in the log.

SCREENSHOTS

ADDITIONAL CONTEXT

(Please, remember to close the issue when the problem has been addressed)

[sfromis]

From what I can see, using web_sensor() is only useful for the main page, as the purpose of that callback is to allow you to add sensor values rendered on the main page. And I confirmed that web_sensor() is not called for the configuration page button. Not sure what the intention for such a button as in the example is, but a tool like Auto-configration is instead handling the configuration page button via webserver.on(), and a corresponding form action in the button.

Maybe @s-hadinger can suggest how configuration page buttons are supposed to work? Looking for pertinent callback, I did not spot a good candidate... It did not work in every_second(); was not really expecting that anyway.

[s-hadinger]

For the configuration page, you need to define an HTML form.

Example from Matter UI:

  def web_add_config_button()
    import webserver
    webserver.content_send("<p><form id=ac action='matterc' style='display: block;' method='get'><button>Configure Matter</button></form></p>")
  end

You also need to register to the sub-url:

  #- ---------------------------------------------------------------------- -#
  # respond to web_add_handler() event to register web listeners
  #- ---------------------------------------------------------------------- -#
  #- this is called at Tasmota start-up, as soon as Wifi/Eth is up and web server running -#
  def web_add_handler()
    import webserver
    #- we need to register a closure, not just a function, that captures the current instance -#
    webserver.on("/matterc", / -> self.page_part_mgr(), webserver.HTTP_GET)
    webserver.on("/matterc", / -> self.page_part_ctl(), webserver.HTTP_POST)
  end

[nobodyman1]

Could you please provide a complete but simple working example?
I already started another discussion before ( #18700) because I don´t know how to implement this.
My intention is to have an additional button to switch a driver on or off (but the button shouldn't be on the main page).
I have some values which I want to have editable. Therefore it would be nice to have some numeric up/down controls to set these values.

[ChrisVonFrosta]

https://github.com/arendst/Tasmota/blob/development/tasmota/berry/artnet/artnet_ui.be.

Could you or @s-hadinger (the author?) explain the purpose of 'dyn()' in artnet_dyn.be? I don’t understand why this class 'dyn()' is used. It returns a map when the init-method is called ( var conf = dyn() ).
Why not just: var conf ={}?
according to the comment which states:
'Allows to use a map with members.'
What does 'members' mean? The method 'find()' is available for both strings and maps, suggesting 'members' are not the same as 'keys'. I found no use of the methods (member and setmember) of the dyn class except for 'init()'.

When I first started using 'persist,' I accessed its content directly, without using the method find(). However, I see the advantage of using find() to return 'nil' if there is no object with the 'key'.
Until now, I've used it this way:

var value = persist.value

# or 

var value = {}
var value = persist.value["value1"]    # better use persist.find to get nil if key/value not exits

[sfromis]

The purpose of that dyn class is to be able to use a syntax like
conf.gpio = ... instead of conf['gpio'] = ... and
print(conf.gpio) instead of print(conf['gpio'])
That is what is meant by "members", which is merely the plural of a common english word. Did you follow the link suggested in the source code of the class?

It refers to Virtual members. If you prefer nil for non-existent values, you can modify the class to do that instead of undefined.

BTW. Assuming that you're using the standard persist module, the last line of the example you posted of what you've used is nonsensical, cannot work.

[ChrisVonFrosta]

thank you. Now, I see the point.

And you are right.
it should be:

var value = {}
var value["value1"] = persist.value["value1"]    # better use persist.find to get nil if key/value not exits

[sfromis]

var value["value1"] = persist.value["value1"]

Nope, you are not creating a variable by assigning to a member. And your syntax for persist is what was badly nonsensical. The persist module has no value method.

[ChrisVonFrosta]

my fault.i tried to show a quick example out of my mind.

i used it with list of maps.

[nobodyman1]

Thank you very much!

I found another simple example: web_handler_demo.

It works if I upload the code to the Berry Scripting console.
I inserted the code into autoexec.be (without web_page_demo_instance.web_add_handler()) and after Tasmota restart the driver is loaded as expected.
But I want to save to code to a file called web_page_demo.be because I want to start multiple drivers.
What steps are required get autostart working again?

[sfromis]

Simplest case is to use load('web_page_demo.be') from autoexec.be to load such files at boot time.

More advanced usage could be to package it into a Tasmota Application file (.tapp), such files are automatically loaded at boot.

[nobodyman1]

Ok, it works.

I want to use cyclic function to get data using webclient class.
if I copy the script to the Berry Scripting console it works, but if the class is loaded automatically it doesn´t work.
I think this is because the network isn´t ready.
How do I get the network state, e.g. Wifi connection established?

[sfromis]

Well, if network state is the issue, reasonable code would then work when network becomes available, as it should also be able to survive any outages. But you posted no info about what you're doing, or what debugging you did do (or not). Anyway, writing "doesn't work" is useless, as it does not tell anything about what happens.

You can get network state using tasmota.wifi() and/or tasmota.eth(). You also have a number of triggers for network/mqtt up/down.

[s-hadinger]

Use something like:

if tasmota.wifi()['up'] || tasmota.eth()['up']

The 'up' member is always present. It's a boolean indicating if the wifi/ethernet is connected and has an IP address.

[nobodyman1]

Thanks again, but I still get some timeouts. After WIF: Connected it is working correctly.
Is it possible to detect this state (or the following one HTP: Web server active on ...)?

[s-hadinger]

tasmota.wifi()['up'] is true only if Wifi is connected and an IP address is available (DHCP completed). The Web server starts as soon as DHCP is completed.

[sfromis]

still get some timeouts

What does that specifically mean? Do you mean "not yet connected, but trying"? And what difference does that even make? Why do you think that network state is relevant to what you're doing with a configuration menu button?

You did not explain this:

I think this is because the network isn´t ready.

[nobodyman1]

Sorry that I didn´t explain exactly what I´m going to do.
Maybe it´s better to add a new discussion because the buttons are working now?

I want to collect some data from other devices (e.g. OpenDTU which gets data from my solar inverter).
Therefore I need some configuration fields like IP address and serial number.
With your given example I implemented a configuration menu to set these options and autostart option for the driver.
I´m using the webclient class to get data from the API.
I added the function call to every_second().
When everything is configured and I restart Tasmota I still get some timeouts from the function which calls the webclient GET() function. (I used set_timeouts(500)!)

00:00:00.994 BRY: Successfully loaded 'autoexec.be'
00:00:01.649 WIF: verbinden mit AP1 xxx ...
00:00:02.018 HTP: Connection timeout after -1 ms
00:00:02.019 INVERTER: get_status response -1
00:00:02.023 HTP: Connection timeout after -1 ms
00:00:02.861 HTP: Connection timeout after -1 ms
00:00:02.862 INVERTER: get_status response -1
00:00:02.870 HTP: Connection timeout after -1 ms
00:00:06.434 WIF: verbunden
17:39:17.429 HTP: Web-Server aktiv bei tasmota-xxx mit IP-Adresse xxx

By the way: what does HTP: Connection timeout after -1 ms mean? (-1 is the response code from the GET() function.)

If I insert the same code to the Berry Scripting console there is no error!
Therefore i think I have to ensure that the weblient class is able to connect to other devices and I have to check the network state first.
But using tasmota.wifi()['up'] seems to be not sufficient.

[sfromis]

As I wrote earlier: "You also have a number of triggers for network/mqtt up/down". Specifically, you could use Wifi#Connected as a point to start your process with using webclient.

To get back the more central issue. Just do not write "doesn't work" instead of explaining what happens. Doing a bit of testing, I observed that Tasmota was crashing if using webclient before having a connection. I think that @s-hadinger was going into look into this "pesky detail". But if I then used tasmota.wifi()['up'] in the every_second() callback to exit instead of calling webclient, I had no trouble if the one-second ticker was started before having a network connection.

What do you mean by "seems to be not sufficient"? Using those words makes it impossible to guess why you think so, and what happens when you try to use the suggested method.

[nobodyman1]

I´m sorry, I noticed that you mentioned the triggers but it´s not easy for a beginner in Tasmota to understand how everything works.
Do I have to write a rule to set a variable or is it possible directly in Berry?

Ok, you´re right. I try to be more precise instead of talking about "doesn´t work".
With "seems to be not sufficient" I mean that I still have this timeout messages although I´m checking tasmota.wifi()['up'].

[sfromis]

Well, seeing timeout messages has nothing to do with whether you have tasmota.wifi()['up'], which only can guard what your Berry code does. It is commonly seen with a few timeout messages while "not yet connected, but trying", no matter if you have any Berry code running, or not.

Here's how you can use those triggers in Berry. https://tasmota.github.io/docs/Berry/#rules
While the naming + syntax of the triggers is "similar" to classic Tasmota rules, it is completely different code, and you cannot see the two ways of having "rules" as interchangeable.
Anyway, you should be able to have your code working even if initiated before Wifi connection, hence no "requirement" to defer driver initialization. But right now you may have crashes if not guarding your code with tasmota.wifi()['up']