Blockly String \-Backslash weirdness

Hey guys,
I am using the Blockly-coding for my dad to make it easier for him to setup some rules.
Now here is the Problem. Blockly acts weird if it comes to strings.
We use a Telegram Bot to send infos about what open-hab is doing.
To make the Messages less sterile we wanted to use some emojis.
Works fine if I code in the DSL-editor:
sendTelegram(ChatIDL, "Textitext! \ud83d\udc33")
Results in a happy Whale emoji.
When we use Blockly:


it results in a message with the code because Blockly doubles the Backslash in the String:
sendTelegram(ChatID, 'Textitext! \\ud83d\\udc33')
Any way to stop Blockly doing that?
Thanks for your help.
Greetings
Metzger

It seems you are using this library:

In general you may therefore ask @Rolli to look further into.

However, the root cause is in in fact standard blockly behavior and not related to the telegram library
:
image

results into

logger.info('Textitext! \\\\ud83d\\\\udc33');

thus, blockly is escaping backslashes because it doesn’t understand unicode escape sequences.

However, what you can do is just copy and paste the real (whale) character into the string and it works:

(I don’t use telegram, so I sent myself a notification via openHAB and I received the whale on my mobile)


for reference there used to be a blockly bug with unicode characters but this has been solved for quite a while already.

2 Likes

Hey Stefan,
sorry for not having the Idea, to copy the Emoji directly without messing with Escape-codes.
Makes sense to try it.
It is a bit confusing, that OpenHAB is not consistent in that way.
For example code for Telegram with Blockly:
things.getActions(‘telegram’, ‘telegram:telegramBot:XYZ’).sendTelegram(ChatID, ‘Textitext’);
can’t be used in DSL-Editor:
val telegramAction = getActions(“telegram”,“telegram:telegramBot:XYZ”)
telegramAction.sendTelegram(ChatID*+L*, “Textitext”)
Thats very confusing.
The same is for the Shelly-Binding
The Item shows the String “Short press” when pressing the button, but in the Code you have to check if “S” is the item state. This inconsistency is driving me nuts.

Thanks for your help.
Now it works as wanted.
Greetings
Metzger

Yeah, from a programmer’s perspective I understand that though you need to see that from the “language” component perspective. Each programming language has its own behaviour (even though most languages use the backslash for unicode escaping). Openhab Blockly relies on the Standard Blockly library, so this is by design the way it is. Blockly’s idea is to be non-tech user friendly, so they don’t want users to know about escaping and the like, I am sure.

Glad that it helped. (pls mark the post as solved then)

1 Like