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...
Greetings
Andreas
-
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...
Greetings
Andreas
@ahhk If you are ready for some reading.... there were a few discussions on the subject already..
-
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.
https://github.com/henrikekblad/Arduino/blob/old-development/libraries/MySensors/MyMessage.hThese 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.
-
Hi,
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 :/
Greetings
