I’ve successfully added a working Telegram thing through Paper UI, but as I want to add all the things in .things-text files I wonder how to realise that.
When I use the following syntax openhab log tells me at the time of sending a message:
2020-03-03 08:09:29.753 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule ‘Send telegram with Fixed Message’: Instance is not a TelegramActions class.
test.rules: val telegramAction = getActions("telegram","telegram:myOpenHAB:anyID") telegramAction.sendTelegram("item temperatursensor_01_luftfeuchtigkeit changed to %s, number is %.1f", temperatursensor_01_luftfeuchtigkeit.state.toString, 23.56)
Don’t, v1 are deprecated.
It will certainly not work text-based neither in the near future nor likely in the far future. OH3 which will have a new GUI but it won’t extend text input capabilities.
I’m not sure if I agree - if the deprecated way still works and the V2 version does not deliver the results you want - go with the V1 version.
Deprecated just means it will be cut of in the future, but if it is the only way to get the result you want just now than go for it…
It is not. It’s the way that he and you want to use by all means but not the only one…
The alternative is the GUI way, and that is proven to work for many users.
And btw the v2 binding is much more powerful, for example you can have rule-driven dialogues with your home now.
The recommendations in the link above are there for good reason. We don’t want anybody to unnecessarily use exotic configurations and then come here ask for help if they don’t work.
That’s wasting everybody’s precious time.
Hmm - GUI configuration might work for some users, but I wouldn’t say it works for everyone. It’s actually one of the strong points of openHAB 2 that you can decide if you prefer text based configuration or the GUI way and, in my eyes, it would be a real loss for openHAB if we lose that on our way forward…
But leaving the question of GUI vs. text based configuration aside:
What??! Your arguments might be valid for an commercial product, but is, IMHO, a no-go for an Open Source Community and not a reflection of my impression of our community over the last few years.
If a question / a configuration is to exotic for you - that’s no problem at all, just skip it. In many cases there will be someone else who will answer, even if it’s just about pointing someone to the right documents.
Can you please not start the gui vs textual configuration discussion?
There have been plenty of arguments made for both methods and there are strong supporters on both sides.
If it works textual - even better. What @mstormi propably was trying to say is just to try it out.
Of course it does. GUI works for everybody, text does not. Technically speaking, that is.
What you mean is you prefer to have text input capabilities. So do I but that’s a completely different discussion and just as @Spaceman_Spiff requested I won’t discuss this (again).
And frankly, things is a very good place and argument to do it GUI (-only).
Things are one-time inputs that works better via GUI (think input validation, help texts etc).
Autodiscovery is another big plus because in larger systems to use KNX, ZWave or similar subsystems, you will want to use that instead of writing down every device.
So there is no advantage in text things but disadvantages only.That’s why docs recommend to do things GUI only today.
Note items and rules are different. For items text is recommended (although that’ll likely change to GUI in OH3), and for rules GUI does not work anyway (except simple use cases with NGRE).
No they’re equally valid for FOSS and OH. It’s not about developing/providing/maintaining functionality.
It’s about the effort that needs to be put into documenting, debugging and supporting. There is no value in having an exotic configuration when a simple mainstream one provides the same functionality.
You’ve quoted my statement but I don’t think you understood it, please go read it again.
Whilst this might be true for most of the users, there are edge cases where it’s not.
I have some z-wave sensors which currently only work when configured manually in a *.things file and it provided an easy way to use these sensors which would have not been possible using only the gui.
As long it is only recommended and not enforced. I maintain multiple OH installations and for me it’s easy to share functionality between them by creating the files once and then just share them through cloud sync.
That would not be possible with the gui.
Well ok but I wouldn’t call that an edge case then because it is not intentional from a design pov.
It`s supposed to work in GUI, if it does not I would call it a bug or incomplete implementation.
I’m not going to get into the text versus gui argument. But I do want to add that when “GUI” is referred to, what is really referenced is the REST API. You do not have to use PaperUI or even a GUI in order to create Things using the “GUI” way. You can use anything to construct a proper JSON formatted THING and submit it to OH using curl or some other type of tool to submit the HTTP POST/PUT command to the REST APi.
I believe it also might be possible to use the Karaf console to create a Thing.
Finally, it’s possible to edit the JSONDB by hand if desired, just don’t do so while OH is running.
Where would this be useful? I like to point to the MQTT case. I had a dozen or so MQTT Things that I needed to create when I migrated to the v2 binding, most of which were very similar with the only difference being the topics. So I created the first one using PaperUI, then used the REST API to access the resultant JSON which I then edited and submitted back to the REST API to create additional Things. I had all those dozen new MQTT Things created in just a few minutes.
For those bindings that do not provide documentation for the available parameters on the Things, one way you can discover them is to create one using PaperUI and then examine the resultant JSON. The parameters usually match. Also review the Things configuration page in the docs for the generic details about .things definitions.
But my understanding is that for OH 2.x at least, the parsing and handling of .things files is implemented by the core so theoretically you should be able to create .things files for any v2 binding. However, some binding authors do not directly support .things file so documentation and support for the specific attributes and supported values may not exist. And to restate Markus’s statement, helping people with syntax errors in .things files is a huge time sink for us. You are guaranteed to never have a syntax error when you use PaperUI to create your Things. You usually get reasonable syntax errors when submitting JSON to the REST API. So I know that I and a number of other helpers on this forum have simply stopped supporting requests for help with .things files. Tools are provided to help you avoid these syntax errors so “use the tools” is often going to be the response from the majority of day-to-day helpers on this forum.
I’ve found out that the error was in the syntax I used for the things file.
Instead of Thing telegram:myOpenHAB:anyID "Telegram-Bot"
I have to use Thing telegram:telegramBot:anyID "Telegram-Bot"
Didn’t realize that when reading the Telegram Binding’s site on OpenHAB documentation.
I understand that telegram is the bindings name, but how should I know of the second part?
The first keyword defines whether the entry is a bridge or a thing. The next statement defines the UID of the thing which contains of the following three segments: binding id , thing type id , thing id . So the first two segments must match to a thing type supported by a binding (e.g. network:device or astro:moon ), whereas the thing id can be freely defined. Optionally, you may provide a label in order to recognize it easily, otherwise the default label from the thing type will be displayed.
From that you should know that the first field is the binding name and the second field must match one of the supported Thing Types.
It could probably be made more clear in the Telegram binding docs but under “Supported Things” it does say
telegramBot - A Telegram Bot that can send and receive messages.
As I said above, many binding authors don’t do a great job of documenting their .things configurations. And even when they do, they assume you have read and understood the generic Thing documentation. But, when you use the REST API/UIs you don’t have to worry about these problems.
