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.
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.
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.
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)
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):
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
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.
If you use Jython there is the python-telegram-bot module. I do everything in python anyway and this way it nicely integrates into my automatization scripts.
Put the telegram module it into your library paths together with the other dependencies (future and certifi)
Unfortunatelly jython appears to handle sockets slightly different (explanation i don’t really understand) and you need to change the shipped urllib3. There is a platform dependent function is_connection_dropped(), I had to adjust:
sed -i 's/return bool(wait_for_read(sock, timeout=0.0))/return False/g' python-telegram-bot-10.1.0/telegram/vendor/ptb_urllib3/urllib3/util/connection.py
After installing the dependencies you can copy the telegram-module’s example echobot to your jython scripts folder to get started. This way once the telegram bot receives a message all openhab-jython functions can be used directly without running another abstraction layer.
I had same problem, so I decided to write a simple bridge application in java (spring boot) to control OpenHab using Telegram and REST API.
It supports only 4 commands at the moment, but works pretty well and is easily extendable. You can run it on the same machine with OpenHab.
Here is a description and instructions how to use it:
For whom it may concern, I just use a python script that constantly checks the telegram bot “in the background”, creates a buttons keyboard in the chat after /menu command and receives any button press (commands to OpenHAB) forwarding to OH via MQTT