Core: capital command names parsing

[enesbcs]

No description provided.

[enesbcs]

Fixed in eae4618

[clumsy-stefan]

Wow, that was a really quick fix!!!

Seems to work:

22:30:08: CMD: pwm,18,52
22:30:08: BCM18 PWM 52% 1000Hz
22:30:08: Event: pwm#speed=52
22:30:08: CMD: sendToHTTP,10.0.0.1,8072,/fhem?cmd=setreading%20rpieasy_02_ch05%20speed%2052
22:30:08: CMD: Event,pwm#speed=52
22:30:08: Event: pwm#speed=52
22:30:08: CMD: sendToHTTP,10.0.0.1,8072,/fhem?cmd=setreading%20rpieasy_02_ch05%20speed%2052
22:30:08: CMD: TaskRun,21

Capital Event does'nt loose teh first character anymore! Thanks!

[clumsy-stefan]

EDIT: sorry, found the issue, again problems with comments. I had the commented out
// Event,pwm#speed=%eventvalue%
in that rule which throwd an error, no matter if there is a space before // or not

Rule:

on ch5d do
  if %eventvalue% < 1
    pcfgpio,5,1
    pwm,18,0
  else
    pcfgpio,5,0
    if %eventvalue% > 100
      pwm,18,100
    else
      pwm,18,%eventvalue%
      // Event,pwm#speed=%eventvalue%
    endif
  endif
  TaskRun,21
endon

~~
sendtohttp also throws an error sometimes, even though the command seems to get executed correctly:

23:03:01 CMD: event,ch5d=73
23:03:01 Event: ch5d=73
23:03:01 Parsed condition: if 73 < 1 False
23:03:01 CMD: pcfgpio,5,0
23:03:01 PCFGPIO5 set to 0
23:03:01 Parsed condition: if 73 > 100 False
23:03:01 CMD: pwm,18,73
23:03:01 BCM18 PWM 73% 1000Hz
23:03:01 Event: pwm#speed=73
23:03:01 CMD: sendToHTTP,10.0.0.1,8072,/fhem?cmd=setreading%20rpieasy_02_ch05%20speed%2073
23:03:01 Curl: http://10.0.0.1:8072/fhem?cmd=setreading%20rpieasy_02_ch05%20speed%2073
23:03:01 CMD:
23:03:01 Unknown command:
23:03:01 CMD: TaskRun,21
23:03:01 Event: ch5#switch=0
23:03:01 Sending task 21 data to FHEM at http://10.0.0.1:8383/ESPEasy
23:03:02 timed out

Same rule as above. Could it be, that it returns a non-zero value if curl had to try more than once to connect and send the data? As there are time-outs on the data sending. Sometimes my server seems to be too slow in answering (have the same issue in ESPEasy, which also tries a number of times to get rid of its payload).
~~

[enesbcs]

// Event,pwm#speed=%eventvalue%
in that rule which throwd an error, no matter if there is a space before // or not

This may be the response by your comment:

23:03:01 CMD:
23:03:01 Unknown command:

as everything behind // is deleted, resulted as an empty line, which is really an unknown command. :)

~~
sendtohttp also throws an error sometimes, even though the command seems to get executed correctly:

23:03:01 CMD: event,ch5d=73
23:03:01 Event: ch5d=73
23:03:01 Parsed condition: if 73 < 1 False
23:03:01 CMD: pcfgpio,5,0
23:03:01 PCFGPIO5 set to 0
23:03:01 Parsed condition: if 73 > 100 False
23:03:01 CMD: pwm,18,73
23:03:01 BCM18 PWM 73% 1000Hz
23:03:01 Event: pwm#speed=73
23:03:01 CMD: sendToHTTP,10.0.0.1,8072,/fhem?cmd=setreading%20rpieasy_02_ch05%20speed%2073
23:03:01 Curl: http://10.0.0.1:8072/fhem?cmd=setreading%20rpieasy_02_ch05%20speed%2073
23:03:01 CMD:
23:03:01 Unknown command:
23:03:01 CMD: TaskRun,21
23:03:01 Event: ch5#switch=0
23:03:01 Sending task 21 data to FHEM at http://10.0.0.1:8383/ESPEasy
23:03:02 timed out

Same rule as above. Could it be, that it returns a non-zero value if curl had to try more than once to connect and send the data? As there are time-outs on the data sending. Sometimes my server seems to be too slow in answering (have the same issue in ESPEasy, which also tries a number of times to get rid of its payload).
~~

Yes sendtohttp has 1 second timeout. It can be raised if needed.
But it never returns any value, as it is running in background as a non-blocking thread. So it returns immediately, and rule execution continues, before knowing if it was succesful. An async "timed out" message arrives to the log later, when time out reached on that thread.

[clumsy-stefan]

as everything behind // is deleted, resulted as an empty line, which is really an unknown command. :)

;) Ok, understood... At some time it would probably be nice to have empty lines in rules, just for reasy eading purposes...

[TD-er]

Not knowing how the rules are being parsed in R'piEasy, but maybe it is helpful knowing how it is being parsed in current ESPEasy builds.

• // is considered start of a comment, thus everything until a newline is skipped. Maybe it is better to change this to // (slash, slash, space) as you mentioned it may be part of an URL.
• From the start of a new line, all spaces and tabs before another (non newline) character is found are skipped.
• See the GetArgvBeginEnd code as it may have been changed since your reference buils. (see also: Updated Rules parameter parsing (2019/11) letscontrolit/ESPEasy#2724 )

[enesbcs]

;) Ok, understood... At some time it would probably be nice to have empty lines in rules, just for reasy eading purposes...

empty lines now silently skipped from commit 634394e

[enesbcs]

Thanks!

* `//` is considered start of a comment, thus everything until a newline is skipped. Maybe it is better to change this to `// ` (slash, slash, space) as you mentioned it may be part of an URL.

'// ' now also replaced as ' //' until newline with empty string.

* From the start of a new line, all spaces and tabs before another (non newline) character is found are skipped.

Yep, strings are trimmed also.

[TD-er]

'// ' now also replaced as ' //' until newline with empty string.

What happens if a line starts with a comment?

[enesbcs]

'// ' now also replaced as ' //' until newline with empty string.

What happens if a line starts with a comment?

Than the line is a comment. I understand that some kind of foolprof approach is necessery, but i hope that users will find out, if they comments without spaces raises errors.
Currently '// ' and ' //' is filtered, '//anything' is not.

[enesbcs]

Capital command names parsing fixed, issue closed