Closed speters closed 1 year ago
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.
Maybe this could take an even different approach. I'm thinking of
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:
It is prone to have some disadvantages:
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.
stale --> closed
Experiment
(only for discussion)
I did some experiments on how to solve the problems with the current xml config format.
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:
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.