Telegram & MSR 1.0.0

[tunnus]

With RfV I used to have this kind of Telegram notification:

{"Temperature " .. OutTemp .. " °C"}

And it worked fine. Now with MSR similarly:

${{ "Temperature " + OutTemp + " °C" }}

...and the message does not come through

Logs:

2021-08-09T14:54:02.213Z <Engine:ERR> NotifyTelegram failure response text: {"ok":false,"error_code":400,"description":"Bad Request: can't parse entities: Character '.' is reserved and must be escaped with the preceding '\\'"}

This is because temp value (here 20.2) contains decimals and therefore ".". Can't really escape that as it is within the variable. Workaround would be to round the value before sending, but even better if this could be fixed?

Using Markdown or MarkdownV2 does not make a difference.

[toggledbits]

Seems like something else. A simple test sending a fixed string with a "." in it does not throw an error. Can you screenshot and paste the entire action as you've defined it?

[MikeReadington]

This post is deleted!

[MikeReadington]

@tunnus was looking on my phone and missed you already thought about round.

[toggledbits]

Ah, I see. Well, if you're using Markdown form for Telegram, you have to provide a properly formatted Markdown string, which would include escaping any such characters. No different than using HTML format; if you provide invalid HTML, I would not expect it to work, nor would I expect the notifier to detect and correct it.

    ${{ replace( "Temperature " + OutTemp + " °C", ".", "\\." ) }}

[tunnus]

@toggledbits Didn't matter before your advice, so I didn't include the whole string earlier:

${{ replace( "ℹ️heater activated \\(" + HeaterWatts + " W\\), 🌡️ out: " + OutTemp + " °C", ".", "\\." ) }}

End result is the same, works if temp value is without decimals (e.g. 20), but if it has decimals (e.g. 20.5) then not. Also above substitution has a side effect that it changes "info" emoji to just "."

For some reason with RfV, the same worked without escaping anything (brackets or dots inside values)?

[toggledbits]

Shoot. Forgot that "." is also a special character for replace(). Here's a more complete solution all around:

${{ replace( "I have all [the] {special} _characters_! This. That~ and the {other} # + =", "([._\\*\[\]\\{\\}~`>#+=|\\{\\}!-])", "\\$1", "g" ) }}

Edit: The forum is not being consistent in its display of the escapes. It's right in the editor and preview but incorrect when submitted/displayed in the thread. Here's a graphic of what it should look like:

Note that every backslash in the string must be doubled.

Edit 2: Here's a version that displays correctly here in any case:

${{ replace( inputString, "([!#*+\x2d.=>\x5b\x5c\x5d_`\x7b|\x7d~])", "\\$1", "g" ) }}

[toggledbits]

@tunnus said in Telegram & MSR 1.0.0:

For some reason with RfV, the same worked without escaping anything (brackets or dots inside values)?

R4V does not interface with Telegram's API directly, the Telegram plugin must be installed, and it handles their API.

Maybe it's just using plain text? Why are you using Markdown format, anyway? There's no markdown formatting in your text, and your string works fine (with icons/emojis) in plain text formatting mode.

[tunnus]

@toggledbits Valid question, I guess because @therealdb recommended Markdown-formatting originally and those early plugin builds defaulted to Markdown and it worked

I'll try plain text and see what happens.

EDIT: plain text seems to work nicely! A minor wish though, if default parsing would happen to be something else than plain text, could you add option in the GUI for it (message format drop-down)? Also MarkdownV2 is missing from that list.

[toggledbits]

If the old Telegram plugin on Vera is escaping those special characters, I wonder how it distinguishes between the use of a special character as part of the text and the use of special character for Markdown. For example, if you want your displayed message to contain the word "emphasis" in italics (e.g. emphasis), you would format that as _emphasis_ in Markdown. But if the plugin is escaping the special characters, you will instead see "_emphasis_" (underscores visible, no italics) because the underscores are being escaped by the plugin and won't be treated as formatting. That would be less flexible/useful, and in fact, it would almost make Markdown and plain text equivalent in that plugin, because it would prevent you from using any Markdown formatting that involves one of those special characters. I don't know, I don't use it on Vera. As I said, if you want to use Telegram with MSR, you have to format the message correctly for the parser (formatter) being used.

Markdown V2 is the only format of Markdown MSR supports, so "Markdown" means "MarkdownV2". The default parsing format is set by the config default_parse_mode. In a default configuration, that value will be blank, so the default will be plain text.

[therealdb]

@tunnus I honestly don’t remember when/why I’ve said that, but I’ve looked at the code and it’s simply url encoding, not replacing or escaping the text. I’ve defaulted to markdown because it’s easier to format, but you could switch to plaintext or markdownv2 very easily. There’s a note in the readme recommending the escape before sending the message, but I don’t remember when I’ve added it.

[tunnus]

@toggledbits btw, how can you reference a local variable in e.g. telegram notification?

${{ "power " + LightWatts + " W" }}

LightWatts belongs to a rule called "Testbed variables" as shown above.

Lastly, a feature request: as for variables shown in the screenshot above and as implemented in RfV, it would be more clear if also rule state conditions would include the rule set name. Maybe images below help understanding what I'm after:

MSR now:

RfV:

[toggledbits]

You can't reference a variable that belongs to another rule in an expression. That's what global variables are for. They are accessible to all rule/expressions.

This raises an interesting incongruity. As currently implemented, the Variable Value condition will allow you to reference a variable in another rule. This should have never been. It breaks the encapsulation/scope of rules. It can lead to problems because there is no guaranteed order of rule evaluation when multiple rules are triggered at the same instant, so it could lead to a situation where a variable is used in Rule B before a new value is computed by Rule A. I think, the ability to select variables that are not local to the current rule or global is on the chopping block today.

[cw-kid]

@toggledbits said in Telegram & MSR 1.0.0:

Variable Value condition will allow you to reference a variable in another rule. This should have never been.

I think, the ability to select variables that are not local to the current rule or global is on the chopping block today

I have some rules that look at the value of a variable from another rule. The variable is not a global one currently.

So this change will likely be a breaking change? And I will need to redo some of my rules and use Global Variables instead.

[toggledbits]

Yes, it would be a breaking change. I can allow any rules currently using that approach work during a deprecation period, but not allow new conditions to be created with that approach. So your rules would not screech to a halt on the upgrade, you'd have some time to find and fix them.

[cw-kid]

@toggledbits

OK thanks for the heads up. Some of those PS4 rules I setup recently will need changing then and maybe some others. I will have to have a look at them again.

[cw-kid]

@toggledbits

Can a Global Expression read a local variable in a ruleset ?

I think the answer to this is no, I've just tried it and got an error.

[toggledbits]

No, that's out of scope.

[toggledbits]

Don't go too far with it just yet. I'm just considering the change. I need time to consider its full impact. The status quo can also be justified, and not be sacrificed on the altar of "purity".

[cw-kid]

I only had two rules that would of been affected by this change. I have moved all those PS4 related expressions out to be global expressions now instead and the one other rule that was using one of those expressions as its trigger, I've edited to use the new global expression instead. None of my other rules I don't think were using a local expression from another rule.