RobTillaart / DHTNew

Arduino library for DHT11 and DHT22 with automatic sensor recognition
MIT License
99 stars 15 forks source link

Adding name tag to sensor #2

Closed RobTillaart closed 4 years ago

RobTillaart commented 4 years ago

An descriptive name into the sensor so I can set

DHTNEW s(4);
kitchen.setName("kitchen");   // or PROGMEM ?
...
Serial.println( s.name);

an 8 byte string or progmem would make loops over multiple sensors easier (no parallel array of strings).

Drawback memory usage.

Mr-HaleYa commented 4 years ago

why is this still open? Is this something you are wanting to add?

RobTillaart commented 4 years ago

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"

RobTillaart commented 4 years ago

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.

  1. Does this mean dynamic memory? could be,
  2. Does this mean PROGMEM? not all platforms support this.
RobTillaart commented 4 years ago

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.

RobTillaart commented 4 years ago

Won't implement a sensor identification schema on short term.