I have done it the hard coded way now but it seams time consuming and not so user friendly.
Which parts do I need to customize to get this flow working.
Sample use case)
Say I want to do a widget for TuneIn radio.
The custom widget should be able to be configured through searching through TuneIn’s API to select radio station I want to display in my new custom widget, so this is the configure phase or the “set prop” if we refer to MainUI.
I would like to have a search prop there the user types his search words.
And from there I parse the json and create a cute list in the there the user can select which radio stations he/she want to have in their listen list.
After admin selects a list containing a few radio stations it will set props to eg: like this: ‘s123456’, ‘s284676’, ‘s5398758735’
Later then you place the widget on a page:
it will fetch the more meta data from TuneIn by using the id and making lookups to that Rest API. It will for example fetch images and Title and Description to produce a end user experience like this
Unless I’m misunderstanding, you are not really looking at an interaction with openHAB for this. You are looking to create a custom webpage with built in JavaScript to interact with an external service. No Items are involved. No bindings are involved. It’s all in the browser. So this wouldn’t be a MainUI Pages widget at all.
What you would do is build your “widget” by hand coding the HTML and JavaScript and what ever else is required separately and place the html file(s) into $OH_CONF/html. Then you would put a WebFrame card on the layout page and use /static/<filename>.html as the URL. Your custom HTML page will be loaded into the web frame.
In that case you need to fully integrate TuneIn with openHAB so all this information is available as Items. There is no binding so you’ll have to use the HTTP binding to send and receive the information.
But there is no way for Alexa to send arbitrary text to openHAB so you won’t be able to tell it an arbitrary station to play.
Once you have the Items interacting with TuneIn then it’s a matter of creating or building the widget to display and control those Items. The Widget does not interact with TuneIn directly. Only openHAB Items.
Ok., so through the HTTP binding I can do search in Tunnel API and select what I want to import into items, so by selecting it it will do a second lookup through a second http in TunelApi there I fetch:
the unique station id “s2838724654”
image url
title
description
Is that possible and is that the correct they of thinking in OpenHab, or do I need to create a custom binding to accomplish this?
The next step I see is that I need just have a list of TuneIn items (wich where created from the second HTTP request) in my custom widget that displays this items and a Alexa Echo Binging to connect the Alexa with it,
That one I already solved by sending stationId → “s2378274” to Alexa Echo Binding radioStationId so it start playing that radio station or are am I missing something?
I suppose if it need to be a number I can remove the “s” and add it as a prefix before I send it to the Alexa Echo Binding ```radioStationId````.
Anything is possible but a binding would probably be more straight forward to implement and use and share.
All those round trips will have to be done via rules. Also note that OH is not all that dynamic usually. So it’s going to be a lot of work over all either way.
You can’t ask Alexa to “play NPR” and get “NPR” sent to openHAB.
Nothing to add here. But it sounds like a fun (and challenging) project to realize this in OH just with rules and 1-2 proxy items tbh. I might have a look into this.
Just one more question regarding the solution you’ve in mind:
Could you share this second API request for searching more channel informations based of the station ID?!
I don’t really remember my thoughts if it was the image URI you will find it in the first request in the JSON object.
When taking a quick look at the api
you can query more info on a Station for example with stationID s2836 and the itemToken you get from the first request.
I might have a look into this.