Doubts about sensor types versus variable types

[marcusvdt]

I'm building a self made controller in python that will integrate in another automation software. It's like a plugin for such software.

It is working already but I'm now looking for enhancing the controller and have it conforming to standard MySensors protocol so it can be easily updated when new versions of the API are released.

Regarding sensor types, I'm assuming they exist so each sensor type can have one or more variable types related to it. As mentioned in the API page, power meters could report both the accumulated KWH and the current WATTAGE. Hence the controller should be able to know how it will show the received information for the user by looking on the variable type reported by the sensor.
So, a S_LIGHT sensor will have the variable type V_LIGHT assigned to it, which means it can receive light status 0=off or 1=on, and whatever these values are received or sent to/from a node, for the end user these values should be displayed simply as ON or OFF.

If I'm correct above, I'd like to build a table of what specific data types are expected for each of various types of variables documented on the API.
For example, for the S_RAIN sensor, I suppose it expects both the V_RAIN and the V_RAINRATE values, but as for the controller side, how is it supposed to deal with each value? Is the V_RAIN a float number? In which unity of measure should it be displayed for the user? Is the V_RAINRATE a float number? Is it a percentage value?

I also would like to know if there is a list somewhere relating the sensor types with each variable type they are supposed to be related to. Something like:
S_LIGHT = V_LIGHT
S_RAIN = V_RAIN, V_RAINRATE
etc

Then I would have another table relating each variable type with the type of data it is, something like:

Variable valid values table
data_types	|	Valid_value	|	Setting		|	Display
============|===============|===============|==================
V_LIGHT		|	0			|	OFF			|	turned on
V_LIGHT		|	1			|	ON			|	turned off
V_RAIN		|	FLOAT		|	Not appl.	|	inches

[hek]

There are some comments in the development branch that might help you:

https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/MyMessage.h

[marcusvdt]

Thanks, it helps a lot!
But I still wanted to have a clear definition of some of the variable types.
The major concern is, if V_LIGHT is supposed to read a binary value of 0 or 1, then my controller should support it correctly. I'm using it this way, but then I saw in the comments from the link you just sent this:
V_LIGHT, // S_LIGHT (Light level in uncalibrated percentage)

This conflicts with what is posted on the variable types page:
V_LIGHT Light status. 0=off 1=on

I'm supposing there is no such documentation yet, or the subject is not cleared defined in the API. That's ok if not, I know you guys give your best and I'm very grateful for having this stuff available for free. I mean, I'm not complaining.
I just want to make sure I'm developing a controller which conforms with the standard API, hence the need to clarify this. If the controller is supposed to read a binary value for V_LIGHT, then it will be programmed for that. If it is supposed to read a percentage, the same.

Can you guys help me? Maybe if I post a table with my guesses for each variable type, you can confirm/correct?

[hek]

Sorry, you are right there was some errors in the comments. Pushed an update. Please have a look again and get back to me if there still is any ambiguities.

[Heinz]

I think that the value types could be recuced to a minimum by declaring the number format instead of repeating the sensor type in the variable type
V_NUM, V_BOOL, V_PERCENTAGE, V_STRING, ...

V_NUM or V_FLOAT would fit to many values sent by the sensors.
The order of different sensor values is a contract between the controller and the sensor anyway. The same goes for the units of the values. The controller must know if the values sent by a distance sensor is mm or cm.

So why are there dozens of variable types? It looks like a bit over-engineered to me?

[hek]

Yep, been discussed here on the forum for a while. There will eventually be a 2.0 version of the protocol but it will effectively break all backward compatibility of the current controller-plugins. So the two versions will probably live for a long time in parallell.

Started drafting it some months ago...
https://github.com/henrikekblad/Arduino/blob/development/libraries/MySensors/MyMessage.h
But other tasks has blocket the 2.0 version.

The main reason for the current variable-types has a Vera-controller legacy. It is simply 1-1 mapping to their devices/variables.

[marcusvdt]

@hek [quote]The main reason for the current variable-types has a Vera-controller legacy. It is simply 1-1 mapping to their devices/variables.[/quote]
I was knocking my head to the wall to understand why you guys have done this that way.
What I'm doing on my controller is to create database tables that will group and relate those variable types to what should be displayed on the user interface.

Thanks for the help.
I think I can go ahead, but some sensor types are still not clear to me.

@Heinz
This is what I thought since I started looking at this stuff.