In listening to some of the recent discussions about attracting and keeping non technical users we always seem to get to a point where there becomes a trade off…if you want to do more…you need to get your hands dirty in code…and I can appreciate that…GUI’s can be a nice front end to complex code, but most of the time you end up working with a limited feature set of the code. So it becomes a balance of ease of use vs capability.
Recently I was looking for an answer in how I could pull in data from a Web Service for one of our larger touch walls we support for a client. In reviewing the platform documentation, an option was available which would make the task fairly easy. I was impressed at how a tool like this (linked below) could really push OpenHab by leaps and bounds.
The tool I’m referring to provides for a very fast and easy way (GUI) to digest Web Services and import/format the results for display in the software.
It seems to me a tool like this for OH would greatly simplify the countless threads for how to I import this or that and how do I get content to display like this or that.
Granted I’m aware this was developed by a for profit organization but we have some smart folks around these parts who I am sure could run with this and expand it even more. I wish I had the development chops myself as I would be neck deep in this.
With a tool like this the amount of needed bindings would surely decrease and number of services available to OH would surely increase.
Seems to me this could be the mother binding that would provide a great deal of functionality and would lessen the amount of work that is required to maintain a great deal of bindings that import or pull data.
The thing is: You need to meta describe your API endpoints. We do this already via the swagger (“OpenAPI Specification”) standard. Each endpoint is described as a json file.
There were some attempts out there to create automatic UIs based on that information (“json forms” etc), but in the end you need to realize that an API endpoint is very domain specific and usually requires a custom UI with specific context help and related inter-links.
Also REST doesn’t scale very well (you need a lot of calls/roundtrips to accomplish specific tasks). That’s why GraphQL got invented and it works pretty well for Facebook and Github and others. I started this discussion in Core already to offer a v2 API based on GraphQL.
Maybe I did a poor job of explaining what the tool above does. This tool allows me to grab content from third party providers.
In just about 15 minutes with this tool, I am pulling:
weather data in from Dark Sky
pulling traffic commute times from Waze
video feeds from traffic cams
All of the above would require separate bindings or use of the EXEC binding etc to work. If we had a tool like this that simply allowed me to pick the information I want and assign them to items…BOOM!
The tool gave us the ability to grab what we need…no REGEX and ingest very quickly. We even had to adjust some data post pull and that was all handled by the tool.
Maybe I’m over simplifying here…but damn it made quick work.
Ah I got it. Yes the average weather binding is 300 lines of code. Would be awesome to just click a service file together to retrieve data and map them to Things and Channels.
Things that I notice on a quick perusal of the docs:
REST APIs I think make up at most a large minority of OH bindings. So this cannot be “one binding to rule them all”
It appears to only support public APIs. If you are working with a home automation device that doesn’t require stronger than basic authentication you should not be using that service.
The AI parts are intriguing.
I think you ought to be able to use this tool as it is to build an integration with OH. Or at least get enough information to use the HTTP binding and Actions to access the data.
I think this sort of approach would be awesome for ingesting data from public services. I think it’s utility for building bindings to consume from home automation cloud services would be pretty limited. It would be great is someone were to code something like this into OH, but I still don’t think it would be able to reproduce/replace many bindings. Stuff like Weather binding and Air Quality binding would be fair game. Interfaces like Ecobee and Nest, not so much.
No I really mean 300 lines, but I meant SLOC. Every file causes 40 lines of license header, so you are basically punished for organizing your code. That’s why you usually use SLOC as the correct metric. But all in all, it’s really just that much.
