On 27 Feb 2015, at 08:03, Kai Kreuzer <notifications@github.com> wrote:

Quote:

but I also fear this can become a maintenance nightmare and we'll end up trying to support a 'database' of devices

Isn't this what you have done with Z-Wave as well?

And again: Yes, the idea of the ThingTypes is that they reflect a certain product/model. This is what you will find in most other bindings as well and I think all bindings should follow the same guidelines.

Quote:

can bindings add their own information into the XML files for device specific stuff?

Do you have a concrete example?

err.... did I miss something here but how would this differ/compare to the <parameter> in <config-description> ?

1. Regarding the original question: I think Z-Wave won't be the only binding to have some custom content in XML, so it imho makes sense to allow such custom sections within the thing XMLs. I so far only briefly discussed this with Dennis, but he felt it should be somehow feasible to do with the current XML parser and thing provider. We will still need to find a way to do it, though.

2. I am also concerned about the number of XMLs we have to parse in the end. So if this can be avoided at startup and we rather maintain an index (maybe this could even be done dynamically?), this might be a good thing in general and not just for Z-Wave. What information would be required in such an index? Only the list of available thing types?

	</manufacturer>
		<!-- FDG211: Dimmer -->
		<product>
			<reference type="0100" id="0104"></reference>
			<reference type="0100" id="0106"></reference>
			<reference type="0100" id="0107"></reference>
			<reference type="0100" id="0109"></reference>
			<reference type="0100" id="100A"></reference>
			<reference type="0100" id="300A"></reference>

			<uid versionMax="1.8">fibaro_fgd211_14</uid>					<!-- VersionMin="1.4" -->
			<uid versionMin="1.9" versionMax="1.11">fibaro_fgd211_19</uid>
			<uid versionMin="2.1">fibaro_fgd211_21</uid>					<!-- VersionMax="2.3" -->
		</product>
	</manufacturer>

3. Yes, there had been a few PRs in the last weeks around thing types. But they were merely about adding "properties" as a flat list to things - this is nothing that will really help you any further, I guess.

4. Parameter grouping: No, this is not planned and I am not sure, if it makes sense. It rather looks as if these parameter groups are relevant for certain channels or channel-groups - hence I would rather look into adding parameters to those (which has been the idea from the start, it just hasn't been implemented out in detail).

5. write-only functionality: Would you consider these to be device configuration (=parameters) or functionality (=channels)? If they are channels, I think this would simply be a channel that only accepts commands, but which simply keeps the state as undefined. Would that work?

a) Let bindings implement their custom parser, which can be helped with by exposing the internals of the current parser. This might result in many incompatible XML schemas and different places to put the files, i.e. the idea of having a common approach would suffer a lot

b) Add a generic element to the schema, which allows a storing additional information. It is not clear to me where we could add that best and how the information would be mapped to the Java model. Having a Map<String,String> in the result is probably not enough as it does not provide any structure (and is thus similar to using the Thing properties).

c) Include structured data within the XML, e.g. a CDATA section where anything could be put - e.g. another custom XML or JSON structure. This would be made available as a String and could be parsed by the binding individually. The downside of this is that the data is not interlinked with the other information in the

buildThingReader.addChannelExtension(aClass).addThingExtension(anotherClass).build();

So the question is what data needs to be in such an index and how the link to certain files is done (actually the content might not even be in a file, but being constructed by a dynamic ThingTypeProvider). Would an index entry per thing type be enough? Or would you also see the need for more detailed information like "thing-type=z-wave-motion, vendor=fibaro, fw=1.23"? It seems that your current z-wave index is very detailed, but probably because you have as many thing types available (as every device has a different structure).

<a-group>
 <a-property name="class">A<a-property/>
 <a-property name="endpoint">B<a-property/>
 <a-property name="cmd">C<a-property/>
</a-group>

Something like...
I'd be happy to look at implementing this if you agree...