Jason2866
commented
1 year ago Tasmota is designed to be used with mqtt. Do not expect near real time behaviour when using http.
Closed digital-spinner closed 1 year ago
Jason2866
commented
1 year ago Tasmota is designed to be used with mqtt. Do not expect near real time behaviour when using http.
digital-spinner
commented
1 year ago Hola, wait a minute! I didn't say anything about the real time behavior and don't be rude man. The WebSend is just slow as hell comparing to other solutions and I'm not even mentioning the random delay of it's processing capabilities and occasional connection issues of that. If this is the case just remove the whole websend / webquery stuff from it so there will be no confusion of any kind. I just bought those devices only because of this functionality. And yea, I can go with MQTT later, but I hope you understand the confusion?
And the last one thing at the end: Tasmota is great without the doubts and it's power comes from "simplicity".
barbudor
commented
1 year ago Hi @digital-spinner I see 2 parts from you issue
I would suggest first to treat them separately starting with the rule If you replace the websend by something purely internal to Tasmota like incrementing a variable or toggling a native relay on gpio, what is your experience? Do you see delay? Randomness?
Regarding the delay on websend (WebQuery could seem more logical for non tasmota target although it's a matter or syntax as it's the same code behind) you would need an analysis at a network level which is not easy to qualify if the delay is from Tasmota or the device or the network
sfromis
commented
1 year ago My experience testing WebSend (or the better implementation WebQuery) is that I get quick reactions, as long as the server responds quickly, but any latency in server (or network) slows down processing, just like when I use a browser and a web server. WebSend is not "fire and forget", but depends on getting a response, unlike the asynchronous MQTT which works much better for such expectations.
I did not see any "rude" behavior from Jason, you should expect different styles from different people, including short matter-of-fact responses. And it is correct that http is not at the core of Tasmota design, more like an added tangent without focusing on tuning this part.
digital-spinner
commented
1 year ago If i just type the Websend in the console it has the same random delay behave. I mean, the first time after long period of not doing anything it usually fires immediately, but after even like 5 seconds next press (or next console command) is a lotery - it may execute like within 2-3 seconds or it will execute like after 5 or so. It looks like it can't be used more often than once per 10 seconds at least. And again it doesn't happen with some other devices (Blebox with thier API capabilities) so that is why I'm mentioning it here at first place. It is a possibility to improve if of course can be done.
barbudor
commented
1 year ago If I understand well what you describe, it's mostly pointing in delay in the whole http communication Definitively needs network analysis (tcpdump/wireshark). If you have an http workflow from another device than Tasmota, both need capture to allow comparison
Improvement can only occur if something missing is identified, and identification can only come from your size (your network, you device)
digital-spinner
commented
1 year ago I think the issue is with scheduling internal execution with Tasmota itself not the network issues, but for my curiosity I will check another Tasmota device if this is a case and let know if anything is changed for worse or better but.. when I click toggle on web panel it reacts immediately for those power outputs which it has (all my devices reacts momentarily), also relays reacts immediately on buttons reactions. Maybe there is a way to prioritize the HTTP over MQTT (an option switch for that) so the HTTP will have a precedence if it consumes some CPU cycles which is less and less after each action because MQTT is working or some other stuff (but I have the MQTT disable on my devices currently).
Anyway it makes sense to have a low priority for the HTTP API support if the MQTT solution is aimed for speed and reliability.. I think I'm gonna get rid of the HTTP devices and put the MQTT to use but i need some time to do that and I have already like 3 other projects to work on :-( And the HTTP API is so simple and easy to use..
sfromis
commented
1 year ago The "low priority" for HTTP is not about scheduling or CPU cycles, but about implementation. It is "tacked on", but by far not seen as a "primary strategy"
Not much has been done to create "optimal" implementations of using HTTP, even on the inherently slower terms of using this protocol, which is based on starting and closing sessions per request, instead of MQTT using a persistent session, leading to fewer network round trips.
As MQTT can be "fire and forget", Tasmota will not be delayed by the time it takes to serve the message, unlike HTTP. OTOH, a request/response strategy is more cumbersome with MQTT, as this is not part of the protocol.
digital-spinner
commented
1 year ago @sfromis thanks for the explanation, good to know that. Just one additional question to that - just wonder about one thing (don't know how it is done here) are those MQTT messeges acknowledged or not (sent by Tasmota). I know it can be both ways with MQTT right? So the brocker ACK can also be problematic if I understand correctly. Also MQTT uses TCP so the connection itself needs to be acknowledged.
sfromis
commented
1 year ago While MQTT uses TCP, each client has one persistent connection while available, until outages of either end or network. Ideally up to years, but at the least it should be hours.
As Tasmota only uses QoS 0 "at most once" with MQTT, delivery is not assured.
The minimal QoS level is zero. This service level guarantees a best-effort delivery. There is no guarantee of delivery. The recipient does not acknowledge receipt of the message and the message is not stored and re-transmitted by the sender. QoS level 0 is often called “fire and forget” and provides the same guarantee as the underlying TCP protocol.
In practice, HTTP provides no better delivery assurance, but the requestor does have the option of checking for a response.
digital-spinner
commented
1 year ago Thank you!
barbudor
commented
1 year ago I just played alittle game between an ESP32-DevKit and an ESP8266-NoceMCU
Each have a relay
Each have a rule like on power1#state do websend [ip of the ohter] power toggle endon
That's the Tamsota version of the stupid machine
Here is the log I have:
21:58:07.387 RUL: POWER1#STATE performs "websend [192.168.168.195] power toggle"
21:58:07.508 MQT: stat/esp32dev3/WEBQUERY = {"WebQuery":{"POWER":"OFF"}}
21:58:07.516 MQT: stat/esp32dev3/WEBSEND = {"WebSend":"Done"}
21:58:07.595 MQT: stat/esp32dev3/POWER = {"POWER":"ON"}
21:58:07.601 MQT: stat/esp32dev3/POWER = ON (retained)
21:58:07.640 RUL: POWER1#STATE performs "websend [192.168.168.195] power toggle"
21:58:07.753 MQT: stat/esp32dev3/WEBQUERY = {"WebQuery":{"POWER":"ON"}}
21:58:07.761 MQT: stat/esp32dev3/WEBSEND = {"WebSend":"Done"}
21:58:07.839 MQT: stat/esp32dev3/POWER = {"POWER":"OFF"}
21:58:07.842 MQT: stat/esp32dev3/POWER = OFF (retained)
21:58:07.875 RUL: POWER1#STATE performs "websend [192.168.168.195] power toggle"
21:58:08.014 MQT: stat/esp32dev3/WEBQUERY = {"WebQuery":{"POWER":"OFF"}}
21:58:08.023 MQT: stat/esp32dev3/WEBSEND = {"WebSend":"Done"}
21:58:08.107 MQT: stat/esp32dev3/POWER = {"POWER":"ON"}
21:58:08.112 MQT: stat/esp32dev3/POWER = ON (retained)
21:58:08.146 RUL: POWER1#STATE performs "websend [192.168.168.195] power toggle"
21:58:08.263 MQT: stat/esp32dev3/WEBQUERY = {"WebQuery":{"WebQuery":}
21:58:08.272 MQT: stat/esp32dev3/WEBSEND = {"WebSend":"Done"}So the round-trip-time is less than 300 ms for one tasmota to send the command and the other to sendback the command And roughly less htan 100ms between the "WebSend Done" and receiving the reply command which is rule execution + Websend execution.
I don't see any performance problem on Tasmota The results are consistent mnutes after minutes
So as sfromis pointed out, it's most likely due to some delay in the network or the other device
Now, we don't know what your Shelly is doing at the same time, so can't judge is tasmota could be busy doing something else. My devkit+nodemcu are only doing that
May be you can try same test between your Shelly and anohter Tamsota ?
barbudor
commented
1 year ago And for the completness of the test, let's do it replacing the WebSend by a publish cmnd/othertopic/power toggle
22:05:33.311 MQT: cmnd/nodemcu/power = toggle
22:05:33.487 MQT: stat/esp32dev3/POWER = {"POWER":"ON"}
22:05:33.490 MQT: stat/esp32dev3/POWER = ON (retained)
22:05:33.502 RUL: POWER1#STATE performs "publish cmnd/nodemcu/power toggle"
22:05:33.509 MQT: cmnd/nodemcu/power = toggle
22:05:33.687 MQT: stat/esp32dev3/POWER = {"POWER":"OFF"}
22:05:33.690 MQT: stat/esp32dev3/POWER = OFF (retained)
22:05:33.702 RUL: POWER1#STATE performs "publish cmnd/nodemcu/power toggle"
22:05:33.709 MQT: cmnd/nodemcu/power = toggle
22:05:33.788 MQT: stat/esp32dev3/POWER = {"POWER":"ON"}
22:05:33.795 MQT: stat/esp32dev3/POWER = ON (retained)
22:05:33.807 RUL: POWER1#STATE performs "publish cmnd/nodemcu/power toggle"
22:05:33.813 MQT: cmnd/nodemcu/power = toggle
22:05:33.987 MQT: stat/esp32dev3/POWER = {"POWER":"OFF"}
22:05:33.994 MQT: stat/esp32dev3/POWER = OFF (retained)
22:05:34.002 RUL: POWER1#STATE performs "publish cmnd/nodemcu/power toggle"
22:05:34.010 MQT: cmnd/nodemcu/power = toggle
22:05:34.083 MQT: stat/esp32dev3/POWER = {"POWER":"ON"}
22:05:34.091 MQT: stat/esp32dev3/POWER = ON (retained)
22:05:34.102 RUL: POWER1#STATE performs "publish cmnd/nodemcu/power toggle"
22:05:34.106 MQT: cmnd/nodemcu/power = toggle200ms round-trip-time So a ~30% performance improvement of MQTT over HTTP Which is not suprising based on the asynchonicity of MQTT vs HTTP
barbudor
commented
1 year ago 
digital-spinner
commented
1 year ago OK, thank you.
One thing I have tested additionally is another Shelly 2 with Tasmota 9.2.0 and it behave in the same way. There is also a random lag after button press. For comparison Blebox switches also are executing api endpoint in the same way but I did not noticed any random lag with those. Of course when I click like crazy 3 times fast then even those will loose one payload etc. but there was no random lag, it was actually expected after multiple presses (I guess it was doing also something) but not like in my Shellies now.
I think I will migrate to MQTT someday, for now I can live with that as it is.
If you can point me what network tests I can do than I will try to do it. My network has fiber WAN connection attached to OPNSense gateway, which serves through the switch 3 APs and some other cable clients. Never had an issue with that - it is rock solid and serves also as a VPN gateway (this is the main reason why it is at the first place). My work laptops have 200+Mbps over WiFi in every case and the workstation easily can utilize 930Mbps over cable. The DNS is dynamically managed but I set the manual assignations, so every device gets its own IP address. Ah, the subnet is 22 if this matter. The APs are just serving WiFi in FAST ROAM mode using OpenWRT firmware and doing nothing more. I have over 40 wifi IOT devices if I remember. I hope that I won't start glowing any soon.
barbudor
commented
1 year ago The best would be to be able to do tcpdump/wirechark captures (I believe I already said that above) But if the addressed device is an embedded device and not a server, I don't know how to achieve that In some case, it is possible to use some wifi card in PCs in "promiscuous mode" which is a kind of "spy" mode where the would capture everything that goes on the wifi network. But my understanding that this feature is not available with every wifi card
digital-spinner
commented
1 year ago OK, one observation extra to that.. When I press both buttons simultaneously, then the random delay applies for both, the physical one and the WebSend wired button also. There is definitely some issue here.
When I have both buttons wired physically (without any rules) then there is no delay.
PROBLEM DESCRIPTION
A clear and concise description of what the problem is.
I have
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Backlog Template; Module; GPIO 255:Status 0:TO REPRODUCE
Steps to reproduce the behavior:
// wipe current configuration but retain WiFi credentials
Reset 4// set theme color
WebColor {"WebColor":["#eaeaea","#252525","#4f4f4f","#000000","#dddddd","#65c115","#1f1f1f","#ff5661","#008000","#faffff","#1fa3ec","#0e70a4","#d43535","#931f1f","#47c266","#5aaf6f","#faffff","#999999","#eaeaea"]}// apply template and best settings
// apply rule to be used with pushbutton 2
Use the switch 2 to operate.. The action execution randomly delays. Sometimes is missing sometimes it executes even after couple of seconds.
EXPECTED BEHAVIOUR
A clear and concise description of what you expected to happen.
Web send should be executed with minimum possible delay, preferably instantaneously but it is not. Blebox device used before this one was behaving like expected.
SCREENSHOTS
If applicable, add screenshots to help explain your problem.
ADDITIONAL CONTEXT
Add any other context about the problem here.
I need to control another device which can accept HTTP GET requests. Since my Blebox device died I switched to Shelly 2.5 and Tasmota 12.3.1 for it (also tested with 9.2.0) but the described issue raised. I have also tested WebQuery command and it behaves in the same way.
(Please, remember to close the issue when the problem has been addressed)