Closed flcu closed 3 years ago
It may be helpful to have a overview about which sensors to support and how they are connected (1-wire, i2c, proprietary, etc). The next question is, whether we choose the sensor during compile time or selecting one during runtime. I don't expect that you will have more than one sensor at the same time connected, right? Or might there be such a scenario?
There's quite a few of these types of sensors, they all differ either in features (Temp and/or humidity), precision and interface (and price...).
I don't think there's much value in connecting more than one offering the same features. What could make sense is to either use a combined temp/humid sensor or two separate sensors for that (?) or only a single one. But maybe I'm overthinking it.
Interface-wise I've seen "proprietary onewire" (dhtX), "real 1-wire" (ds1820), and i2c (sht3x). The only protocol that needs maybe a bit more consideration is i2c as the bus could be used by other plugins and devices as well (I could think of other display drivers or maybe some other sensors) and should be properly and maybe centrally initialized and protected from concurrent access(?).
Happy to discuss...
I've pushed my #IFDEF based version into my PluginDevelopment branch if you want to have a look at it. I don't like it, but it works...
There's quite a few of these types of sensors, they all differ either in features (Temp and/or humidity), precision and interface (and price...).
I don't think there's much value in connecting more than one offering the same features. What could make sense is to either use a combined temp/humid sensor or two separate sensors for that (?) or only a single one. But maybe I'm overthinking it.
Interface-wise I've seen "proprietary onewire" (dhtX), "real 1-wire" (ds1820), and i2c (sht3x). The only protocol that needs maybe a bit more consideration is i2c as the bus could be used by other plugins and devices as well (I could think of other display drivers or maybe some other sensors) and should be properly and maybe centrally initialized and protected from concurrent access(?).
Shortly discussed today with @0ooYoo0 about. The current idea may be to have a plugin, which just shows data from a sensor, including the unit. The plugin could stay generic this way. Additional add something like a "sensor data provider", with a generic interface, where you can select a sensor, get its kind of data, unit, precision, value, etc. Every instance of the plugin can be configured to show dedicated sensor data.
Just a rough idea right now.
I've pushed my #IFDEF based version into my PluginDevelopment branch if you want to have a look at it.
I tried to have a look ... but somehow I couldn't find it. Your PluginDevelopment branch is even with my PluginDevelopment branch.
@flcu Could you test the latest changes with your DHT11 sensor?
@flcu Now with the latest, please test your SHT3x sensor too. :-)
Hi Great! Sorry for being so quit - I enjoyed a few days off. I'll try it out in the next few days and provide you with feedback! Thank you very much
Issue to track the SHT3x sensor implementation.
I was also thinking about extending the TempHumid plugin to support temperature-only sensors - what's your opinion on that (eg ds1820)