Tasmota: USE_EXPRESSION breaks string variable support

[netpok]

Describe the bug
_A clear and concise description of what the bug is._
Firmware compiled with USE_EXPRESSION can't store string variables as it's defaults to 0.000.

_Also, make sure these boxes are checked [x] before submitting your issue - Thank you!_

• [x] _Searched the problem in issues and in the wiki_
• [x] _Hardware used_ : All affected
• [x] _Development/Compiler/Upload tools used_ : not relevant
• [x] _If a pre-compiled release or development binary was used, which one?_ : not relevant
• [x] _You have tried latest release or development binaries?_ : yes
• [x] _Provide the output of command_status 0 : not relevant

To Reproduce
Executing var1 TEST will result in value 0.000

Expected behavior
var1 value: TEST

Additional context
Currently can not think to a right solution so I'm leaving this here maybe someone has an idea.

Cause of problem is:

#ifdef USE_EXPRESSION
      dtostrfd(evaluateExpression(XdrvMailbox.data, XdrvMailbox.data_len), Settings.flag2.calc_resolution, vars[index -1]);
#else
      strlcpy(vars[index -1], ('"' == XdrvMailbox.data[0]) ? "" : XdrvMailbox.data, sizeof(vars[index -1]));
#endif      //USE_EXPRESSION

[localhost61]

Yes, the feature has its limits, it can operate on timestamps neither, it's one of the reason I couldn't use it to monitor Wifi down periods and made a PR for that.
Maybe the solution is to introduce STR variables (necessary of limited size) and add a method to allow concatenation of STR+VAR.

_Who was talking about opening a box of worms ? XD_

[netpok]

My current ideas to solve this is:

1. revert changes of var and mem commands and introduce 2 new commands:
   VarE variable with expression evaluation and
   MemE memory with expression evaluation
2. Introduce a character for the same:
   for example values starting with \ is handled as expressions, but then it needs it's own escape sequence (\\)

Note: for backward compatibility with release versions the expression ones should get the change.

I'm waiting for feedback and better ideas. For now I would go with the first, if it gets accepted, I will implement the change.

[laurentdong]

Actually I knew that the implementation of expression will block string assignment to variable but I'm really new on Tasmota ( and any home automation projects ) so I didn't realize some people really need the string support.
My plan is truly support string expression. But at this moment I would rather implement a quick fix for this problem, which is do string copy instead of expression evaluation when the followed parameter in VAR/MEM is a single string or variable.

[laurentdong]

@netpok About the idea of having new commands (VarE, MemE) to support expression, it is also on my plan, but my idea is having one command only which "LET". So the command would be:
Let Var1 =
This looks much beautiful, but still not good enough. We actually can have variable type and name, so it will be:
Int n = 1
String sRoom="Bed room" + n
Is this too much for this small guy?

[arendst]

That's way too much!

There is just 3 x 512 characters available for rules which is why naming has to be as short as possible.

I think it's time to recall the USE_EXPRESSIONS until a functional version is tested and available. Until then it will de undefined to free current users from non-functionality.

[laurentdong]

A quick solution is let the Var/Mem do expression evaluation only when it followed a "=". This can keep the backward compatibility.
So
Var1 Mem1
Will do the exactly same thing like before, assign string "Mem1" to var1. And
Var1 = Mem1
Will assign the double type value of mem1 to Var1

[Jason2866]

I agree with @arendst to disable the USE_EXPRESSIONS at the moment until a good soultion is found.
Having a broken string support in var&mem is really bad and backward compability is broken too.
Already issues from users who updated https://github.com/arendst/Sonoff-Tasmota/issues/5412#issuecomment-470556572

[localhost61]

Did you test if this workaround still work with URL commands which are already introduced with this equal sign?
http://192.168.1.102/cm?cmnd=var1=mem1

[laurentdong]

@localhost61 I think the correct format should be:
http://192.168.1.102/cm?cmnd=var1%3Dmem1

[ascillato2]

Closing this issue as the PR #5421 has been made to solve this and it is being reviewed.

Thanks everyone for working on this :+1: