Closed RobTillaart closed 4 years ago
why is this still open? Is this something you are wanting to add?
It is open as it is an idea that might be useful for some at the price of RAM. I do not want to add it now.
Needs more investigation in the pro and con arguments. Technically it looks like a no brainer and could be implemented in 10 minutes but the added value and its price are not clear yet.
Moreover there are other less trivial solutions for this problem that are better in the long term. These need my investigation.
It is labelled as an enhancement so no prio. Maybe it needs a label "to investigate"
Note: The length needed to have a good descriptive name depends on the language used. 8-10 bytes seems to be a practical minimum (remember DOS), but up to 25(?) bytes might be needed to allow a good descriptive name.
Note: If sensors have an unique DESCRIPTION_ID and it is short e.g 1 byte, then it could be used as an index for a lookup table with the actual strings. This would make it usable over all sensor libraries.
Initial though is to use 1 byte as that should be enough for most applications For I2C devices the I2C address might be used (assume no multiplexing)
For more complex or distributed applications one might need a more complex naming scheme. That would give a lot of overhead
Maybe 2 bytes are a good middle, reserving some values or bits for special cases / future e.g FFFFBBBB DDDDDDDD F = future B = bus ID (16 busses could be sufficient D = description id (250 id's per bus, id 0xFF could be bus description
more thinking needed.
Won't implement a sensor identification schema on short term.
An descriptive name into the sensor so I can set
an 8 byte string or progmem would make loops over multiple sensors easier (no parallel array of strings).
Drawback memory usage.