psyntium/node-red-contrib-telegrambot
Telegram bot nodes for node-red.
Telegram bot nodes for node-red
This package contains a receiver and a sender node which act as a telegram bot.
The only thing required is the token that can be retrieved by the @Botfather telegram bot.
https://core.telegram.org/bots
Credits
dvv (Vladimir Dronnikov) for providing the saveDataDir configuration option.
snippet-java for adding venue messages. And for providing the markdown problem fallback.
greenstone7 for providing the callback query node.
dceejay for cleaning up the project
Dependencies
The nodes are a simple wrapper around the node-telegram-bot-api
Warning
The nodes are tested with v4.2.1 (ECMAScript 6).
The project is still under construction.
Usage
The input node receives messages from the bot and sends a message object with the following layout:
msg.payload contains the message details
- chatId : the unique id of the chat. This value needs to be passed to the out node when responding to the same chat.
- type : the type of message received: message, photo, audio, location, video, voice, contact
- content : received message content: string or file_id, or object with full data (location, contact)
msg.originalMessage contains the original message object from the underlying node-telegram-bot-api lib.
The simple echo flow looks like:

source flow
Configuration Node
The only thing to be entered here is the token which you received from @Botfather when creating a new bot.
The string is automatically trimmed.
The node contains two optional properties: users and chatids. You may enter a list of names and/or chatids that
are authorized to use this bot. This is useful, if the bot should only accept incoming calls from dedicated persons.
The values in the property fields must be separated by a , e.g.:
Hugo,Sepp,Egon
Leave the fields blank if you do not want to use this feature.
saveDataDir is an optional configuration value that can be set to automatically download all contents like music, video, documents, etc.
Receiver Node
This node receives all messages from a chat. Simply invite the bot to a chat.
(You can control if the bot receives every message by calling /setprivacy @Botfather.)
The original message from the underlying node library is stored in msg.originalMessage.
msg.payload contains the most important data like chatId, type and content. The content depends
on the message type. E.g. if you receive a message then the content is a string. If you receive a location,
then the content is an object containing latitude and longitude.
The second output is triggered when security is applied and the user is not authorized to access the bot. See below.
Sender Node
This node sends the payload to the chat. The payload must contain the following fields:
msg.payload.chatId - chatId
msg.payload.type - e.g. "message"
msg.payload.content - your message text
msg.error - is set when an exception occurred
Command Node
The command node can be used for triggering a message when a specified command is received: e.g. help.
See example below.
It has two outputs
- is triggered when the command is received
- is triggered when the command is not received
The second one is useful when you want to use a keyboard.
See example below.
Callback Query Node
The node receives the callback queries of inline keyboards.
See example-flow inlinekeyboard in examples folder.
Reply Node
The reply node waits for an answer to a specified message. It should be used in conjunction with the sender node:
See example below.
Implementing a simple echo
This example is self-explaining. The received message is returned to the sender.

source flow
Implementing a /help command
This flow returns the help message of your bot. It receives the command and creates a new message, which is returned:

Note: You can access the sender's data via the originalMessage property.
Implementing a keyboard
Keyboards are very useful for getting additional data from the sender.
When the command is received the first output is triggered and a dialog is opened:

source flow
The answer is send to the second output triggering the lower flow. Data is passed via global properties here.
Implementing a on reply node
Next to the keyboard the bot could also ask a question and wait for the answer.
When the user responds to a specified message the telegram reply node can be used:

source flow
The question is sent to the chat. This node triggers the on reply node waiting for the answer.
Note: that the user has to explicitly respond to this message. If the user only writes some text,
the node will not be triggered.

The last function shows how to evaluate the answer using a function node with two outputs.
Implementing an inline keyboard
An inline keyboard contains buttons that can send a callback query back to the bot to trigger any kind of function.
When the command is received the first output is triggered and a inline keyboard is shown:

source flow
The callback query is received by the receiver node. It must be answered like shown as follows:
Here you can add your code to trigger the desired bot command. The answer contains the callback query data in msg.payload.content.
Edit an inline keyboard
An inline keyboard can be modified using the 'editMessageReplyMarkup' instruction. To be able to modify an existing message you need
to know the messageId of the message of the keyboard.
A sample flow is provided in the examples folder and could look like this:

source flow
The message id needs to be saved in the flow or gobal context. This is just a demo assuming that there is only one single chat.

Replace the initial keyboard with a modified one using the magic 'editMessageReplyMarkup' command as type.

The following switch node just handles the response and hides the keyboard using another magic command: 'deleteMessage'

As an alternative to 'editMessageReplyMarkup' you can also use 'editMessageText' to replace the keyboard and also the text as follows:

Receiving a location
Locations can be send to the chat. The bot can receive the longitude and latitude:

Sending messages to a specified chat
If you have the chatId, you can send any message without the need of having received something before.

source flow
Sending photos, videos, ...
Next to sending text messages you can send almost any content like photos and videos. Set the right type and content and you are done.
If you want to respond to a received message with a picture you could write:
msg.payload.content = 'foo.jpg';
msg.payload.type = 'photo';
Note: that the chatId is already the correct one when you reuse the received msg object from a receiver node.
You can use one of the following types to send your file as content:
- photo
- audio
- video
- video_note
- sticker
- voice
- document
The content can be downloaded automatically to a local folder by setting the saveDataDir entry in the configuration node.
You can add a caption to photo, audio, document, video, voice by setting the caption property as follows:
msg.payload.caption = "You must have a look at this!";
The following types require a special content format to be used. See the underlying node api for further details.
- location
- contact
- venue
- callback_query
Sending contact
Sending a contact is limited to the fields supported by the underlying API to "phone_number" and "first_name".
But you can also receive "last_name" if the client sends it.
msg.payload.type = 'contact';
msg.payload.content : { phone_number: "+49 110", first_name: "Polizei" };
Advanced options when sending messages.
Text messages can be in markdown format to support fat and italic style. To enable markdown format
set the parse_mode options property as follows:
msg.payload.options = {parse_mode : "Markdown"};
Telegram always adds a preview when you send a web link. To suppress this behavior you can disable the preview
by setting the options property as follows:
msg.payload.options = {disable_web_page_preview : true};
The callback query answer has a show_alert option to control the visibility of the answer on the client.
It is directly mapped to the options property.
msg.payload.options = true;
Configuring security
The configuration node contains two properties for applying security to your bot. You can choose between configuring
the single usernames or configure one or more chat-ids that are allowed to access the bot. The values must be separated using a comma like shown in the screenshot.

Note: that the chat-ids are positive in chats where you talk to the bot in an 1:1 manner. A negative chat-id indicates a group-chat.
Everybody in this group is allowed to use the bot if you enter the chat-id of the group into the lower field of the configuration node.
Detecting unauthorized access.
The receiver node has a second output, that is triggered when authorization fails. The message is send to this output for further processing.
You can reply on that message or log it to a file to see who wanted to access your bot.

The message needs to be formatted before the log to file node can be triggered. A simple function could look like this:

Implementing a simple bot
Putting all pieces together you will have a simple bot implementing some useful functions.

source flow
All example flows can be found in the examples folder of this package.
License
Author: Karl-Heinz Wind
The MIT License (MIT)
Copyright (c)
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.










