@Damme
Hi,
The node might handle the ID itself?
I used the reference on the top of this page: http://www.mysensors.org/build/sensor_api
What i'm trying to put in the example is for a S_TYPE to supply multiple V_TYPE'S and the possibility to have the same V_TYPES based on fixed positions defined by the example char array. Just because the current setup is working with S_TYPES and V_TYPES.
I have not thought about multiple S_TYPE's of the same kind... good point..... But would this not just send multiple presentations like:
gw.sendSensorPresentation(ID1, S_DOOR);
gw.sendSensorPresentation(ID2, S_MOTION);
Or am i wrong... ?
I agree absolutely with what your saying and that everything that can be done with data handling like the metrics and grouping etc. should be done on the controller.
The current setup where there is just one group level is from what i think quite clever, of course on controller side it can be discarded, but it gives a nice multiple single purpose, multi sensor setup. An example with S_TYPE "Door":
With the possibility to announce in advance what kind of V_TYPES it can send, lets say: V_LOCK_STATUS at position 0 in the char array and V_OPEN_STATUS at position 1 in the char array (just made up). With the possibility to announce in this way it is possible to auto create this "door" device and will of course be a one time request.
When handling the V_LOCK_STATUS data on controller side when mysensors would send, as current is the case, the V_LOCK_STATUS it can send the array position of this V_LOCK_STATUS. Because the controller knows in advance that position 0 is V_LOCK_STATUS it can bound to that.
Yes it does complicate stuff more on controller side, in my case it would be a simple extra mapping. On the hardware side it would require the programmer to keep track of it's V_TYPE's position.
The driver i'm currently writing does not care how a "device" is defined. It can handle a sensor node as a device where the S_TYPES are groups which can contain multiple V_TYPES. Or it can create a "device" based on the S_TYPE which contains the V_TYPES. My example builds further on @hek 's example, which would give me the opportunity and i think also others to automatically create multi-V_TYPE S_TYPE groups.
Me myself is using the sketchname for keeping track of what type of node (sensor group in your view) it is. But this could be sensor ID0 reserved for this. Everyone is free to program whatever they want! You dont even have to use V_TYPE.. You could use this as an adress as well, so you can actually address 256x256 sensors on every node..
Today you could even present every ID with a S_TYPE (id 1+2+3+4 = S_WEATHER) and then just send data with ID and V_TYPE.. Let the controller keep track of eveything, this will pose a problem for me tough in my MQTT broker. I dont have the space of storing this type of data. So I'll be might start publishing the Presentation data, This data is just discarded of today. But because I know people using stuff are full of ideas they will work around this problem.
With my example I tried to keep the current multi table setup in honor and it currently is the default way to build the sensor network. I think @hek 's example does help to advance the MySensors protocol. And at the moment people are inventing their own idea's with code modifications and change the protocol data position definitions, in which of course they are free to do, they break the default compatibility.
P.S.
I also think this thread could better me renamed to "Advancing MySensors" then "Generalizing MySensors" because it is so extremely difficult or even impossible to generalize at this current moment with all those hundreds of protocols, data- and sensor definitions used. Also with MQTT there is no generalization because everyone is free to create their own hierarchy.
But, eventually, i will be fine with any implementation, as long is i know about it :).
