thing upgrades: missing support to add/change/remove channel properties

[alexf2015]

I am using channel properties and as part of a change I also need to add some properties as part of a migration. See #14866 for details. Changing channel type worked fine for me but this is only a part of the migration. Please add support for this.

[J-N-K]

Channels don't have properties:

    <xs:complexType name="channelType">
        <xs:sequence>
            <xs:element name="item-type" type="xs:string" minOccurs="0"/>
            <xs:element name="kind" type="xs:string" minOccurs="0"/>
            <xs:element name="label" type="xs:string"/>
            <xs:element name="description" type="xs:string" minOccurs="0"/>
            <xs:element name="category" type="xs:string" minOccurs="0"/>
            <xs:element name="tags" type="thing-description:tags" minOccurs="0"/>
            <xs:element name="state" type="thing-description:state" minOccurs="0"/>
            <xs:element name="command" type="thing-description:command" minOccurs="0"/>
            <xs:element name="event" type="thing-description:event" minOccurs="0"/>
            <xs:element name="autoUpdatePolicy" type="thing-description:auto-update-policy" minOccurs="0"/>
            <xs:choice minOccurs="0">
                <xs:element name="config-description" type="config-description:configDescription"/>
                <xs:element name="config-description-ref" type="config-description:configDescriptionRef"/>
            </xs:choice>
        </xs:sequence>
        <xs:attribute name="id" type="config-description:idRestrictionPattern" use="required"/>
        <xs:attribute name="advanced" type="xs:boolean" default="false" use="optional"/>
        <xs:attribute name="system" type="xs:boolean" default="false" use="optional"/>
    </xs:complexType>

[lolodomo]

Please update the issue title as it does not concern the upgradetool.

[J-N-K]

As I already said: I would vote for won't fix because properties are not part of channel-types.

[lolodomo]

I was also a little surprised to discover properties on channel types.
Properties are for thing types.
On channel type, you can have configuration parameters.
I would be curious how many bindings defined properties on channel types. But not easy to check with a simple grep.

[J-N-K]

If SAT works ad designed it should trigger a SAT warning that the XML is invalid. The interesting thing is that the Channel class defines properties, that's why it works.

[lolodomo]

Yes, and in fact @alexf2015 defined properties on channels, not channel types:

		<channels>
			<channel id="lockCablePermanently" typeId="rwtype-switch">
				<label>Lock Cable Permanently</label>
				<description>Lock Cable Permanently status of the wallbox.</description>
				<properties>
					<property name="writeCommand">ChangeConfiguration</property>
					<property name="validationExpression">.*</property>
				</properties>
			</channel>

When updating such channel, the properties are apparently lost, that is the object of the issue.

[jlaur]

So this is the relevant part of the XSD (declaring properties for a channel):

<xs:complexType name="channel">
    <xs:sequence>
        <xs:element name="label" type="xs:string" minOccurs="0"/>
        <xs:element name="description" type="xs:string" minOccurs="0"/>
        <xs:element name="properties" type="thing-description:properties" minOccurs="0"/>
        <xs:element name="autoUpdatePolicy" type="thing-description:auto-update-policy" minOccurs="0"/>
    </xs:sequence>
    <xs:attribute name="id" type="config-description:idRestrictionPattern" use="required"/>
    <xs:attribute name="typeId" type="thing-description:namespaceIdRestrictionPattern" use="required"/>
</xs:complexType>

[lolodomo]

That means when updating a channel, there are some data to keep (label, description, properties, autoUpdatePolicy) to reuse them when inserting the new channel from the channel type ... if they were present.
I believe this is in fact a very similar issue as the one for label discussed in the other issue.

[alexf2015]

I do not think that #3612 will fix my issue. I wanted to add two properties as part of the migration. If I understand #3612 correctly this will only nsure that already existing properties will not get lost during the update.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/come-back-and-learn-how-to-use-file-based-configuration/147067/15