nested SendTo commands

[chromo23]

For my dashboard easyfetch it would be great if following command would work:

When i send from my main unit (1) this comand:

Code: Select all

SendTo,8,'SendTo,9,'taskvalueset,5,1,[Plugin#GPIO#Pinstate#16]''

unit 9 should get the Pinstate of GPIO 16 from unit 8

But it doesn't. It seems that "[Plugin#GPIO#Pinstate#16]" gets already parsed on unit 1.

Is there a way to make this work?

[TD-er]

You should also use different types of quotes for the nesting.

Code: Select all

SendTo,8,`SendTo,9,"taskvalueset,5,1,[Plugin#GPIO#Pinstate#16]"`

However I don't think this will be possible as indeed things will be translated already.

You could do it in events, but then it defeats your purpose for the "it just works" approach of the dashboard.

I will think about this, but I'm a bit afraid this will stir up a lot of rules code.

Maybe we could consider "escaping" characters, like this:

Code: Select all

SendTo,8,`SendTo,9,"taskvalueset,5,1,\[Plugin#GPIO#Pinstate#16\]"`

or

Code: Select all

SendTo,8,`SendTo,9,"taskvalueset,5,1,_[Plugin#GPIO#Pinstate#16]_"`

This way we could mark arguments to only be parsed when actually being processed as separate argument.
Still it is a bit tricky as it has a huge potential for breaking stuff...

[chromo23]

You could do it in events, but then it defeats your purpose for the "it just works" approach of the dashboard.

Exactly.

I will think about this, but I'm a bit afraid this will stir up a lot of rules code.

That´s what i thought...

Maybe we could consider "escaping" characters, like this:

Sounds good. If there is a way to solve this i would be grateful.

[chromo23]

Wouldn´t it be even better to wrap the whole command in brackets like e.g. "{ }" to tell the parser to ignore the whole stuff inside and just send it:

Code: Select all

SendTo,8,{SendTo,9,"taskvalueset,5,1,[Plugin#GPIO#Pinstate#16]"}

[TD-er]

That's also an option indeed.
Have to think about it as I also was thinking about adding scopes to the rules.
And those were the braces I was thinking about using.
But since those are not yet used, they are probably the least invasive to implement in the parsing code.

With scopes I mean storing variables which will not be global and some other ideas...

It just feels like it might be possible to combine both concepts without being too ambiguous in the meaning of those { }
But like I said, have to let it sink in a bit more.

[Ath]

And those were the braces I was thinking about using.
But since those are not yet used, they are probably the least invasive to implement in the parsing code.

With scopes I mean storing variables which will not be global and some other ideas...

It just feels like it might be possible to combine both concepts without being too ambiguous in the meaning of those { }
But like I said, have to let it sink in a bit more.

Hmm, String functions are already wrapped by curly braces...

[TD-er]

Ah yep, those formatting functions...

[chromo23]

Hmm, String functions are already wrapped by curly braces...

It's getting tight with available characters...

[TD-er]

Or we could look into which commands really need this.
So far I can only come up with the sendTo.

[chromo23]

So far I can only come up with the sendTo.

Yes, i think this is the only command where this is needed...

[TD-er]

So all we need is something to mark a parameter or character to be verbatim and only strip away the verbatim wrapper when processing.

I still think the "\[" and "\]" are the simplest here.
This would then also apply to "\%" and "\{...\}"

[Ath]

So far I can only come up with the sendTo.

Yes, i think this is the only command where this is needed...

In some cases where I need a bit more stable/confirmed command to be sent, I've used SendToHTTP instead of SendTo, but that may be an edge-case.

[chromo23]

I still think the "\[" and "\]" are the simplest here.

There is one issue.
"\" seems to be translated to "^" by ESPEasy:

Code: Select all

SendTo,8,`SendTo,9,"taskvalueset,5,1,\[Plugin#GPIO#Pinstate#16\]"`

Code: Select all

237714401: HTTP: SendTo,8,`SendTo,9,'taskvalueset,5,1,^[Plugin#GPIO#Pinstate#16^]'`

[TD-er]

Nope, just in the logs as you can't use it in JSON.
And it isn't implemented yet, so it was just a suggestion of what we could use before implementing it in the parser and potentially break everything rules/parser related

[chromo23]

And it isn't implemented yet,

I know.. i just wanted to test what happens with this character along the way (was a bit unnecessary to write about it i guess )

potentially break everything rules/parser related

Where would be all the fun if not...

[chromo23]

Btw:

While testing things with my code changes in easyfetch i was looking for unused characters for device and value names.
I found out, that using "<" and ">" gives no error message but since they are used for "less" and "greater" they should, right?

[Ath]

IMHO, adding support for backslash "\" as the escape character, is nicely in line with the C++, Python and Javascript programming languages used in the project, so should cause minimal confusion.

[TD-er]

Compare characters are only processed when it is expecting something to compute.
Thus with the let command and there is also a number of other cases where an = (or != or =! ???) is used.
Maybe (just a silly idea popping up) we should document these?

[chromo23]

Thus with the let command and there is also a number of other cases where an = (or != or =! ???) is used.
Maybe (just a silly idea popping up) we should document these?

I am not quite following but documentation is always a good idea...

[chromo23]

So this is no issue when used as a value name?:

Code: Select all

Dummy&8>16

[TD-er]

Well if you really need to...
Just don't use a dot (.) or a # in task names or value names and I guess when you start with a letter it will be fine.

[chromo23]

Well if you really need to...

Not really... i also thought about using "G" instead (for gpio)
But with ">" its a little bit less code...

...
...
...I think i´ll go with "G"