New Telegram Binding and updated Action - Tester and Feedback welcome

Tags: #<Tag:0x00007f51dbcf0448> #<Tag:0x00007f51dbcf0240> #<Tag:0x00007f51dbcf0088>

(Miika Jukka) #8

Havn’t fiddled around with developement bindings in a while and never had such problems. As a next step I would try to build it with maven and see if that works. If not, then it’s back to the drawing board.

Edit: I just noticed that you triggered maven build from eclipse. Is it the same thing if you run it from command line?

(Belgadon) #9

I think so. At first I tried “export -> JAR”.

That is what I do now. It still gives me two warnings

[WARNING] Could not transfer metadata org.openhab:pom-tycho:2.4.0-SNAPSHOT/maven-metadata.xml from/to p2-openhab-deps-repo (${ohdr.version}): Cannot access${ohdr.version} with type p2 using the available connector factories: AetherRepositoryConnectorFactory, BasicRepositoryConnectorFactory
[WARNING] Could not transfer metadata org.openhab:pom:2.4.0-SNAPSHOT/maven-metadata.xml from/to p2-openhab-deps-repo (${ohdr.version}): Cannot access${ohdr.version} with type p2 using the available connector factories: AetherRepositoryConnectorFactory, BasicRepositoryConnectorFactory

and this at the end after downloading several files.

[INFO] Adding repository
[INFO] Resolving dependencies of MavenProject: org.openhab.binding:org.openhab.binding.telegram:2.4.0-SNAPSHOT @ D:\openHABProject\git\openhab2-addons\addons\binding\org.openhab.binding.telegram\pom.xml
[INFO] Resolving class path of MavenProject: org.openhab.binding:org.openhab.binding.telegram:2.4.0-SNAPSHOT @ D:\openHABProject\git\openhab2-addons\addons\binding\org.openhab.binding.telegram\pom.xml
[INFO] ----------< org.openhab.binding:org.openhab.binding.telegram >----------
[INFO] Building Telegram Binding 2.4.0-SNAPSHOT
[INFO] ---------------------------[ eclipse-plugin ]---------------------------
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ org.openhab.binding.telegram ---
[INFO] Deleting D:\openHABProject\git\openhab2-addons\addons\binding\org.openhab.binding.telegram\target
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 36.991 s
[INFO] Finished at: 2018-10-28T12:45:27+01:00
[INFO] ------------------------------------------------------------------------

(Belgadon) #10

Ok, so when I did bundle:start <ID> it says Unresolved requirement: Import-Package:; version="2.8.2"
I used that at the beginning, but not anymore. After deleting it from the MANIFEST and builing it again it now works!

Thank you so much, I learned a lot!

Edit: At least for the binding. But I’ll figure out the action too. :slight_smile:

(Belgadon) #11

Updated my first post with the download link of the JARs:

(Miika Jukka) #12

Can you share your code in github?

(Belgadon) #13

I will do that. I have to read the etc. first.
Will be doing it till at least the end of this week.

(Belgadon) #14

Ok, already uploadet it.
But be aware. Like I said my Java is a little rusty and there is definitely much work todo



For now I’m just trying to get feedback on whether the beaten path is the right one.

(Mihai Badea) #15

I’m interested in such a binding/action for Telegram, especially useful to send reminders, like in your example, to “take the trash out” or the like.
However,I think it will be nicer to get the reply from the custom keyboard returned by the action, not through the binding.
Something like:

var String json_keyboard = '{"inline_keyboard":[[{"text":"Erledigt","callback_data":"trash_done"},{"text":"Erinnere mich nochmal.","callback_data":"trash_later"}]]}'
var String reply = sendTelegram("BiergartenBot", "%s und %s solltest du noch raus stellen.", json_keyboard, gCal_Abfall_Event1_Summary.state.toString, gCal_Abfall_Event2_Summary.state.toString)
if(reply == "trash_done"){

What do you think?
Wouldn’t it be easier to write rules?

But some timeout will be needed, otherwise the action will wait indefinitely…

(Mihai Badea) #16

About the binding now…
Seems to work pretty well, however I have some observations:

  • lastMessageDate maybe should return DateTime.
  • lastMessageUsername is not populated, it remains empty (NULL)

(Belgadon) #17

First of all: Thank you for the feedback!

If I understand you correctly, you want the rule to wait for an answer to happen. Unfortunately I don’t think that this is how rules in OpenHAB are intended to work.
Plus: The Telegram API also splits sending and receiving messages. Afaik there is no method for sending a new message that also returns a possible answer.
And I think there is a good reason why:
There could be minutes or even ours between the message send from the Bot and someone sending an answer (thought a button or not). You probably don’t want the rule to wait for such a long time but you want to get and work with the answer, even if it comes half a day later.
I think the binding also should work without the action.

But I totaly agree with you, that the current implementation isn’t very good either. I will definitely try to find a better solution and I will have your idea in mind.

Valid point. I will definitely look into this.

It is only populated if you have an username set in Telegram. Since its optional to have one it can be NULL. Could you check if you have a username set please? In the Telegram App you can set one under “Settings” in the Hamburger menu. The second row should be your username. (Android, iOS may vary)

(Oliver Albold) #18

Hey, update here since November 2018. How is it going? Can’t wat to try that extention!

(Alex Krasno) #19

We are working on it :slight_smile: I’m trying to support Belgadon with the binding.

What we did so far is to migrate the actions provided by the OH1 telegram action module to the OH2 framework and to make use of the TelegramBots API instead of using a http client directly which provides a better abstraction and saves us some code. Now, it’s not necessary anymore to use both the OH1 action to send messages and the OH2 binding to receive replies from the user.

I would like to present my proposal here to have a base for further discussions. I currently see two use-cases:

1. Use-case: your bot wants to send you a message (and wants an answer from the user)
This is very similar to what Belgadon already presented. I will just shows how it would look in a real working example.

Let’s say we have the following items

String telegramMessage "Telegram Message" { channel = "telegram:telegramBot:620b3747:lastMessageText" }
String telegramReplyId "Telegram Reply Id" { channel = "telegram:telegramBot:620b3747:replyId" }
Switch PresenceAnyone "Anyone [MAP(]" <presence>

and this is our first rule:

rule "Nobody's at home"
   Item PresenceAnyone changed to OFF
    val actions = getActions("telegram","telegram:telegramBot:620b3747")
   actions.sendTelegram("MyOH2Bot", "No one is at home, but some lights are still on. Do you want me to turn off the lights?", "Reply_Lights", "Yes", "No")

Notice that the third arguments “Reply_Lights” is quite important because it acts as a connection between the sent message and the answer (we will see later)

The other arguments define the button names that will be shown. The alternative of using variable arguments would be to use exactly one argument like “[ Yes ] [ No ]” and to split that internally with String operations.

After this is send, it looks like this:

Then, we have a second rule

rule "Reply handler for lights"
    Item telegramReplyId received update Reply_Lights
    val actions = getActions("telegram","telegram:telegramBot:620b3747")

    if (telegramMessage.state.toString == "Yes")
        actions.sendTelegramAnswer("MyOH2Bot", telegramReplyId.state.toString, "Ok, lights are *off* now.") 
        actions.sendTelegramAnswer("MyOH2Bot", telegramReplyId.state.toString, "Ok, I'll leave them *on*.")

Here, the “Reply_Lights” is again used in the rule to know for what request the Yes/No answer belongs to.

After the user pressed one of the buttons, the reply markup is removed and the answer is provided:

I pushed the changes for this prototype to Belgadons repository.

2. Use-case: Providing commands

This is not yet implemented, but I think it would be useful if the user could send commands to the bot via /sendcommand Bedroomlight ON
or to get a status: /status TemperatureLivingRoom with reply “The temperature in the “Living Room” is 21°C”
With /help or /list we could show the user a list of available commands and items.

The UI of the telegram client can even show you a list of available commands and you just have to tap on one of them (see Commands).

(borcon) #20

Wow, it sounds good. :grinning:
@ZzetT Any plans to offer in next time a jar file with your changes to test the binding?

(Kristof Rado) #21

I’m interested in this! Right now I can’t really think of a use-case for bots for my home (almost everything is automated and ‘automatically’ controlled), but this is a really good way for controlling your home fast.

(Oliver Albold) #22

Hey Alex, sounds great… Very nice work. Can’t wait to try it!

(David Graeff) #23

Just to let you know: OH is in a bit of movement at the moment. And the OH1 actions must be migrated over in a not so far future. If the new binding is capable of replacing the OH1 action, please submit a PR ASAP and I’ll prioritize the review.

One question though: Is this binding already providing OH2 actions (like the MQTT binding does?

Cheers, David

(Alex Krasno) #24

Yes, in my opinion the idea is to replace the OH1 Telegram actions completly. However, we still need some time I think to test it a bit more, to write documentations and make it “ready”. (It’s our first binding that we develop).
What exactly do you have in mind? By what time should we have it ready for review?
I guess you want to avoid the migration effort for the OH1 actions, right?

However, there is one thing were I’m not sure if we can replace it completly. The OH1 Telegram actions support and API where you can download a picture from a passwort protected location:

sendTelegramPhoto(String group, String photoURL, String caption, String username, String password)

But this is not supported by the library we are using here (since we are not directly using a HttpClient anymore). Not sure if this is a big problem.Ok, in the worst case, we have to use a HttpClient to download the picture first and to pass it to the TelegramBot Lib.

Yes, it is. That’s also why I was asking a few things in this thread (Actions).

(David Graeff) #25

Take your time. But aiming at 2.5 would be sweet (around June).
And yes, with having this binding there is no point in converting the telegram OH1 action.



(Alex Krasno) #26

I have a general question to the OH architects.

Since we are using an external java library (TelegramBots) to simplify the implementation, this comes with the following costs:

  1. it uses an Apache Http Client (see, but this comment seems to “forbid” this?
  2. Since the library is based on a Long polling approach, it uses at least two threads (see for implementation details), but the Coding guidelines explicitly state “Creation of threads must be avoided.”
  3. the license of the libary itself is MIT but it depends on other libraries like Jackson for xml processing based on Apache License 2.0

Do you see any problems with one of those points?

(David Graeff) #27
  1. Not cool. Ideally some shim adapter classes are used. If we have the http usage under full control, https certificates can be managed in a central place and so on.
  2. Not a problem. If there are alternatives like websockets etc those are preferred of course.
  3. Eclipse, Apache and MIT are all accepted licenses.

Cheers, David