Add and rearrange datapoints
bertmelis opened this issue · 2 comments
see PR #8
Idea is to create a number of base DPs and subDPs. Whenever there are subDPs, the base is an abstract one.
TempBase --> TempDP (2-byte / 10) and TempSDP (1-byte)
CountBase --> (have to make the inventory)
ModeDP (no subDPs?)
...
To do:
-
move conversions to seperate classes which can be attached to datapoint objects (see link)
-
idea: return a (tagged) union from VitoWifi to reduce the number of callback types --> callbacks will be in the form of
void callback(Datapoint& dp, DPValue& value)whereDPValueis a union (or struct) which holds the value in the most appropriate type eg. a temperature in a float/int/uint, mode in a uint, status in a bool... -
add a datapoint manager (Factory pattern but with with a switch, see this link) and remove it from the VitoWifiClass
-
add a 'raw' datapoint that returns a byte array to be able to do conversions yourself (and make the sniffer example as in #32
-
other ideas?
Question: now all different datapoints have a somewhat meaningful name. Should I keep this or let it go? A more types will be added, it can become hard to maintain.
-
move conversions to seperate classes which can be attached to datapoint objects (see link)
-
idea: return a (tagged) union from VitoWifi to reduce the number of callback types --> callbacks will be in the form of void callback(Datapoint& dp, DPValue~~&~~ value) where DPValue is a union (or struct) which holds the value in the most appropriate type eg. a temperature in a float/int/uint, mode in a uint, status in a bool...
-
add a datapoint manager (Factory pattern but with with a switch, see this link) and remove it from the VitoWifiClass
-
add a 'raw' datapoint that returns a byte array to be able to do conversions yourself (and make the sniffer example as in #32
New things or issues to implement before a version 1 can be released? I'm not thinking of new datapoint types. These can and will always be added on request.