Closed nikvostro closed 3 years ago
It looks like it is running out of stack space when telegram is executed from script.
I see no easy solution.
It looks like it is running out of stack space when telegram is executed from script.
I see no easy solution.
Hello Theo! Glad to see you there here in my bug :) OK, more complex solutions are also welcome! Do you have any ideas?
p.s. I'm making not smart but a bit clever home without any automation servers - decentralized ecosystem. It's quite important to have most of Tasmota features available for every device making them independant of each other. Indeed I understand the physical MCU limitations but nevertheless I beleive in magic of coding :)
p.s.p.s. Thanks a lot for growing such a good project!!! Very appreciate on your efforts! Hope I can bring some value by reporting bugs....
Tasmota is specifically designed for operation via MQTT, and not for devices being maximally independent. It is outside the concept to insist on multiple "big" features existing on the same ESP8266. Using ESP32 may provide more headroom, as you've observed.
Tasmota is specifically designed for operation via MQTT, and not for devices being maximally independent. It is outside the concept to insist on multiple "big" features existing on the same ESP8266. Using ESP32 may provide more headroom, as you've observed.
Indeed I do understand the concept. For my case I'm don't want to have additional MQTT server/broker as my automation needs are potentially covered by exciting rules/scripting features. Sure MQTT setup is much more easy to control in one place and it's endless flexible. But it's rather redundant for me neither bringing value. Telegram integration is really useful thing to bring control to end-user without any additional manipulations with LAN/WAN port forwarding, using VPN etc. I'm trying to use factory modules (devices) maximally. Sure ESP32 would be much more appropriate but esp8266 (and wb3s) are not pin compatible with esp32. It would be great to use more powerful esp32 MCU but this is not a case unfortunately because I'm using ZbBridge... for other wb3s devices it was not a problem for me to swap MCUs.
Using the new ESP32-C3 chip, you can actually get a module which is largely pin compatible with WB3S. See this video.
Do note that the Tasmota support for ESP32-C3 is in a very early stage (but largely compatible with the "classic" ESP32), meaning that while the basics seem to work, the risk of running into issues is very much there.
Using the new ESP32-C3 chip, you can actually get a module which is largely pin compatible with WB3S. See this video.
Do note that the Tasmota support for ESP32-C3 is in a very early stage (but largely compatible with the "classic" ESP32), meaning that while the basics seem to work, the risk of running into issues is very much there.
Will try C3 later on on closer to stable stage... resoldering...
Another one example of unstable work of subroutines. ESP8266. Command IRHVAC executes correctly but RSL is returned corrupted each time.
#ACSET(par)
modenum=par%10
fan=((par%100)-modenum)/10
temp=(par-(fan*10)-modenum)/100
switch modenum
case 0
mode="Cool"
case 1
mode="Heat"
case 2
mode="Fan"
ends
print %temp% %fan% %modenum% %mode%
->IRHVAC {"Vendor":"FUJITSU_AC","Model":1,"Mode":"%mode%","Power":"On","Temp":%temp%,"FanSpeed":"%fan%"}
#ACOFF
print acoff
temp=0
->IRHVAC {"Vendor":"FUJITSU_AC","Model":1,"Power":"Off"}
subroutines work:
10:14:54.977 CMD: acset 2533
10:14:54.983 25.00 3.00 3.00
10:14:54.138 RSL: RESULT = {"ACSET":"{"V��?@��?FUJITSU_AC"}
10:15:01.115 CMD: acoff
10:15:01.118 acoff
10:15:01.202 RSL: RESULT = {"ACOFF":"��?1��?���?��%@"}
10:15:14.503 CMD: acset 2400
10:15:14.509 24.00 0.00 0.00 Cool
10:15:14.663 RSL: RESULT = {"ACSET":"{"V��?@��?FUJITSU_AC"}
10:20:05.555 CMD: acoff
10:20:05.559 acoff
10:20:05.642 RSL: RESULT = {"ACOFF":"��?1��?���?��%@"}
Just scanned my tasmota source code but I'm sorry to say I see nowhere that a command like acset
is present.
Do I miss something?
Just scanned my tasmota source code but I'm sorry to say I see nowhere that a command like
acset
is present.Do I miss something?
It's all about subroutines. See 1 comment above please - #ACOFF
sub
Ah it's scripting. I guess you'll have to escape the quotes in your command line but as I'm not a script expert @gemu2015 may know better.
Ah it's scripting. I guess you'll have to escape the quotes in your command line but as I'm not a script expert @gemu2015 may know better.
I guess I can't avoid quotas for IRHVAC JSON, but let's try anyway:
#ACOFF
print acoff
temp=0
->IRHVAC {Vendor:FUJITSU_AC,Model:1,Power:Off}
11:24:28.603 script compressed to 751 bytes = 60 %
11:24:28.606 Script: nv=11, tv=2, vns=106, ram=289
11:24:44.191 CMD: acoff
11:24:44.195 acoff
11:24:44.200 RSL: RESULT = {"ACOFF":""}
11:24:54.240 CMD: acset 2533
11:24:54.245 25.00 3.00 3.00
11:24:54.399 RSL: RESULT = {"ACSET":"{"V��?@��?FUJITSU_AC"}
11:24:58.445 CMD: acoff
11:24:58.448 acoff
11:24:58.454 RSL: RESULT = {"ACOFF":""}
Removed quotas for acset
sub:
#ACSET(par)
modenum=par%10
fan=((par%100)-modenum)/10
temp=(par-(fan*10)-modenum)/100
switch modenum
case 0
mode="Cool"
case 1
mode="Heat"
case 2
mode="Fan"
ends
print %temp% %fan% %modenum% %mode%
+>IRHVAC {Vendor:FUJITSU_AC,Model:1,Mode:%mode%,Power:On,Temp:%temp%,FanSpeed:%fan%}
11:32:01.772 script compressed to 735 bytes = 60 %
11:32:01.775 Script: nv=11, tv=2, vns=106, ram=289
11:32:04.951 CMD: acset 2533
11:32:04.957 25.00 3.00 3.00
11:32:04.962 RSL: RESULT = {"IRHVAC":"Invalid JSON"}
11:32:04.965 RSL: RESULT = {"ACSET":"{Vendor:FUJd�%@0��?!��?���?��%@ "}
try this:
+>IRHVAC {Vendor:"FUJITSU_AC",Model:1,Mode:"%mode%",Power:On,Temp:%0temp%,FanSpeed:%0fan%}
by the way. i also replaced my iobroker raspberry setup with tasmota scripting.
i am using esp8266 devices for all sensors and actors. most of these devices have dedicated web pages with google graphs for local sensors. additionally all variables are made public by global variables.
then i have several esp32 devices with displays that collect all these data, show them on webui with extended graphs, store them on SD card and every week send the collected data as email attachments.
print +>IRHVAC {Vendor:"FUJITSU_AC",Model:1,Mode:"%mode%",Power:On,Temp:%0temp%,FanSpeed:%0fan%}
+>IRHVAC {Vendor:"FUJITSU_AC",Model:1,Mode:"%mode%",Power:On,Temp:%0temp%,FanSpeed:%0fan%}
12:13:35.769 Script: nv=11, tv=2, vns=106, ram=289
12:13:38.443 24.00 0.00 0.00 Cool
12:13:38.445 +>IRHVAC {Vendor:"FUJITSU_AC",Model:1,Mode:"Cool",Power:On,Temp:24,FanSpeed:0}
12:13:38.450 RSL: RESULT = {"IRHVAC":"Invalid JSON"}
12:13:38.453 RSL: RESULT = {"ACSET":"{Vendor:"FUd�%@0��?!��?���?��%@ "}
Good approach with using esp32 as a core device! And global variables are in my plan for imlementation :) In my case I've decided (not to dive into Android programming) to utilize Tasker. I'm don't need to collect and analyze any data (as for now:)). Here are my 2 screens for controlling Light and ACs:
sorry other quotes missing:
+>IRHVAC {"Vendor":"FUJITSU_AC","Model":1,"Mode":"%mode%","Power":"On","Temp":%1temp%,"FanSpeed":%0fan%}
example from docs IRhvac {"Vendor":"Mitsubishi_Heavy_152", "Power":"On","Mode":"Hot","FanSpeed":3,"Temp":22.5}
I guess %1 forces 1/10 decimal precision level in parameter definition... So the result is still same:
12:52:01.218 24.00 0.00 0.00 Cool
12:52:01.219 +>IRHVAC {"Vendor":"FUJITSU_AC","Model":1,"Mode":"Cool","Power":"On","Temp":24.0,"FanSpeed":0}
12:52:01.372 RSL: RESULT = {"IRHVAC":{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Cool","Power":"On","Celsius":"On","Temp":24,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}
12:52:01.375 RSL: RESULT = {"ACSET":"{"V��?@��?FUJITSU_AC"}
yes is decimal precision
no, now you don't get invalid json. so it should send correctly. the command ACSET however returns an invalid result. i dont use irhvac, so i cant test directly. why do you use +> and not -> ? this may cause weird effects by unwanted recursions.
This worked initially actually - command was executed properly, but idea was to fix RSL JSON. My app is getting a bit confused by getting this response for HTTP request. Sure it doesn't make big sense here but it can be quite critical in other appliances.
Command IRHVAC executes correctly but RSL is returned corrupted each time.
I faced with incorrect behaviour somewhere by using => (or ->) and replacing it with +> has solved the problem. To be honest I do understand recursion in programming but I don't understand what does mean "+> Execute recursion enabled" in Scripting. Nothing explained in Docs :(
=> execute tasmota cmd with MQTT output enabled -> execute tasmota cmd with MQTT output disabled +> execute tasmota cmd with MQTT output enabled and recursion enabled.
exampe, if you execute a tasmota cmd in an >E section and this cmd itself executes >E you will get an infinite loop. this is disabled normally and enabled by the +> in case you know what you are doing
feel free to edit the tasmota documents to clarify things!
Good news.
Starting with ArduinoEsp8266 core 3.x more user RAM is available. This allows more heap space too which solves the OP's issue with executing telegram from a script.
To test use the latest development environment and enable Core 3.0.2
PROBLEM DESCRIPTION
The following command crashes esp8266 being executed in >E section or in subroutine (or manually in Console with "script >"):
=>tmsend somesampletext
But this problem doesn't occur on ESP32 devices - tested on ESP32CAM and Lillygo TTGO T-Display.tmsend [text]
command works fine in console and in other places (sections) of Script:REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
[x] Read the Contributing Guide and Policy and the Code of Conduct
[x] Searched the problem in issues
[x] Searched the problem in discussions
[x] Searched the problem in the docs
[x] Searched the problem in the chat
[x] Device used (e.g., Sonoff Basic): Sonoff ZbBridge and also crashes on clean ESP-12E. Works on ESP32CAM and Lillygo TTGO T-Display
[x] Tasmota binary firmware version number used:
[x] Flashing tools used: VSC/PlatformIO
[x] Provide the output of command:
Backlog Template; Module; GPIO 255
:[x] Sample Script used:
ALERT(msg)
print message=%msg% =>tmsend tstmsg
weblog
to 4 and then, when you experience your issue, provide the output of the Console log:--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Soft WDT reset
ctx: cont sp: 3ffff600 end: 5c5c5c5c offset: 01a0 3ffff7a0: 00000078 00000000 00000001 4024e9aa 3ffff7b0: 00000000 00000000 3fff581c 4024e9aa 3ffff7c0: 00000008 00067a6a 3fff5544 4024375e 3ffff7d0: 00000078 00000005 13cb2fa7 00000000 3ffff7e0: 402645f0 4026459c 3fff581c 4026417a 3ffff7f0: 3fff5d1c 3fff713c 3fff581c 3fff5544 3ffff800: 3fff713c 00000001 3fff5544 4024387c 3ffff810: 3fff713c 3fff905c 00000000 402439ba ..................................
ALERT(msg)
print message=%msg% =>tmsend tstmsg
3.2 power1 1 3.3 script>=>tmsend test
EXPECTED BEHAVIOUR
Text message should be sent
SCREENSHOTS
N/A
ADDITIONAL CONTEXT
N/A
(Please, remember to close the issue when the problem has been addressed)