{"action":"created","issue":{"url":"https://api.github.com/repos/eclipse/smarthome/issues/587","repository_url":"https://api.github.com/repos/eclipse/smarthome","labels_url":"https://api.github.com/repos/eclipse/smarthome/issues/587/labels{/name}","comments_url":"https://api.github.com/repos/eclipse/smarthome/issues/587/comments","events_url":"https://api.github.com/repos/eclipse/smarthome/issues/587/events","html_url":"https://github.com/eclipse/smarthome/issues/587","id":120137683,"number":587,"title":"Runtime validation of configuration parameters","user":{"login":"kaikreuzer","id":3244965,"avatar_url":"https://avatars.githubusercontent.com/u/3244965?v=3","gravatar_id":"","url":"https://api.github.com/users/kaikreuzer","html_url":"https://github.com/kaikreuzer","followers_url":"https://api.github.com/users/kaikreuzer/followers","following_url":"https://api.github.com/users/kaikreuzer/following{/other_user}","gists_url":"https://api.github.com/users/kaikreuzer/gists{/gist_id}","starred_url":"https://api.github.com/users/kaikreuzer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kaikreuzer/subscriptions","organizations_url":"https://api.github.com/users/kaikreuzer/orgs","repos_url":"https://api.github.com/users/kaikreuzer/repos","events_url":"https://api.github.com/users/kaikreuzer/events{/privacy}","received_events_url":"https://api.github.com/users/kaikreuzer/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/eclipse/smarthome/labels/Core","name":"Core","color":"207de5"},{"url":"https://api.github.com/repos/eclipse/smarthome/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-12-03T10:23:52Z","updated_at":"2016-02-23T13:37:37Z","closed_at":null,"body":"migrated from Bugzilla [#465428](https://bugs.eclipse.org/bugs/show_bug.cgi?id=465428)\nstatus NEW severity *enhancement* in component *Core* for *---*\nReported in version *unspecified* on platform *All*\nAssigned to: Project Inbox\n\nOn 2015-04-24 09:53:11 -0400, Chris Jackson wrote:\n\n> Currently, when saving a parameter, ESH is not checking the type that is in the thing XML file (at least this is my working assumption from looking at what is happening). The problem is that if we send a parameter \"6\", then ESH saves this as a string, and then restores it as a string when the getConfig function is called. However, if the binding thinks this is going to be an integer, and assumes this (as per our previous discussion) then it throws an exception.  The way to solve this is for the rest interface to write this as 6, not \"6\".\n> \n> I know that you could (and probably will) consider this a bug in the UI and I agree that the UI should send back the data correctly. However given the consequences that it will cause the binding to crash if it's wrong, I think this should be checked, and converted where possible, in ESH.\n> \n> The other option is for the binding to perform type checking to see what is returned from getConfig, but this seems wrong to me. The binding has stated it wants an Integer, so it should get one (or at least a BigInteger as per our previous discussion).\n\nOn 2015-04-25 08:17:09 -0400, Dennis Nobel wrote:\n\n> Hi Chris,\n> \n> first I think that the application should send correct values. In the Paper UI IÂ´m converting the values at the client. If the binding expects an integer or boolean, the Paper UI sends the native type as part of the REST call:\n> \n> 'configuration': {\n>    'stringParameter': 'value',\n>    'decimalParameter': 20,\n>    'booleanParameter': true\n> }\n> \n> But I agree that we should have type checking as part of the framework. We planned to do so, but as usual we did not find the time to implement it. \n> \n> > The other option is for the binding to perform type checking to see what is returned from getConfig, but this seems wrong to me. The binding has stated it wants an Integer, so it should get one (or at least a BigInteger as per our previous discussion).\n> \n> Yes, converting inside the binding makes no sense, as (ideally) the binding should not get wrong values if we add type checking and config validation.\n> \n> Regards\n> \n> Dennis\n\nOn 2015-04-25 08:22:23 -0400, Dennis Nobel wrote:\n\n> If it is ok for you, I will change the title of the bug to \"Runtime validation of configuration parameters\" and put it to the list of feature requests.\n\nOn 2015-06-27 08:06:18 -0400, Chris Jackson wrote:\n\n> Dennis,\n> Just another example of this issue. I have the following parameter defined -:\n>             <parameter name=\"channel\" type=\"integer\" required=\"true\">\n>                 <label>Channel</label>\n>                 <description>Specifies the channel the sensor is using</description>\n>                 <options>\n>                 \t<option value=\"1\">Channel 1</option>\n>                 \t<option value=\"2\">Channel 2</option>\n>                 \t<option value=\"3\">Channel 3</option>\n>                 \t<option value=\"4\">Channel 4</option>\n>                 \t<option value=\"5\">Channel 5</option>\n>                 \t<option value=\"6\">Channel 6</option>\n>                 \t<option value=\"7\">Channel 7</option>\n>                 \t<option value=\"8\">Channel 8</option>\n>                 </options>\n>             </parameter>\n> \n> This is saved by paper UI as a string and I then get an exception in my binding. I think this might be a bug in paper ui though since it works ok in HABmin.\n> \n> I missed the comment when you said you would change the name to 'validation' -  to me it should be conversion as well as validation (ie conversion where possible, and validation where not)  Are you happy with that definition? IF so, I might have a look at fixing this.\n\nOn 2015-06-27 08:19:25 -0400, Chris Jackson wrote:\n\n> Actually, what I described above might be a bug specific to PaperUI when creating a new thing. If I edit the parameters, then it is correctly saved as a BigInt, but when it was first created, it was saved as a String.\n\nOn 2015-06-28 12:40:23 -0400, Dennis Nobel wrote:\n\n> Yes, itÂ´s a bug in the Paper UI (see https://github.com/openhab/smarthome/issues/15). As commented before I would only expect a runtime validation, not a conversation. UIs should send data in the correct format.\n\nOn 2015-08-01 04:55:53 -0400, Chris Jackson wrote:\n\n> When adding the validation, we need to ensure that arrays are supported (for the multiple selection option)\n\nOn 2015-08-03 09:43:39 -0400, Dennis Nobel wrote:\n\n> Maybe I missed the forum discussion or the PR, but what is the format of an array value inside the configuration? Values just separated by \",\" or \";\"? Or a real JSON Object like [\"a\", \"b\"]?\n\n"},"comment":{"url":"https://api.github.com/repos/eclipse/smarthome/issues/comments/187702606","html_url":"https://github.com/eclipse/smarthome/issues/587#issuecomment-187702606","issue_url":"https://api.github.com/repos/eclipse/smarthome/issues/587","id":187702606,"user":{"login":"kaikreuzer","id":3244965,"avatar_url":"https://avatars.githubusercontent.com/u/3244965?v=3","gravatar_id":"","url":"https://api.github.com/users/kaikreuzer","html_url":"https://github.com/kaikreuzer","followers_url":"https://api.github.com/users/kaikreuzer/followers","following_url":"https://api.github.com/users/kaikreuzer/following{/other_user}","gists_url":"https://api.github.com/users/kaikreuzer/gists{/gist_id}","starred_url":"https://api.github.com/users/kaikreuzer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kaikreuzer/subscriptions","organizations_url":"https://api.github.com/users/kaikreuzer/orgs","repos_url":"https://api.github.com/users/kaikreuzer/repos","events_url":"https://api.github.com/users/kaikreuzer/events{/privacy}","received_events_url":"https://api.github.com/users/kaikreuzer/received_events","type":"User","site_admin":false},"created_at":"2016-02-23T13:37:37Z","updated_at":"2016-02-23T13:37:37Z","body":"Ok, so it is on the initial creation after all then and not in the `handleConfigurationUpdate`.\r\nNonetheless, the framework should try to reinitialize the handler on an update - I will have to analyze with @sbussweiler why this isn't working. Do you potentially have another stacktrace of what exactly happens if you now try to replace the config by something valid?"}}