WebQuery HTTP response code

[makedir]

Hello,

I am using a ESP32-C3 here with default firmware. I want to make two simple rules to send a WebQuery on a SSerial Event

Rule2 ON SSerialReceived#Message DO WebQuery http://URL POST %value% ENDON

and send back a SSerial message, that the WebQuery was delivered. But I cant find any documentation how to parse if WebQuery was successfully delivered. ChatGpt told me to use this:

Rule3 ON WebQuery#Status=200 DO SSerialSend "WebQuery sent" ENDON

But it seems there is no "Status" at all implemented. I found this example here to use something like this:

Rule3 ON WebQuery#Data=Done DO SSerialSend "WebQuery sent" ENDON

This gets parsed, but it always is parsed no matter what.

There is always a RESULT = {"WebQuery":"Done"} sent, no matter if the message was delivered.

You could even do a bogus command like this:

WebQuery http://THIS_URL_DOES_NOT_EXIST POST test

and you still get a :

RESULT = {"WebQuery":"Done"}

---

What is the right way to do this and get a proper HTTP reponse code like 200, or something else to notice the server responded?

[sfromis]

I already answered about what you can do. #13209 (comment)

[makedir]

@sfromis Hello, thanks for answering, but like I already said, this doesnt work. Tasmota always sends back

{"WebQuery":"Done"}

no matter what. if you do a bogus command like WebQuery https://thisurldoesnotexist POST test it also respons with

{"WebQuery":"Done"} and not with {"WebQuery":"Connect failed"}

There is never a error message sent back. is this a bug?

I dont know how to use Berry, the documentation is sadly not really good. If youd like to post a simple Berry example for this if it is just a few lines, I would appreciate that. But I would more like to use Rules because how simple they are for this.

[makedir]

Is there a variable you can check if the wifi is connected and also to get the current gateway? something like

Rule2 ON SSerialReceived#WifiStatus=1 DO SSerialSend2 %wifistatus% ENDON

I cant find any information about this. Also to get the value of the current gateway

Rule2 ON SSerialReceived#PingLan=1 DO ping %gw% ENDON
Rule3 ON Ping#%gw%#Success>0 DO SSerialSend2 PingLanOK ENDON

Why is there no On Ping#Success ? so it would use the last ping? it makes it complicated that Ping# needs an ip in between

I just found some command like Status 5 to get StatusNET information, but how do I get the gw out of the json into a variable and then use it? and how to check from Status 5 if wifi is connected? Would I be able to get the information somehow with ON StatusNET#Data ? but how to retrieve a specific value and send it back over SSerialSend2 ?

And how do I put the device into Wifi discovery so you can enter a new wifi ssid and password via its web interface without deleting any configs? Typing in WifiConfig doesnt work, the documentation is unclear what parameter to use for this. is it WifiConfig 2?

[sfromis]

Read the docs for available rule variables, and thus also what is not there:
https://tasmota.github.io/docs/Rules/#rule-variables
And triggers, including Wifi getting dis/connected:
https://tasmota.github.io/docs/Rules/#examples-of-available-triggers
Also JSON parsing from commands you may have issued, just like you are already doing with WebQuery.

You are getting past the point where using rules is as straightforward as you hoped for, with Berry having function calls for easy checking whether Wifi is connected, or one-step execution of a command and getting a value from the command response - instead of the contortions with rules only having rudimentary features.

The reason for not having a different format for basing triggers off Ping, is that there are no "ping triggers", like not at all. What you have is JSON-based triggers needing to fully match the structure of the JSON you have available. However, if you had spent a bit of time on the docs about rule triggers, you could have seen that wildcards are supported.

Sometimes, just try things instead of asking when you already have a guess at an answer.

[makedir]

Sadly Berry is no option because I find it really confusing how to use Berry on Tasmota, there is no true way to program in functions in an easy way, how do you save in functions for example. then also no intuitive way to see how you do events with Berry, so functions are called on Rule event triggers.

How would I implement the same in Berry like this for example?

Rule2 ON SSerialReceived#Nachricht DO Backlog WebQuery https://ntfy.sh/MYTOPIC POST %value% ENDON ON

[sfromis]

As I already posted:

The docs for Berry does include basic examples for how to do triggers and code in Berry.
https://tasmota.github.io/docs/Berry/#rules

A direct match for your rule now would be:

tasmota.add_rule('SSerialReceived#Nachricht',
  def (value,trigger,data)
    tasmota.cmd(f'Backlog WebQuery https://ntfy.sh/MYTOPIC POST {value}')
  end)

Sure, this is not shorter; where Berry wins is when starting to combine things, without weird workaround for limitations with rules.

A fuller implementation would be to replace the use of WebQuery, something along the lines of:

tasmota.add_rule('SSerialReceived#Nachricht',
  def (value,trigger,data)
    var wc = webclient()
    wc.begin('https://ntfy.sh/MYTOPIC')
    var status = wc.POST(f'{value}')
    var response = wc.get_string()
    print(f'ntfy.sh {status=} {response=}')
    wc.close()
    if status == 200
      tasmota.cmd('SSerialSend2 WebQuerySent')
    else 
      tasmota.cmd('SSerialSend2 WebQueryError')
    end
  end)

The point is that after getting started, there is not so much frustration with you basically "insisting" on rules being "simple" without knowing about the weird and arcane contortions it takes to use rule for more than rudimentary things, instead aiming for what you are used to do with "real programming" like you can do with Java and other actual programming languages. Rules ain't there.

Next level could be to no longer use SSerialSend but use the serial class in Berry.

And details like having more straightforward access to things like Wifi connection status and getting data from commands.

And functions are very easy to create.

  def myfunction(arg)
    var wifistatus = tasmota.wifi('up')
    print(f'Hello {arg}, {wifi=}')
  end
  myfunction('world')

Berry code should be saved in the file system, but you can also do simple experimentation in the Berry console.

[makedir]

Thank you !! I think I need to get into Berry like you said, and your examples will help me a lot. No I meant like, where do you write them? I mean you mostly need to copy some files on the device somehow, like myscript.berry or something and then how do you "prime" it, so it is automatically run at boot time and also in the background as services?

That example with tasmota.add_rule, is that really Berry? Or does that just add a Tasmota Rule, so you would again hit a wall at 3 rules? are these commands a one time thing or how does it work? where to put them, is there a global autorun.file or something? and if you remove the line tasmota.add_rule the rule is automatically deleted?

what is the f for in the syntax like (f' ?

Can you just put "infinite" tasmota.add_rule in a script file and they all work?

So all events like "SSerialReceived#..." also work in Berry with the same names and syntax? Is there a complete list somewhere for Events in Berry with examples?

Then if you convert the three rules to tasmota.add_rule, you delete the rules in the console with rule1-3 ''?

[makedir]

It seems there is a file called autoexec.be which will be executed at boot time, not sure why this is not in the Berry for starters guide as the very first guide part, because, that is mostly the most important information people need, where to put the code, how to execute it at boot time.

so it would go like this? is there a way to "reload" the file without rebooting? seems you can run a load('autoexec.be') in the berry console. will all commands in the file replace the previous loaded rules or berry commands? so if you remove them theyre also gone, or are they somehow saved like rules, and you need to clear them?

Also what is the file _persist.json ? I dont see the file on another ESP device of mine.

[sfromis]

My example with tasmota.add_rule is 100% Berry, not even related to "classic" rules, only similarity is that both use a similar syntax for the triggers relating to events, and the same triggers are available both places. Like also with "classic" rules there can be no "complete list", as any JSON-formatted event message is automatically a candidate, even ones you may create yourself.

Within available memory, there is no limit to how much Berry code you can have, including this type. No automatic deletion, outside of restarts, hence all will go away unless you made sure to have it saved. If you want to experiment with multiple iterations of add_rule, better include the id parameter to be able to overwrite the old version (or use remove_rule first).

As a starting point, you can have code in the file autoexec.be which will be automatically executed after boot. You can unsurprisingly also have myscript.be which you can load/execute with load('myscript.be') (which you can also put in autoexec.be if you like to avoid having specific code in that general file.

The syntax with f-strings is "borrowed" from python, the basic meaning is that you have a string format, where you can embed variables with {varname}, instead of separate steps to put the variable into the string. It is also possible to have formatting specifications, similar to Java String.format like f'Temperature: {temp:.2f}}°C' (corresponding to %.2f`)

[sfromis]

I think I answered the additional questions from while I wrote. And the file you ask about is related to the persist module, a handy mechanism for similar purposes as Mem variables in rules.
https://tasmota.github.io/docs/Berry/#persist-module