Yoric
commented
8 years ago Indeed, Decentralized Taxonomy will introduce something along these lines. See here for a high-level overview of Decentralized Taxonomy. Will this provide what you need, @dhylands ?
Side-note: indeed, the enums are not for the adapters, they are for everything that uses the adapters (at the moment, the REST API, Thinkerbell).
dhylands
Following up on our discussion about FanOn, LightOn, etc.
I think it might be useful to be able to get at the FanOn/LightOn On/Off stuff as strings rather than as rust enums.
It sounds like we're going to wind up having many aliases for the same thing, which from the adapters point of view are all 100% identical. This means having a bunch of duplicated code in the adapter.
I'd rather have a file, or something which lists all of the strings which are actually aliases for one another and write the code once, and just append new aliases as they become available.
There isn't any place in my adapters where the enums are actually used in any kind of enum-meaningful way. The adapter basically has to translate each of the things which means on to true and off to false (or perhaps the inverse), so that it can send true/false to the device.
Also, for the zwave adapter, it will need to translate in both directions, since it will need to store some type of persistent mapping. For example, zwave knows that say Node 2 is a BinarySwitch. If the user has assigned that Node 2 controls a fan, and wishes to use FanOn, FanOff commands, then we need to persist that information someplace so that we can present Node 2 as a Fan in the getters & setters. So we're going to wind up having to persist the fact that its a Fan with FanOn/FanOff using strings as well, as well as adding getters and setters which allow the kind/type to changed.