Binding configuration text files and setting properties

[protectivedad]

Does the thing configuration text files allow for setting a property?

My binding has a discovery service that will pull an “ianaTimeZone” field and populate a thing property by the same name. This works great for discovered things. If the thing is manually created in a text file using that information to locate the “ianaTimeZone” is difficult and costly from a resource perspective. So can the ianaTimeZone=“America/Someplace” be put in the configuration text file without making it a configuration parameter?

[mstormi (Markus Storm)]

yes, search some binding docs for .things examples it’ll be something like

Bridge solarforecast:fs-site:VorhersageStandort "PV Vorhersage Standort" [
        location="51.15,10.45"
    ] {
         Thing fs-plane VorhersageString1 "PV Vorhersage String 1" [
            refreshInterval=60,
            azimuth=5,
            declination=35,
            kwp=9.9
        ]
    }

[protectivedad]

Thanks for taking the time. I looked all over and searched and searched. In your example I don’t see the “property” type vs a “parameter”. The parameters are obvious and mentioned in documentation everywhere. But I haven’t found any mention of setting a “property” in the .thing file. I tried putting something like ianaTimeZone="America/Someplace" for example but it doesn’t show up in the properties list in the thing. This is what it looks like for a discovered thing:

When I use

Bridge honeywell:oauth20:openhab "Honeywell API Bridge" [ consumerKey="redacted", consumerSecret="redacted", optimized="false", refresh="90" ] {
        Bridge thermostat LCC-112233445566-test "Family Room Thermostat" [
                locationId="3268813",
                deviceId="LCC-112233445566",
                ianaTimeZone="America/Someplace" ]
}

It doesn’t show up:

[mstormi (Markus Storm)]

Yeah if the binding author didn’t document that, you’re out of luck.
You could try to scan the java source code for a hint or open a GitHub issue, but other than that your best bet is to move to managed (UI based) configuration.

[seime (Arne S)]

AFAIK thing configurations are Read/Write while thing properties are Read only.

You cannot edit thing properties, neither for file-based nor managed things.

The developer just need to add the necesary call to editThing and updateThing in the thing initialisation process (with the respective properties set). That is if the data is readily available and doesn’t require slow or multiple expensive IO calls to the bridge to do so, that would degrade overall init process for the device upon each startup.

Suggestion: Create a feature request on Github and put a bounty on it if it saves you a lot of time

[Udo_Hartmann]

What does the auto-generated code look like?

[Lolodomo]

Thing properties cannot be set in file based configuration. These properties are normally device properties that should be retrieved and set by the thing handler at handler initialisation. This is for example the device MAC address, the device firmware version, the device hardware version, …

[protectivedad]

Thanks for all the replies. As the developer, I’ll just document the limitation and move on. I was hoping I had missed a simple syntax that allowed properties to be initialized in text files. For now I will keep it simple and if someone has multiple homes with multiple time zones they will have to use the discovery process and not use a text .thing file.

[jimtng]

This is a bit of a problem, because we can’t set Thing’s representationProperty manually if that representationProperty is a property and not a configuration.

Example:

• amazonechocontrol: its representationProperty is a configuration, so this is fine. We can create a manual Thing (whether it’s by .things file, or in UI)
• lgwebos: its representationProperty is a property, not a configuration, so, AFAIK, we cannot manually create a Thing that would match up with the discovered Thing here.

In this case, I guess the binding developer needs to change it so it becomes a configuration.

[Mherwege (Mark Herwege)]

You could make this an advanced, not required, configuration parameter. If it is not set, the default will be used. That way it is something you can set in text configuration if needed.

[protectivedad]

It’s a decent idea. I just don’t like the idea of mangling a property as a parameter (or configuration), but it’s a small thing. Thanks. It’s also better than making it a channel.

[protectivedad]

It’s more interesting than I thought.

I decided to do what you suggested because all I needed to add was the definition in the config java/xml. That made me think about the core itself. The creation mechanism for things from the discovery process handles a property differently then the creation mechanism for things from the text file. With the discovery stream using withProperty("myProperty","myPropertyValue") creates either a “property” or “parameter” depending on if “myProperty” exists in the config. With the text stream it just drops the property if it is not in the config.

I can see an argument for making these two streams consistent or even making them feed into the same thing creation mechanism so they are always consistent.