Hello,
I am using telegram for status messages for a while now.
But is it possible to receive orders via telegram?
Until now, I could not figure it out.
It would be nice to have a bot to understand something like:
“Me: /SwitchHeating ON”
Maybe triggering a OpenHAB Rule “SwitchHeating”
Thank you in advance
Someone would have to write a Telegram binding. It looks like right now there is only an Action which will only let you send messages, not receive.
Ok, thank you.
I had hoped to have overlooked something.
Well… someone could do that. As far as I know Telegram offers a wide API for these kinds of developments and there are probably java reference implementations available. @gruenwaldt why not check it out? There are numerous similar bindings you could derive from.
Side Note: Not sure if this component would be a binding or IO addon.
An honest question (versus some of my more Socratic challenging questions). What is the distinction between the two? It seems a little blurry to me what sort of API falls into one category versus the other.
@gruenwaldt, it occurred to me that you might be able to make something work through IFTTT and the Telegram and openHAB channels.
The repository is forked already.
Now trying to get an overview if its worth trying (for me), since i never contributed to ObenHAB before
What about this as an option @gruenwaldt? http://www.instructables.com/id/Raspberry-remote-control-with-Telegram/
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.
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!
I also like this idea!
Would this be any help if somebody starts to develop a binding?
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.
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?
Thank!
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? 
I think it largely depends on the implementation.
If you create an IO add-on it would work like:
No Rules are required.
If you create a regular binding it would work like:
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.
wow, what did I do here 
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.
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!
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. 
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:
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.
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
return
end
if (msg.text == ‘sink’) then
os.execute(‘/opt/OSscripts/kitchen_sink.sh’)
end
end
function on_binlog_replay_end ()
started = 1
postpone (cron, false, 1.0)
end
And for the kitchen_sink.sh it has the following:
curl --header “Content-Type: text/plain” --request POST --data “ON” http://xxx.xxx.xxx.xxx:8080/rest/items/kitchen_sink_light
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.
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 
):
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).
There is XMPP console functionality which perfectly allows to control OH (lookup for items, get status, update and command):
>
help
<
Usage:
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