New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rule Parsing White Space Issue. {Rule Example in Wiki no longer works} #2987
Comments
That's a good one. |
personally it should be more clear with space, but if "compatibility" mode is used in advenced options it can be tolerated, all possible examples should be with whitespace added or maybe easier is to add syntax parser in JS and warn user about possible problems |
The wiki rule example has been around a long time. So I suspect there will be some existing users that will suffer abnormal rule behavior and/or reboot loops after they flash to the current release. To ensure that ESPEasy is "easy" to use, I highly recommend that the missing white space is tolerated without further attention by the user. EDIT: The rules example (jpg image) in the wiki has been updated. I exaggerated the whitespace between the "if" and "[" open bracket. Ref: Rules1.jpg
|
Well @uzi18 's suggestion is to only allow it with the "Tolerant last parameter" checked. |
@TD-er this should be easy to find when rules file is loaded into webbrowser - regex like "newline/whitespace+if[" and when it is there warn user about it. |
in fact we can think about it when new issues like this arrive, for now it is not a big problem |
So far I've helped out a couple forum users that have experienced this issue when using the latest releases. For example:
For the record, they weren't. So that's why I updated the wiki today. I hate to sound like a brat, but I don't understand the reluctance to allow backwards compatibility and ignore the missing white pace. There's no need to warn about it, just allow it. ESPEasy should be easy. Making a change to functionality that breaks existing rules seems like an invitation to user frustration. I'm just here trying to make a point that the user experience is important.
|
Well you don't sound like a brat :) One reason (for me) to be a bit reluctant about backwards compatibility is that it may make the code more elaborate than strictly needed.
So by using a "backwards compatibility" or "tolerant" mode, you may make it clear some of the currently used code is "deprecated" or at least not as it was intended to be used. What we can do, to make it "easy" again, is to parse for a few common "mistakes" and warn the user about it. |
In regards to the warning idea, I can imagine how that could work when the user is saving edits to a Rules page. But it's not clear to me how this helps when the user has re-flashed to a newer version and the white space is missing in their existing if statements. This scenario might suck the "easy" out of ESPEasy (rules stop working and/or possible reboot loop). Enough of my rants, I don't want to wear out my welcome. So I'll leave the fix implementation up to you.
|
That's a valid point. Right now we have a check on reboots by disabling plugins and then controllers if they might be the cause of reboots. So I will also append the check for "enable tolerant mode" and next step to disable rules. I'm all in favor of making it as easy as possible, but on the other hand remaining compatible with the past may later become a burden. My main problem is that I often don't see the problems myself so you have to keep pushing me to see it :) |
So somewhere we have to find a good compromise and I hope you keep pushing and stirring where the UX is less than optimal so we can all make ESPEasy easy to use. Thanks for the friendly invitation. I prefer to be helpful and hopefully my occasional pushing is taken as a gentle nudge.
|
Looked into the code and it does seem like a very simple fix. The problem was that it looked for |
elseif should be also modified respectively |
Just added it. |
The only "if" case that would deserve this special treatment would be if[ (if appended with open bracket). So both "if " and "if[" (and elseif) would be valid.
|
It could also be used with system variables, which have been replaced by the time it is parsed. On the other hand, if we were to add a space in front of replaced system variables or |
Did anyone test the rules using this patch? |
I'll try it on a NodeMCU if you post the [Testing] bin.
|
don't see any impact on code but it is less readable and we should avoid such syntax |
I agree on the syntax stuff, and we should later add warnings, etc. |
I installed ESP_Easy_mega-20200410-94-PR_3005_test_ESP8266_4M1M_VCC.bin on a NodeMCU. But bad news, it breaks the rule handler. Some events don't run. I deleted all "If" statements and the affected events still don't fire. I reverted back to ESP_Easy_mega-20200310_test_ESP8266_4M1M_VCC.bin and everything is working again. It's unexpected that the "if" patch caused this. Maybe there were other changes in this build?
|
Do you have some examples of events that no longer were running? |
is it possible for you to attach rules and comments precisely what works and what not? |
Rule file code posted below. The Notification rule (timer4) and NEXTION#idx=98 do not fire. But I can I see Nextion's idx=98.00 in the web log, so this event should occur.
|
I should mention that these rules have been in use for a couple years on a variety of ESPEasy releases. A few weeks ago I added the single quotes around the Nextion printing statements (as required by the recent releases). But other than that the rules have been working trouble free.
|
Just to be sure, the last nightly build does work fine on these rules? |
Affirmative. Rules are working on ESP_Easy_mega-20200410_test_ESP8266_4M1M_VCC.bin
|
Could you please also check if Rules Set 2-4 are accessible in that build? I have an issue in Custom build described here: #2980 |
Check! @ghtester It should be fixed as I did fix that +other related issues with toggling some combobox items that would trigger a reload, like switching DNS/IP in controllers, selecting a (new) plugin and some more. |
@thomastech Can you at least also test with the current state of the mega branch? |
The seven day old ESP_Easy_mega-20200410_test_ESP8266_4M1M_VCC.bin is the latest nightly build I can find. As reported, this bin is working. Do you have a more current [Testing] build for me to try?
|
@thomastech Made a test build of the current HEAD of the mega branch. |
Thanks for the test build. Good news, it works. I checked rules on these two bins:
|
OK, so it is only the PR I made. So I was thinking about using exactly that on the processing of a single line in the rules parsing. |
OK, couldn't resist.... at least it is already "tomorrow" ;) Started a test build for it, which I will link after sleeping, which I will do now. |
Test build: ESPEasy_mega-20200410-101-PR_3005.zip |
Thanks, new bin tested.
The warning message is a bit cryptic. If I was a casual observer I don't believe I would have understood the significance of it. That is to say, would a typical user think it was a basic log status message, warning, or error? To reduce confusion, if a syntax issue has been automatically corrected then the log message could say something like this:
|
Thanks for testing and good to hear it is working. So it should be an "error" type, as strictly speaking it is not according to our grammar rules. |
None that I can think of at the moment. Thanks for asking.
|
[rules] Allow "if [" and "if[" in rules (#2987)
Background info:
Recently the ESPEasy Rule parameter parsing was refactored. The new requirements were nicely summarized by TD-er in this post:
#2724
The Problem:
But the new parsing has also affected the syntax of conditional statements. Older releases were more tolerant to the whitespace usage in a "if" statetment. For example, the Wiki rule example published here no longer works:
https://www.letscontrolit.com/wiki/index.php/Tutorial_Rules
Original example code:
This example worked on older versions. But with the new rule parsing this rule will cause abnormal operation, including reboot loops.
The problem is due to this statement:
if[E1SW1#Switch]=1
The new rule parsing requires a space between the if and the [ open bracket. Like this:
if [E1SW1#Switch]=1
Proposed solution:
Revise parsing so that the "if" does not require any whitespace before the "[" open bracket. That is to say, make it backwards compatible.
The text was updated successfully, but these errors were encountered: