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.

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.

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.

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.

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

gruenwaldt:

Now trying to get an overview if its worth trying

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!

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?

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.

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 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.

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.

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:

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
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

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.

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?

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.

job:

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.

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).