[insteon] Added the ability to configure devices from the UI

[robnielsen]

Initial support includes broadcast channels for PLM and disabling heartbeat for motion sensor II

[fwolter]

I find it highly questionable to let the user enter JSON data for configuration. Are you aware that Channels can have config parameters as well?

[robnielsen]

Yes, I'm aware that channels can have config parameters as well, but they are not accessible by the Paper UI, you must define these in a .things file which can be confusing. This changes allows to completely configure the things and channels from the UI. Other than JSON, what do you suggest to use for config data that requires key/value pairs and varies by device and channel?

[fwolter]

Channel configuration parameters can be configured in PaperUI. See the pen:

I'd add all config parameters that a specific Channel can have to a Channel. I think you can remove config parameters at runtime, if you only know at runtime which parameters are applicable.

[robnielsen]

@fwolter Thanks for the info, I'll remove the code for configuring channels.

[TravisBuddy]

Travis tests were successful

Hey @robnielsen,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[robnielsen]

@fwolter, the ability to configure channels has been removed

[fwolter]

Maybe I miss something, but why do you use JSON format for the Thing configuration? If I see correctly, there are two new config parameters. Why not adding them as normal configuration parameters to the Thing?

[robnielsen]

The config parameter varies by the Insteon device that is specified by the productkey parameter of the device. Currently there are only 2 of the approximately 50 device types are using this new optional way to configure devices. The parameter will more than likely be different for each new device configuration and adding these to the thing will just complicate configuration it will be full of parameters that are useless.

[fwolter]

After looking at the rest of the code I understand why you chose this approach.

It might've been better if each productKey got its own Thing type. Then, you could define the config parameter as needed for each product and you don't need to assign Channels dynamically.

Maybe OH3 is a good opportunity to think about a breaking change.

As I don't have any better idea to integrate a product specific config in the current design, I'll approve it.