Reason for all the different sensor-types (but same datatypes)?
Hi, i am a new but very excited user of the mysensors-library and i am not a native english-speaker. I hope you understand what i am trying to ask and tell.
There is one thing, i dont understand why it was made this way:
There are a lot of sensor-types, but all of them only consist of only some different datatypes: bool, float, integer (...) Wouldnt it be easier to create a general "sensor-type" instead of creating a lot of different sensors?
My idea is to make something like a "constructor" for a sensor i want to use. In this constructor i define the datatype, the name, and additional (standardized) parameters like:
- arm- / disarmable
- min / max-value
- other "read" and writeable values...
In this way i can "build" my sensor-type as i need it. For example i can create a sensor, which reports batterylevel as integer or as float - or just as boolean (batt-ok-value). I can define a "setable" min-value (or max) and so on... The battlevel-feature included today only allows percent-values. This is a bit a limitation, i think...
It is main reason for the current datatypes is historic. If we would redo things from scratch it would probably look much different.
Here is an embryo I did way back on a future OTA protocol.
These types of changes will affect/break controller plugins, so we cannot do them just for fun.
It will be much easier to support different protocols soon (using the same codebase) this opens up for changes more easily.
thats a LOT of text - wow. but very interesting (didnt read everything until now).
Is there a topic or discussion ongoing on this?
Maybe it can be redone with "mysensors 2.0" (in parallel to 1.5)..
I will make a deep-dive into the source code now. Its too interesting and i like this kind of coding
At last: Sry that i opened another topic for this question. looks like i didnt use the right words in the search