You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If applicable, we should include information about the teach-in variant, support for ADT etc in the EEP.xml also. At least some profiles do include this information in the documentation, and thus it should be set in our version. At least multiple VLD profiles include this information.
Not sure if any of our current profiles define these, but the structure of EEP.xml should be revised to include these. Also, majority of this information could be done
The revised structure should include information about
data exchange
directions of communication, whether or not the device also listens to us...
addressing (mainly support for ADT?)
teach-in
method
variant
Maybe something like the following example, with support for multiple teach-ins, where the first one is preferred. The point of using a list would be to include the variations we have seen with real hardware, to make an educated guess for the correct variant.
<data>
...
</data>
<teachin>
<!-- number of devices is just a tally of devices we have actually observed to use the variation -> thus making it more likely canditate.-->
<varianttype="2"number_of_devices="4" />
<varianttype="1"number_of_devices="1" />
<!-- As for devices using UTE, the learn -message differs from the normal message, so teach-in could and should be left out?-->
</teachin>
<dataexchange>
<direction> <!-- only one should be applicable? -->
<unidirectional />
<bidirectional />
</direction>
<supports_adt /> <!-- included only, if ADT is supported, otherwise left out -->
</dataexchange>
The text was updated successfully, but these errors were encountered:
kipe
changed the title
Include teach-in variant in EEP
Include teach-in variants in EEP
Feb 18, 2016
kipe
changed the title
Include teach-in variants in EEP
Include additional information in EEP
Feb 18, 2016
I contacted the EnOcean Alliance and asked for some up-to-date EEPs.
On their website, they state the the XMLs are member only. But maybe they are open source friendly..
Lets see :)
Anyway, I would propose that we keep close to the official EEP XMLs and find another place for the additional fields.
If applicable, we should include information about the teach-in variant, support for
ADT
etc in theEEP.xml
also. At least some profiles do include this information in the documentation, and thus it should be set in our version. At least multipleVLD
profiles include this information.Not sure if any of our current profiles define these, but the structure of
EEP.xml
should be revised to include these. Also, majority of this information could be doneThe revised structure should include information about
Maybe something like the following example, with support for multiple teach-ins, where the first one is preferred. The point of using a list would be to include the variations we have seen with real hardware, to make an educated guess for the correct variant.
The text was updated successfully, but these errors were encountered: