Controlling OpenHAB by Telegram?

Tags: #<Tag:0x00007fadf9e38100> #<Tag:0x00007fadf9e37ed0> #<Tag:0x00007fadf9e37d40>

( #7

What about this as an option @gruenwaldt?

This has also been something I’ve been after as a way to not have to open firewall ports to be able to update OpenHAB values. In the .sh file you would just switch the command to be a curl update to the switch.

( ) #8

As I’m not a Binding developer I rather not dare try explaining. @Kai ?

Adding yet another binding seems pretty easy measured on the previous times a user started out fresh and documented it here in the forum. It will be especially helpful to check out one of the similar addons and derive your work from it. Good luck!

Btw. I’m also a Telegram user and would love this addition!

(Miika Jukka) #9

I also like this idea!

Would this be any help if somebody starts to develop a binding?

(Kai Kreuzer) #10

Short version: A binding adds functions (items) to the system. An I/O add-on exposes existing items to the outside world with the goal to control them. This case here is imho the latter.

(Rich Koshak) #11

That actually makes the distinction clear. So something like Hue Emulation is an IO because it exposes Items to be controlled by external services (e.g. Alexa).

Would it be fair to say that IO bindings should use Tags to identify those Items that are to be exposed (of course the Cloud Connector uses the .cfg file unless something changed that I missed) instead of the usual binding configs?


(Joachim Boeddeker) #12

Not neccessarily. Depends on implementation. If i understood it correctly that is.

I would think of a telegram conversation as the thing, which adds an string item/channel like e.g. ‘last message received’ (incl. addtional metadata, sender etc.) and perhaps another string item/channel like e.g. ‘new message to send’ (with additional metadata as well). With that you can easily write a rule which answers any command.

Did I say, I am interested in anything to receive telegram messages as well? :wink:

(Rich Koshak) #13

I think it largely depends on the implementation.

If you create an IO add-on it would work like:

  • Send specially formatted message to OH
  • OH IO add-on parses the message, determines which Item the message is destined for, and postUpdate or sendCommand (or however an Item is updated or commanded from a binding) to that Item.

No Rules are required.

If you create a regular binding it would work like:

  • Send a specially formatted, but the format is something you come up with yourself, message to OH
  • OH binding sendCommands the message to an Item bound to the Telegram Item’s Incoming Channel
  • User creates a Rule to parse the contents of the specially formatted message and does something with the information (e.g updates or commands other Items)

I definitely see advantages and disadvantages to both approaches. But the IO binding approach fits in more closely with OP’s original use case of messages like: <ItemName> <New State>. It also requires less work on the user’s part as the format of the messages is predefined and no Rules are required.

In short, it could be implemented as either an IO add-on or as a traditional binding, but I think an IO add-on would be a better choice.

(Michael Grünwaldt) #14

wow, what did I do here :smiley:

I would prefer an “In Openhab” solution. No need to make the OpenHAB Homegear etc. things more complex. (in my case)

@rlkoshak I think I would prefer IO Solution too. Would make it possible to control Items just by knowing their Names.

But I think this is a bit too much to start with, for me.

( ) #15

Hey @gruenwaldt,
after all that was said I actually think that a binding with the options stated by @job and with the help of the library mentioned by @gitMiguel would be pretty cool and relatively easy to implement. You should reconsider!

(Rich Koshak) #16

With the IO approach, though it will be more work to implement up front, it will be less work for the users and both the use case of commanding individual Items by name as well as job’s use case would be supported (i.e. you can send any text/XML/JSON to a String Item by name and use a Rule to parse it out).

With the binding approach, the user must create a Rule to parse out the messages and/or the binding will have to support matching and transformations like MQTT 1.x does, at which point is it really easier to implement?

I don’t use Telegram and don’t have time to code something up so I don’t have a dog in this fight. My opinion is worth nill, but I present it non-the-less. :slight_smile:

(Joachim Boeddeker) #17

I am quite interested in such a solution, but as i said, i would prefer the binding solution. I can see the benefits of the io solution, but i don’t see myself controlling single items via text messages.

I would create a handful of commands which start/stop larger processes.

For example:

  • lights : returns the state of all lights
  • batteries : returns the state of all batteries

Is it neccessary to decide one or the other? Isn’t it possible to use a single codebase for the io and the binding approach?

I am currently time limited, but hopefully next month i can try to develop something. Could be fun doing some java again.
Off course, i would start with the binding approach, but the logic behind the io approach isn’t that complex. Parse the item name from the message, get or set the item value, send a reply.

( #18

Not to derail the conversation, but as a quick update I am able to control turning on a light above my kitchen sink (as an added bonus my wife in the same group chat can use the same keyword and it also runs the script).

So with telegram-cli you run the following command on a system (still trying to figure out how to run it as a service)

~/tg$ ./bin/telegram-cli -s ./action.lua

Within in the action.lua I have the following:

function on_msg_receive (msg)
if msg.out then
if (msg.text == ‘sink’) then
function on_binlog_replay_end ()
started = 1
postpone (cron, false, 1.0)

And for the it has the following:

curl --header “Content-Type: text/plain” --request POST --data “ON”

What I also had the most trouble with is that this does not appear to work on a Channel in telegram vs a chat with yourself or a group chat.
I also believe that with the action.lua file you can also limit who can issue what commands by only allowing them to come from you or some other ID; I’m thinking of things like smart locks you don’t want to let kids have the ability to unlock the house for their friends, so limit it to your own ID.

I’m going to be adding some more if conditions into my action file and see how well it works for me.

Another presence method - Android specific
(Kai Kreuzer) #19

Currently yes, but no new tags should be invented and thus the possibilites are pretty limited right now.
The suggested solution to this problem for IO add-ons is a new meta-data service that still needs to be implemented.

A binding seems to be a bad choice for that. This is imho rather the normal use case for a rule action - just like you would send tweets, mails, etc.

Just to give some further options and make it all even more complicated (sorry :blush:):
You could also think of implementing Telegram as a “Console” through which all the smarthome console commands are made available. I actually did that back in 2010 through XMPP (using iChat and Jabber as clients).

(Vladimir Grebenschikov) #20

There is XMPP console functionality which perfectly allows to control OH (lookup for items, get status, update and command):


  update <item> <state> - sends a status update for an item
  send <item> <command> - sends a command for an item
  status <item> - shows the current status of an item
  items [<pattern>] - lists names and types of all items matching the pattern
  say <sentence to say> - Says a message through TTS on the host machine
   <script to execute> - Executes a script

(Manfred) #21

you can use node-red with openhab and telegram nodes to control openhab by telegram.
for openhab and node-red see
if you are using openhabian it is very easy to install.

(Flavio Pompermaier) #22

Any how-to about setting up a working telegram-openhab integration + node-red?

(Chris) #23

Does this still work with OpenHAB2?

If so, can you explain a bit more, what is needed to make it work?

So far I installed the XMPP action addon and sending messages from OpenHAB to the messenger app (Conversations on an Android phone) works. Also messages sent to the OpenHAB server are shown in the log. But I don’t see a way to e.g. switch on a lamp by sending an XMPP message to the OpenHAB server.

(Vladimir Grebenschikov) #24

Not sure, that it works with OH2, but for the latest OH1 it works perfectly for me:
( in config: xmpp:consoleusers=)

Vladimir Grebenschikov:
items Light*

Lights (Type=GroupItem, BaseType=SwitchItem, Members=28, State=OFF)
Light_1_Kitchen_Center (Type=SwitchItem, State=OFF)
Light_1_Kitchen_Zone (Type=SwitchItem, State=OFF)

Also, I’ve small Lua script for telegram-cli command line tool, which provides same functionality over telegram messenger, connecting to console port (localhost:5555), like:

$ telnet localhost 5555
Connected to localhost.
Escape character is ‘^]’.
osgi> openhab items Light*
Lights (Type=GroupItem, BaseType=SwitchItem, Members=28, State=OFF)
Light_1_Kitchen_Center (Type=SwitchItem, State=OFF)
Light_1_Kitchen_Zone (Type=SwitchItem, State=OFF)

(Chris) #25

Thanks for your reply.

I don’t use the telegram messenger, so I would prefer to do this with XMPP (Conversations).

When sending a message from Conversations to OpenHAB I can see in the log that the message was received:

[DEBUG] [hab.action.xmpp.internal.XMPPConsole] - Received XMPP message: items W* of type chat

But OpenHAB doesn’t send an answer to Conversations.

On the other hand I created a rules file which sends a message from OpenHAB to Conversations when e.g. a thing goes OFFLINE. This works so far.

So the question is: what is missing here?

(Fulvio Spelta) #26

Hi all, just to know, is someone working on telegram IO module ?
Have a nice day