[PaperUI] Prompt for credentials/config after discovery

Hello together,

I’m working on a binding for a password protected network device. I’m able to discover the device in my LAN and add it to the inbox. In the Inbox a user would then click on this device and be able to enter its label only. As at this point discovery knows no credentials to connect to this device, the Thing is instantly OFFLINE. A user must first open the Thing, enter credentials, update and reinitialize the Thing.
My question: is there a possibility (or a ToDo) to prompt for additional information while adding a Thing from Inbox? For example, if a Thing have 5 configuration entries and but 3 were provided with DiscoveryResult, PaperUI would prompt for the other two?

(Edit: see picture)

Thank you in advance
Pav

If the binding supports additional config options I think those options will be listed when you browse to the Thing under Configuration -> Things. I don’t know if there is anything in work to prompt for additional information. You can check in the eclipse smarthome repo’s issues:

Hi and thank you for your answer!
Sure I can update my configuration later.
My dream: I discover the Bridge automatically, would be prompted for credentials upon discovery and would then directly discover connected Things.
Currently I have to add my Bridge, go to Configuration -> Things, enter credentials and reinitialize the Bridge, all before discovering connected Things, which disrupts the user experience somehow.
Best regards
Pav

Hi Pav,

I agree that the current process is not very user friendly.
Ideally, I would one day want to see some kind of wizard that could also guide you step-by-step through the necessary process (besides entering values, you might also have to press some button on the device or follow an OAuth2 flow…), but this is a complex topic that probably won’t be addressed anytime soon.

For your case, there is imho a rather simple improvement possible that would already help a lot - I entered my suggestion as an issue in June: https://github.com/eclipse/smarthome/issues/3657
Unfortunately, nobody has come up with a PR yet…

Regards,
Kai

I see now that you’ve faced the same issue and I’m but stumbling in your footsteps. Thanks for pointing this out, at least I don’t have to harbor false hopes :slight_smile:

Hello again Kai.

As I’ve seen, you are one of the contributors to the PaperUI interface. I’m new here and before I make any PRs I’d like to hear your opinion. After spending several hours yesterday I came up with three solutions for the discussed issue. The implementation difficulty (as well as fault possibility) differs:

First and easiest: as you’ve proposed, after thing discovery user could be prompted for redirection to Thing Edit instead of Thing View. This requires but one line diff in controllers.setup.js:

- toastService.showDefaultToast('Thing added.', 'Show Thing', 'configuration/things/view/' + thingUID);
+ toastService.showDefaultToast('Thing added.', 'Edit Thing', 'configuration/things/edit/' + thingUID);

I find this approach too generic to be accepted widely.

Second solution would be quite the same with a previous check in the same JS file:

     $scope.label = discoveryResult.label;
+    $scope.hasEmptyProperties = false; 
+    for (var key in discoveryResult.properties) {
+        if (discoveryResult.properties.hasOwnProperty(key)) {
+            if (discoveryResult.properties[key] === "") {
+                $scope.hasEmptyProperties = true;
+                break;
+            }
+        }
+    }
     $scope.thingType = null;

This new variable would then be passed…

     $scope.approve = function(label) {
         $mdDialog.hide({
-            label : label
+            label : label,
+            hasEmptyProperties : $scope.hasEmptyProperties            
         });
     }

to the function from the first approach, where an additional check would be performed:

-    toastService.showDefaultToast('Thing added.', 'Show Thing', 'configuration/things/view/' + thingUID);
+    if (result.hasEmptyProperties) {
+        toastService.showDefaultToast('Thing added with empty properties', 'Edit Thing', 'configuration/things/edit/' + thingUID);
+    } else {
+        toastService.showDefaultToast('Thing added.', 'Show Thing', 'configuration/things/view/' + thingUID);                
+    }

This approach is preferable as it would change nothing for the end user unless the binding author explicitly adds an empty parameter upon discovery, e.g.:

properties.put(BindingConstants.PASSWORD, "");

As it would be a quite rare case, a straight redirect could also be possible.

$scope.navigateTo(..);

Third solution would involve prompting for empty properties upon adding a Thing from Inbox:

     <md-input-container class="col-xs-12 noPadding"> <label>Name</label> <input ng-model="label"> </md-input-container>
+    <div ng-repeat="(key, value) in properties">
+       <md-input-container class="col-xs-12 noPadding" ng-if="value===''"> <label>{{key}}</label> <input ng-model="properties[key]" > </md-input-container>
+    </div>  

… and POSTing them as JSON string along with Thing label to the approve() in InboxResource.java and further into the core. This approach is the most complex but also the most elegant one (see picture).

I hope I am not overbearing and thank you for your work so far! :slight_smile:

Best regards
Pav

Hey Pav,

Sorry, but I am not at all a developer of the Paper UI - I have no clue about Angular and Javascript…

To find the right people to discuss the ideas, you should better follow up the discussion on the ESH issue.

Thanks!
Kai

Oh, sorry, I’ve seen your name somewhere in the project and assumed…
Anyway, I’ve posted this link in the issue you’ve mentioned and hope to be seen :slight_smile:
It’s also a kind of philosophy question: which option would be the most user and developer friendly.

@Pavion, @Kai,

we have also ideas and think about adding a wizard.
Maybe we can join forces?

BR Mehmet

Hello Mehmet,

please take a look at this issue submitted by Kai https://github.com/eclipse/smarthome/issues/3657
stating:

#3 would only be the start of a way more complex wizard-like approach which I would like to start only if we have the requirements to do so.

Anyway I’ve still tried to implement a wizard approach but had to realize, that the required changes would involve:

  • updating core functions such as Thing handler and Discovery Handler
  • changing data transfer between core and UI (POST handling)
  • updating PaperUI interface and underlying JS functions

As I’m new to this project, I can’t even estimate every required change or their impact on other functions. Also implementing and getting approval for such a major change will take enormous time I simply don’t have beside my job.

Still, if you have the capacity and are keen to try it, I wish you good luck!

Best regards
Pav

P.S. For a lite approach, please see my PR:

1 Like

@Pavion,

I can’t find where paperui is located in github anymore. I noticed that your PR was merged, but is it still the case now?

I have a question though:

I have two types of device, one type needs a key to be set, another type doesn’t. Other than that, the api is the same, so they are implemented by the same binding handler. During discovery, I can differentiate between the two types of device. Is there a way for me to make paperui to prompt for the key for the device that needs it, but not prompt for the one that doesn’t need it?

Hi @JimT,

upon discovery you’re using Builder to create your Thing. Here you puts all Properties you know. If there are Properties specified in your XML but not supplied here, you’ll be prompted to enter them after creation.
So in your case just supply a dummy key for one device type and left it out for another device type and you should be fine.

 @Override
    public DiscoveryResult createResult(ServiceInfo service) {
...
                    properties.put(Constants.PROTOCOL, "http");
                    properties.put(Constants.PORT, port);
                    properties.put(Constants.HOST, ip);
// properties.put(Constants.KEY, key); <-- either put a dummy value or comment it out to be prompted

                    DiscoveryResult result = DiscoveryResultBuilder.create(uid).withProperties(properties).withLabel(label).build();
                    return result;
...
    }

BR Pav

Brilliant!

I tried this, but it didn’t prompt when I did Autodiscovery -> Add Thing.

Furthermore I realised I can’t do this because the type that doesn’t require the key, will not have the key=“xxx” in people’s Thing definition and by making “key” a required property, the existing things will become offline with “HANDLER_CONFIGURATION_PENDING”.

Why not define it as required:

<required>true</required>

Using Discovery you can add this parameter with a dummy value for devices w/o key and skip it to be prompted. HANDLER_CONFIGURATION_PENDING is the proper response in this case and as of 2.5.0 should redirect user to Thing configuration page.
People using text files will have to use a dummy key in that case, sure, so what? Just state it in your readme and make a nice example :slight_smile:

It will break existing installations.

This isn’t what I am observing. It just says “Things added”. I am on 2.5.2 right now.

That is weird. I’m using 2.5.0. Username and password are declared as required. Thing is discovered. I click it, click on “Add as Thing” and I’m redirected with “Thing added and must be configured” message:


If I enter credentials, Thing goes ONLINE. If I leave this form without saving, Thing keeps its state: HANDLER_CONFIGURATION_PENDING as expected.

Are you sure? In my case above I’ve just tried text file configuration without both required values. It haven’t thrown any error and my Thing was created with both fields empty, marked red as expected. So it should be in your case. Old text file configurations should still be accepted, new key field may be shown red then and not changeable but it should not affect Thing’s functionality in any way.

Is that Thing created through text file config in ONLINE state without having the username and password specified in the config?

Well, Thing creation is handled by Handler, so it’s up to the developer how to react to it.
In my case, Thing can not be online, as my parameter are required. Thus my Handler still marks it as HANDLER_CONFIGURATION_PENDING.