Telegram & MSR 1.0.0
-
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. -
@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.
@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.
-
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.@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:
-
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.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
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.
@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.
-
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.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
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.
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.
-
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.
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.
-
No, that's out of scope.
-
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".
-
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.
-
T toggledbits locked this topic on
