Binding development question : storage, QR code

dalgwen · March 7, 2022, 2:05pm

Hello,

I’m making a Signal binding.
It’s nearly completed (at least the basic functionnalities, it can register, send and receive messages) but I have some remaining points and I would appreciate some suggestions.

1- Storage :
Signal is a stateful protocol, and require to store numerous data (exchange key, etc). What should be the correct way to store data ? On the filesystem, under the user data directory ? For the moment, I decided to use the java prefs system, which let the jvm handle the storage implementation. Is it also a valid choice ? I didn’t found anything on the developement documentation.

2- QR code :
Signal, beside working in standalone mode (already implemented), can work in provisioning mode (i.e. the binding can be linked to an already existing account). The process is :

The device/program asks the Signal server to be registered as a secondary device.
Signal server respond with a special link ( sgnl://linkdevice…). The device/program must now display it to the user in the form of a QR code
The user, with the main device running Signal (most of the time, a mobile phone), must know scan the QR code from within the Signal application.
The two devices are now “linked”.

For the curious, you have an example of such procedure when you try to use the Signal Desktop application. So, to do this, what is the best ? In a user-friendly and secure way ?

Output the sgnl://linkdevice link provided by Signal to the openHAB log and let the user generate a QR code ?
Output the sgnl://linkdevice link as a thing parameter, so it can be displayed on the openHAB thing configuration page ?
Some variation of this, but this time the sgnl://linkdevice URL is wrapped inside an URL to an internet service generating the QR code ? (more user friendly, a little bit less secure)
Let the binding generate the QR code with a java library, and output it on an Image channel (the user must then link it to an Image channel) ?
other suggestions ? Some interaction with the openHAB cloud ?

Thank you for reading me.

rlkoshak · March 7, 2022, 4:01pm

Not a binding developer but I can comment on what makes sense from the end user’s perspective.

Other bindings will create their own folder in $OH_USERDATA to store stuff used by the binding. I’d push for that approach over using the Java prefs system because it’s more consistent and apparent to the end user where data is stored and managed. It will also automatically be picked up by the backup and restore scripts already built into OH.
How time sensitive is this QR code? The HomeKit binding uses a QR code in its settings page in MainUI through MainUI but I don’t know if it follows the same sort of handshake flow you describe, but it should at least be an example you can look at.

dalgwen · March 7, 2022, 9:53pm

Thank you very much,

1- OK, good points, I’m convinced, I will go with the file storage.

2- I don’t know the QR code duration and cannot find the information online. Usually for the linked device (Desktop application is the main one) the process is a one-step, done quickly and hassle free, so it seems that nobody has yet needed to ask the question !
I check the HomeKit integration and the QR code it produces, but it seems to be more than a binding : it goes with its own user interface, if I understand correclty ? I will have to think about it, but I’d rather go without a specific interface if I can

Thank you again

rlkoshak · March 7, 2022, 9:59pm

It’s just configuration. MainUI provides the UI. I think everything there would be just a bunch of XML to describe the forms and other stuff that makes up the configuration. If you’re gonna use a QR code, you gotta use the UI. Most people run OH headless so there will be no other option.

splatch · March 10, 2022, 8:40pm

I haven’t tested that, but from looking at the code I can tell you:

Make a config drscriptor
define config text parameter with context tag set to qrcode
Feed this config parameter with your own qrcode text

Normally configurable services are bound to OSGi managed services and config descriptor is just a way to declare how to draw form for it.

If you have above main UI shall render QR image for user to be scanned:

github.com

openhab/openhab-webui/blob/main/bundles/org.openhab.ui/web/src/components/config/config-parameter.vue#L87

      
        
                } else if (configDescription.type === 'TEXT' && configDescription.context === 'item') {
                  return ParameterItem
                } else if (configDescription.type === 'TEXT' && configDescription.context === 'thing') {
                  return ParameterThing
                } else if (configDescription.type === 'TEXT' && configDescription.context === 'rule') {
                  return ParameterRule
                } else if (configDescription.type === 'TEXT' && configDescription.context === 'channel') {
                  return ParameterTriggerChannel
                } else if (configDescription.type === 'TEXT' && configDescription.context === 'persistenceService') {
                  return ParameterPersistenceService
                } else if (configDescription.type === 'TEXT' && configDescription.context === 'qrcode') {
                  return ParameterQrcode
                }
                return ParameterText
              }
            },
            mounted () {
              // Uncomment to perform initial validation on the field
              // this.$f7.input.validateInputs(this.$refs.parameter.$el)
            },
            methods: {

Seem to be an undocumented feature of UI

Good luck with your binding!!

dalgwen · March 29, 2022, 9:44am

I finally took time to check your responses and to make some tests.

Thanks @rlkoshak, as usual on this forum, you are completely right : it’s just a matter of XML configuration. The Homekit addon or the bindings work in the same way regarding the configuration subject.

And thanks @splatch, you pointed out the exact solution : the “qrcode” context tag in the XML description is sufficient to show it as a real QR code on the GUI. It works flawlessly (it’s kind of magical, in fact).

Now I can continue my work.
Many thanks.