UI button missing after tasmota hangup

[ouinouin]

Hi, while fiddling around wit berry , suddenly tasmota hanged, so i rebooted, but then i cant find anymore the webui button to go to the berry console , im on esp32C3 , i noticed that many buttons disapperaed : the autoconfig button, the matter button etc etc. does anyone have an idea of what could have happened ?

[ouinouin]

auto answering : the problem remained even after a reflash, i then removed all files including my autoexec.be and then recovered all the missing webui buttons .
after many tries , i see that the culprit is my autoexec.be , i ll further investigate but nowhere the device tell me that my code is failing.

edit : my code is not failing (and working properly) while pasting in the console , but as soon as i paste it in autoexec.be file, i loose all the forementionned UI buttons
edit2 while in this situation (after uploading the autoexec.be), going to the tasmota console and issuing : brrestart 1 gives me back the buttons . is the code behind those buttons programmed in berry ?
edit3 : while testing , i see thqt on the console while the berry ails to load this message appears : 00:00:00.041 FRC: Some settings have been reset (5)

[sfromis]

As you are giving no details about exactly what your autoexec.be is doing, no basis for working out why it fails.

On a general level, the Berry console button depends the Berry VM being able to initialize at all. As a "normal" failure in autoexec.be is only after Berry was already initialized, a simple failure (like division by zero) in autoexec.be does not explain why the button failed to appear.

It is "not impossible" that initialization failures may be rooted as the hardware level, like not having good stable power available. This was not meant to suggest "that's why", only to illustrate that details matter a lot to working out issues.

And no, the button "Berry Scripting console" (or the Tools menu in general) is not produced by Berry code.

[ouinouin]

@sfromis thanks for useful hints, i finally understood that yes, it really the code having some impact , i added some delay to start the code.
( i m pretty sure you ll mention that it wouldnt have occured if i did register the code as a driver :-).
as per my tests , the culprit was cl.GET() from the webclient library , that is quasi immediately triggered in my code, and i m guessing nothing is set and it has a negative impact. addint the "waitme" timer of 10 seconds solved the issue.
Maybe we ll see in a near future some berry functions able to return the boot ended / connected state a bit like we have with the triggers on the native rules.

import string
#import mqtt
#import persist
#import introspect
import json
#we must decouple buttons from relays setoption....
#we get values directly from esphome rest api 
# http://192.168.7.253/sensor/bmv700_state_of_charge
#sensor-bmv700_state_of_charge

var load_index = 0 #index 0 means the first relay
var state_of_charge_json
var state_of_charge = 0
var testmode = 0
var testvalue = 50
var SOC_to_start_load = 90
var SOC_to_stop_load = 75
var init_ok = false

def hysteresis(value,last_state,setpoint_low,setpoint_high)
    if  last_state == nil
        last_state = false
    end
#returns true if > setpoint_high and false if < to setpoint_low, returns last value in case nothing changes
    if   value > setpoint_high
        return true
    elif value < setpoint_low
        return false
    else
        return last_state
    end
end
    

def start_load()
    print("function start_load: starting load")
    tasmota.set_power(load_index,true)
end

def stop_load()
    print("function stop_load: stopping load")
    tasmota.set_power(load_index,false)
end

### init ###
print("establish connection to esphome")
cl = webclient()
cl.begin("http://192.168.7.253/sensor/bmv700_state_of_charge")


def loopme()
    
    if cl.GET() == 200
        state_of_charge_json = json.load(cl.get_string())
        state_of_charge= number(state_of_charge_json.item("value"))
        print("got a value from remote Rest API , sstate of charge value  is : ", state_of_charge ," % ")
    end

    if cl.GET() != 200
        stop_load()
        print("couldnt reach esphome Rest service, stopping the load")
    end

    if state_of_charge != nil && cl.GET() == 200
        print("launch hysteresis function , setting relay if needed")
        if testmode == 0
            #setting the power only on state change
            if hysteresis(state_of_charge,tasmota.get_power(load_index),SOC_to_stop_load,SOC_to_start_load) != tasmota.get_power(load_index)
                tasmota.set_power(load_index,hysteresis(state_of_charge,tasmota.get_power(load_index),SOC_to_stop_load,SOC_to_start_load))
                print("relay state changed")
            elif 
                print("hysteresis inital and final state are identical , no action" )
            end
        elif testmode == 1
            print("in test mode")
            #setting the power only on state change
            if hysteresis(state_of_charge,tasmota.get_power(load_index),SOC_to_stop_load,SOC_to_start_load) != tasmota.get_power(load_index)
                tasmota.set_power(load_index,hysteresis(state_of_charge,tasmota.get_power(load_index),SOC_to_stop_load,SOC_to_start_load))
                print("relay state changed")
            elif 
                print("hysteresis inital and final state are identical , no action" )
            end
        end
        
        print("relay value : ", tasmota.get_power(load_index) )
    end
    tasmota.set_timer(5000, loopme, 1)
end


## lazy function to wait full wifi start
def waitme()
    init_ok = true
    loopme()
end
### loop ###
tasmota.set_timer(10000, waitme, 2)

[sfromis]

Using webclient before Wifi connection is indeed pretty bad. You could postpone your initialization till a trigger like System#Boot (Tasmota fully initialized), as a more robust alternative to hardcoding 10 seconds. Something like: tasmota.add_rule('System#Boot', loopme) (Skipped the setting of init_ok as this is not used for anything.

Registering as a driver would not really make a difference to the issue of using webclient without Wifi, and I don't see the code doing anything a good fit for being a driver.

You could also use a cron for repeated execution, instead of using tasmota.set_timer:
tasmota.add_cron(*/5 * * * * *', loopme)

[s-hadinger]

Also you should call wc.GET() only once per loop, and store the result in a variable. The call has some strong side effects.