I’m building lots of Smart Home devices based on microcontrollers myselfe, (e.g. to controll lights, relays, …). The hardware is often based on the Arduino platform and conected to my network using Wifi. I want them integrated in openHab. Therefor I’ll need to create a own binding. But instead of creating a new binding / extending it for each new device, I’ll do something more generic:
Each of my devices (or custom “hubs”) will host a http-service. This service should expose ThingTypes and Things connected to it. With this generic approach, I can define everything in my “microservices”, outside of openHab. These services will be responsible to maintain the state of Things connected to them. Another benefit of this is, that I can freely choose the language I’ll implement my logic, as long as I make some endpoints available.
I imagine it to work is as follows:
I’ll create a new binding with a “RemoteThingBridgeHandler”, a subtype of BridgeHandler.
This Bridge needs to be configured with a host, a port, and maybe somekind of authentication.
It will then query the host at an endpoint, which lists ThingTypes. For these types, a new ThingProvider is created.
Then, a second endpoint is called, which lists all connected Things and there ThingTypes. They now appear in the Inbox as they are discovered. Each Thing can then be reached using its own endpoint. All commands from openHab will be send to that endpoint, and openHab can poll the state of the Thing.
After reading a bit of documentation, came up with the following endpoints:
get /types
Lists all ThingTypesf
get /things/
Lists all connected Things with an Uid and their ThingTypeUid
get /thing/$ThingUid$
Gives information about that Thing, lists its ChannelUids
get /thing/$ThingUid$/$ChannelUid$
Gives the channel definition, also includes a field that indicades how often the value endpoint should be fetched
get /thing/$ThingUid$/$ChannelUid$/value
Gets the value of the item linked to the channel
post /thing/$ThingUid$/$ChannelUid$/command
Called when a command is issued to the channel
Before I start implementing this, I have some questions:
Is there already anything similar?
Is my understanding of the concepts wrong?
Any general suggestions?
I would say “therefore I want to create my own binding.” The vast majority of OH users who similarly integrate DIY devices with OH use either MQTT or MySensors, both of which already have an OH binding. A small minority will use HTTP/REST or TCP/UDB, again both of which already have an OH binding.
So the only reason to create a new binding is because you want to, not because you need to.
The nice thing about MQTT and MySensors is that you don’t have to poll. The sensors can directly report to OH.
MQTT using the Homie standard on your devices would probably work like you want it to, though it would require changing your approach on the devices themselves. Even your endpoints look a whole lot like MQTT topics.
I don’t code bindings so I can’t say for sure. What I can say is that, from a user’s perspective, a Bridge is a Thing that OH must go through in order to reach and/or discover the devices. For example, Zwave has a Controller thing that represents the USB dongle through which all communication to the zwave devices go through. OpenWeatherMap has a Bridge Thing with all the account information for that service through which the weather information Things communicate.
So I think your concept of a Bridge is reasonably correct, but it sounds like you actually have two Bridges and that is where I’m not clear.
Avoid NIH syndrome and use one of the ways to do this that has already been implemented so you can focus on you can focus on building the sensors and creating your home automation instead of reinventing the wheel to get your devices to communicate with OH.
Of course, if this is the fun part for you, then by all means proceed. Coding stuff like this can be fun. But realize that this problem has been solved multiple times in multiple standardized ways already.
This was actually what I wanted to write. Untill I saw Richard was faster in answering
Avoid polling at all costs, especially if you want your microcontrollers to use as little power as possible (maybe because you want them to be battery driven). Have each active element (the MC in this case) push the data and leave it to the consumer to obtain it. Which in turn matches nicely with the MQTT paradigm
Thanks for your suggestins!
I started creating a homie library in dart. It’s already working and as soon as documentation is finished I will publish it on github.
As openHab frontend I’m using PaperUi. My TV (which is connected through the LG binding) is rendered with a nice slider for volume controll. On the otherhand, the homie device I implemented using the dart library renders the integer value just as a plain number. Can I tell PaperUi to render it as a slider instead?
No, because PaperUi is intended for administration. The Control tab gives you a quick look but has no customization. You will want to create the UI for your bespoke home automation using sitemaps or HABPanel. In both of these cases, you can present the Number Item using a Slider.
