[SOLVED] Shared configuration and custom thing add process

Tags: #<Tag:0x00007fc20e638af8>

Hello everyone!

  1. The binding i am developing, additionally to regular per-thing configuration requires some global config. Connection to the hardware is done via a cloud (aka “the grid”, and connecting to a thing requires the cloud connection to be present. This cloud connection requires a key (32 random bytes), which serves as a host identifier. This key is to be generated once and stored for the lifetime.
    Are there any facilities in openhab for this scenario? Or do i just dump a file somewhere?
  2. Things will not be added by the user directly, instead they will be received from the original smartphone app, provided by the vendor. Receiving is done using a one-time password, issued by the app. How to implement that? Usual manual adding in OH allows the user to specify thing configuration directly, but here i need some UI to enter the OTP and receive configuration from the phone. Is it possible to have custom UI for adding a thing? Regular manual adding cannot work because the configuration includes a device unique ID on the cloud network, which is kept but never exposed by the smartphone app.
  1. Look at bindings like OpenWeatherMap and DarkSky. They have an “account” Thing that stores this type of information.

  2. I don’t think this is possible. The way it currently works is you initiate a scan for new things from the Inbox and as the binding finds them they pop up. I’m unaware of any way to pop-up a form to enter some information to use before the scan.

However, what might work is to have that OTP be a parameter on the account Thing discussed in 1. above. Then the instructions would be to modify that entry prior to initiating the scan for new Things in the Inbox.

Well, i also thought about some special Thing type, but from end user’s prospective this feels like a workaround against a missing concept.
I think this should be one of things to consider for OpenHab 3.

Your’s is the first use case to come across a requirement like this. I suspect if you want this feature, you will have to code and contribute it yourself.

Actually not, you have mentioned two other bindings, having some global control/setting. Perhaps i’m the first to see it this way and to ask questions.
Just from the user’s prospective it would be more logical to have e.g. “Receive DeviSmart configuration” section somewhere (in Inbox ?), with a text entry field to enter the One Time Password and “Receive” button.

The global control setting is common and well handled with a set pattern, as I described. Essentially, you create a Bridge Thing that has the account information/API key/username password/serial device controller/etc.

What is unique to you is the need to enter a OTP prior to initiating a scan for new devices. That is, as far as I’m aware, completely unique among all current OH bindings. Given that this part is unique, or at least very rare, it will be up to you to contribute any modifications to handle it if you can’t make it work with what is currently available.

In which way doesn’t a bridge not work here?

It’s not that rare. For OAuth2 one needs to enter an auth token and this is one time used to get refresh token. In the Spotify I mean innogy binding among others this one time token is a configuration and is removed when the refresh token is obtained by the binding.

The dsmr binding for the Luxembourg meter discovers a bridge, but then the user needs to set a key. After this is set the discovery than can discover the actual meters.

What’s different, as I understand it from OP’s original post, is that there is no refresh token. So there is a token/OTP that needs to be entered prior to every scan for new devices. Hence the request for a dialog in the Inbox prior to initiating a scan for new Things.

With OAuth2 et al, you have a token that you only need to use that first time into the Bridge Thing and from that point forward, the binding is able to operate without further information from the user, including discovery of new Things.

Yes, indeed, the OTP is a one-shot token needed to add new devices. You use it once and then you forget it. If you modify your setup and add let’s say one more thermostat, you configure it using original smartphone app, then you would need to re-share the configuration with OpenHAB in order for it to see the new device. And that time you’ll be using another OTP.
BTW OpenHAB 2 almost has the needed infrastructure. In Inbox there’s a “Search for things” button, which allows you to choose a binding and manually initiate a scan. What’s missing is ability to plug in a text field to enter the one-time password.

In order to avoid potential confusion and give some understanding of concepts, i’ll describe how the original DeviSmart system works.
A DeviReg Smart™ hardware is a floor heating thermostat, installed in a standard European (AKA German AKA Schuko) wall box. The thermostat has a wi-fi connectivity and can be controlled by a smartphone app. The app supports multiple such thermostats and can organize them in zones, but it’s all managed by the app. Thermostats don’t know about each other.
The connection is maintained via a custom cloud AKA Grid, maintained by Trifork company. The grid is a peer-to-peer encrypted network. Both smartphone and thermostat are clients in terms of this network. They connect to the grid server and become peers. A peer may ask the grid to establish a connection to another peer. Peers are identified by 32-byte ID’s AKA public keys. A device chooses its key pair once in the lifetime and retains it, becoming known by the public key. In order to connect to a thermostat, the phone app must know its public key.
There is a process of initial pairing for a newly installed thermostat, which knows neither any peers nor Wifi settings. In this and only in this mode it becomes a wifi access point itself and opens up for local connection for any peer. The first connected peer (it is a smartphone app) is expected to add itself to device’s whitelist and configure the wifi. After wifi has been configured local connection is no longer permitted, and the thermostat talks only to peers it knows only via the grid.
In order to add more users to the setup the smartphone app has configuration sharing mode, employing the aforementioned one-time password. The sending phone issues the password; the receiver is expected to supply it. Communication between two participating phones is done via the same grid. During the sharing process sending phone also gets receiver’s peer ID and registers it on all the thermostats it knows, granting the access for a new user.
Users’ smartphones also don’t know about each other, each stores own copy of the thermostats list. If a new thermostat is being added to the setup, the smartphone who has added it needs to re-share the configuration between other users.
So, the easiest way for OpenHAB to get plugged in is to receive the configuration from the smartphone, where things are already set up. Technically it is possible to auto-discover thermostats in initial pairing mode (that’s how the smartphone finds them), but:

  1. This would require to change wi-fi settings on the OpenHAB server.
  2. This would require the user to hard-reset all his/her thermostats; this is the only way to bring them back into initial pairing mode. They would lose all pairings, settings and schedules
  3. Consequence of (2): the original smartphone app would no longer work. Unless you implement full support for configuration sharing on OpenHAB side.
    So it is a bad way to go, especially during initial development phase. Initial pairing mode requires too much functionality to be present. And i don’t even have a spare unused thermostat to develop it.

Actually there is support for shared binding-wide cobfiguration. I’ve noticed that GPIO binding adds parameters under “Configuration->bindings”

The reason why i want to store OpenHAB peer ID globally is how i designed the OpenSDG library. The host key is global for simplicity. Theoretically you can have multiple grid connections if there is a hardware X, using a different instance of the grid, but there is only one host key because it’s the same host.
If i make a bridge Thing and each bridge stores own key, they would fight

Another small question, however: How can a binding update own config? Of course i can assign new values, but how to save them?

If you want my personal opinion, I’d use a file under userdata (many plugins do this) because userdata get’s backed up/restored. Basically at startup, if the file doesn’t exist - generate it and either generate a global key or have the user modify it with the correct key. Discovery can then read the file on a scan and if the key is specified - do whatever you need to do.

Note: you can get the userdata folder location with: ConfigConstants.getUserDataFolder()

As for your second question (assign config parms) - in the discovery, simply call ```setProperties`` on the discovery result to set configuration parameters. If the thing already exists, this will UPDATE the configuration of the existing thing

You can store it as a binding config.

@hmerk yes, this is whati am going to do. Hence the question: how to save settings after updating ftom within the binding itself? Ot are they saved automagically?

The answer to my first question is contained here: https://www.openhab.org/docs/developer/osgi/configadmin.html