Let’s say I have an addon that I’m creating (ahem sony) and when I discover the device, the addon writes a bunch of default configuration options I get from the device. For this example, let’s say it’s the mac address of the device (the sony device has an api that returns the mac address and I write it to the configuration). The addon needs to know the mac address to send WOL packets correctly.
Now - the mac address is correct in about 95% of the cases but there are a few devices that return an incorrect mac address (not technically incorrect [it’s still a valid mac address] - it’s just the wrong mac address).
Because of that - I made the mac address a configuration option to allow the end user then to ‘correct’ the mac address to the correct one.
All great until the next discovery packet comes into the system - then I query the mac address, put the ‘incorrect’ mac address into the configuration and send the result. This will then, unfortunately, overwrite the ‘correct’ mac address that the user entered.
What would be the correct way of handling this? I don’t see anything in the config xml that would help but hoping someone might suggest something.
My latest thoughts is to write those variables that default from device but can be overwritten by the user as PROPERTIES instead. The addon would then check to see if a configuration has been set by the user and if not, fall back to the property value.
I don’t code bindings, but can’t you check to see if the mac received in your discovery packet is different from the mac already configured and if so ignore it?
As far as I know - in the discovery participant, there is no way to get to the Thing (to find the configuration). You could potentially reference the thing manager but prior reviewers nicked doing that in a discovery participant (can’t remember correctly but had something to do with timing) - so there isn’t a way to get to the current configuration (that I know of)
Crap - I just realized that the discovery result kinda mixes configuration and properties into a single object so you can’t really say “macAddress” configuration and “macAddress” property (the discovery result is simply “macAddress” property and it’s converted to configuration if there is a like named one).
Looks like I have to go with a backup plan unless someone else has an idea. The backup plan being to have a “macAddress” (settable by the user) and a “deviceMacAddress” (not settable by the user and is not defined in configuration [making it a property]).
Then when I need a mac address - I check the macAddress config property and if blank, use the deviceMacAddress property instead…
That sounds reasonable. Alternatively, you could add a second config parameter with a name like overrideMacAddress that, if set manually, would override the macAddress parameter.
It would be nice if there were a way to control which configuration parameters can be overwritten by discovery results, but so far I haven’t heard anyone complain much about the lack of one.
Do these devices have any unique identifier. Some devices have an id by which they can be identified. I thing you should be able to use the representation-property to filter out those results.
I don’t have any identifier until I’m fully authenticated (which can’t happen in discovery) - however, I’m pretty happy with what I’ve discovered so far…
So I found out that you can create configuration properties in the discovery result that subsquently appear in Configuration (and my custom configuration object) WITHOUT specifying them in the config.xml. I don’t know if this is by design but it works out great because it prevents the user from setting them manually!
So it turns out the above isn’t true (atleast it stopped acting that way after I restarted openHAB). However, if I added them to the config.xml as READONLY - I pretty much achieved the same thing (not modifiable by the user - it’s just they aren’t hidden). Note: would have been really nice if paperui used some kind of visual indication for non-modifiable items - maybe ng-paperui will have something like that…
