Feature newxmlformat

[speters]

Experiment

(only for discussion)

I did some experiments on how to solve the problems with the current xml config format.

• commands/addresses are separated from the set of features/possible commands of a device (see #15)
• the format makes use of the already existing xi:include file inclusion scheme to break down the config into manageable pieces and to separate general config (commands) from local config (ports, device types, ...). commands.xml devices.xml protocols.xml units_devicetype.xml units.xml

Devices would be defined with a list of commands the support. Commands can get an alias name, so that internally different commands/addresses could be called by the same name:

<?xml version="1.0"?>
<devices>
  <device ID="2098" name="V200KW2" protocol="KW2"/>
  <device ID="2053" name="GWG_VBEM" protocol="GWG">
    <command alias="getTempA" name="getTempAGWG" />
  </device>
  <device ID="20CB" name="VScotHO1" protocol="P300">
    <command alias="getTemp" name="getTempA" />
    <command name="getDevType" />
...
    <command name="getDevID" alias="getid" />
  </device>
</devices>

I must admit that I still do not like the config structure too much. Particularly the separation of get and set commands is unneccessarily blowing up the size of the xml files.

[philverh]

Looks interesting, as it clarifies the contents and usage of the different xml files. About the get and set commands blowing up the size of the commands.xml file, I thought about the following: Instead of having two command blocks for each R/W command, such as

<command name="getTempPartyM1" protocmd="getaddr">
      <addr>2308</addr>
      <len>1</len>
      <unit>ST</unit>
      <description>Solltemperatur Partybetrieb M1</description>
      <device ID="2053"/>
    </command>
    <command name="setTempPartyM1" protocmd="setaddr">
      <addr>2308</addr>
      <len>1</len>
      <unit>ST</unit>
      <description>Setze die Warmwassersolltemperatur Party M1 in Grad C</description>
      <device ID="2053"/>
    </command>

we could change the xml input file to something like

<command name="TempPartyM1" mode="rw">
      <addr>2308</addr>
      <len>1</len>
      <unit>ST</unit>
      <description_r>Solltemperatur Partybetrieb M1</description_r>
      <description_w>Setze die Warmwassersolltemperatur Party M1 in Grad C</description_w>
      <device ID="2053"/>
    </command>

and generate two sets of commands in the table, with the prefixes GET{name} and SET{name} while parsing the above. I left the two descriptions in the example above, but we could also agree to only use one. For read-only commands I would use mode="r", and obviously only generate one entry in the command table with the get{name} entry. From what I could see (and I only looked into the commands for the device I have installed) the read and write addresses are always identical. In case there would be different addresses for write for some devices/commands, a third mode="w" could be foreseen in the code.

Now of course this also impacts the alias feature you added.

Food for thought.

[Morg42]

Maybe this could take an even different approach. I'm thinking of

• combining get/set as per idea from philverh
• using generic data point descriptors as a basis for aliases
• combining these with device-specific files which assign the address and a generic datapoint to an alias

for example

datapoints.xml:

<datapoint name="_TempPartyM1" mode="rw">
    <len>1</len>
    <unit>ST</unit>
    <description>Solltemperatur Partybetrieb M1</description>
</datapoint>
<datapoint name="_TempA" mode="r">
    <len>1</len>
    <unit>ST</unit>
    <description>Außentemperatur</description>
</datapoint>

devices.xml (or multiple files, each with one or more devices)

<device id="204D" name="V200WO1C">
    <alias name="TempPartyM1">
        <address>2022</address>
        <datapoint>_TempPartyM1</datapoint>
    </alias>
    <alias name="TempA">
        <address>01C1</address>
        <datapoint>_TempA</datapoint>
    </alias>
</device>

<device id="2053" name="...">
    <alias name="TempPartyM1">
        <address>2308</address>
        <datapoint>_TempPartyM1</datapoint>
    </alias>
    <alias name="TempA">
        <address>01C1</address>
        <datapoint>_TempA</datapoint>
    </alias>
</device>

As far as I see it, this has some advantages:

• generic datapoint/function definition, device independent
• discrete device definitions, possibly with local adjustments, exchangeable
• rather clean configuration
• no doublings for get/set
• everyone can improve / contribute single device configurations, no need to tamper with datapoints.xml

It is prone to have some disadvantages:

• datapoints.xml might get extensive, if the function differs between devices (only if a 100% description is absolutely needed, there might be room for interpretation)
• proper and correct protocol definitions needed (not covered in example)
• used units e.g. for TempA or TempPartyM1 need to be consistent over all devices (else override with setting in devices.xml possible?)

This reflects the idea I had some time ago about creating/maintaining a database of all data points in an open and accessible format, possibly with vcontrold-conformant format export. Sadly, that one got no further responses.

Maybe this could join the efforts.

[speters]

stale --> closed