[somfytahoma] Use QuantityType to set channels linked to item of type Number with a dimension

[lolodomo]

As I already mentioned in another place, the binding defines channels for items of type Number with a dimension like for example Number:Temperature but these channels are set using a simple DecimalType without specifying any unit. A QuantityType should be used and the unit should be set.

Here are the list of channel types concerned:

1. luminance => Number:Illuminance - used only by the thing type lightsensor
2. current_temperature => Number:Temperature - used only by the thing type heatingsystem
3. humidity => Number:Dimensionless - used only by the thing type humiditysensor
4. target_temperature => Number:Temperature - used by the thing types heatingsystem, thermostat and valveheatingsystem
5. temperature => Number:Temperature - used by the thing types temperaturesensor, thermostat and valveheatingsystem
6. energy_consumption => Number:Energy - used only by the thing type electricitysensor

@octa22 are the units adjustable somewhere for the Tahoma system ? Or are there fixed and the API can only return one unit for a particular state ?
Could you provide the unit used by the API for each API state used to set these 6 channels ?
We could then use a QuantityType to set the channel value rather than a DecimalType.

Could you identity too for which one the API is providing a device attribute core:MeasuredValueType defining the unit of the state ? I agree with you that it is apparently not always present but I see it for example for the temperature sensor (5th channel in my list) and the energy consumption sensor (6th channel in my list). This could be used at least when present.

[lolodomo]

Considering the attribute name core:MeasuredValueType, this may be present only for measurements (temperature, humidity, energy, luminance) and not for targer temperature.

[octa22]

Units are automatically converted to OH ones. This does the parseTahomaState method within the SomfyTahomaBaseThingHandler class. The problem is, that Tahoma TYPE_DECIMAL gets automatically converted to OH2 DecimalType for now. There is no distinguishing between QuantityType and other types as requested.

Regarding your question about core:MeasuredValueType, my things do not provide this extra infomation. I guess the olny API call which should return it, is the calling of the getSetup method in the SomfyTahomaBaseThingHandler class, which returns the clients overview of his installation. Of course the model must be extended so the attributes are taken into account when available.

[octa22]

The automatic type conversion might be extended by checking the acceptedState even if TYPE_DECIMAL should be converted so it can take QuantityType into account. Of course the method must be extended so the unit is provided as well.

[lolodomo]

Units are automatically converted to OH ones. This does the parseTahomaState method within the SomfyTahomaBaseThingHandler class. The problem is, that Tahoma TYPE_DECIMAL gets automatically converted to OH2 DecimalType for now. There is no distinguishing between QuantityType and other types as requested.

That is exactly what I would like to fix.
I just need to know what units are used by the Tahoma API for these states:

• core:LuminanceState
• core:RelativeHumidityState
• core:TemperatureState
• core:ElectricEnergyConsumptionState
• core:TargetTemperatureState
• core:TargetRoomTemperatureState
• core:DerogatedTargetTemperatureState
• zwave:SetPointHeatingValueState

[lolodomo]

The automatic type conversion might be extended by checking the acceptedState even if TYPE_DECIMAL should be converted so it can take QuantityType into account. Of course the method must be extended so the unit is provided as well.

Yes, that is the idea.
We just need to know the unit for few API states.

[lolodomo]

Can I assume that all temperature states and target temperature states are in Celcius, humidity state in %, energy state in Wh and luminance state in ???

[lolodomo]

Regarding your question about core:MeasuredValueType, my things do not provide this extra infomation. I guess the olny API call which should return it, is the calling of the getSetup method in the SomfyTahomaBaseThingHandler class, which returns the clients overview of his installation.

Yes, I see that information when "getSetup" HTTP call is executed.

[octa22]

Can I assume that all temperature states and target temperature states are in Celcius, humidity state in %, energy state in Wh and luminance state in ???

Luminance is returned in luxes (Lux), energy state might be either in Watts (W) - the actual power consumption or in WattHours (Wh) - the total power consumption.
I found a getSetup response from one user having a LuminanceSensor and the measured value type is: "core:LuminanceInLux"
A HumiditySensor returns type "core:RelativeValueInPercentage"
A TemperatureSensor return type "core:TemperatureInCelcius"

[octa22]

I have reverse engineered all the values from Tahoma they are here:
`
{
"units":{
"core:TemperatureInCelcius":"°C",
"core:TemperatureInCelsius":"°C",
"core:TemperatureInKelvin":"K",
"core:TemperatureInFahrenheit":"°F",
"core:LuminanceInLux":"lux",
"core:ElectricCurrentInAmpere":"A",
"core:VoltageInVolt":"V",
"core:ElectricalEnergyInWh":"Wh",
"core:ElectricalEnergyInKWh":"kWh",
"core:ElectricalEnergyInMWh":"MWh",
"core:ElectricalPowerInW":"W",
"core:ElectricalPowerInKW":"kW",
"core:ElectricalPowerInMW":"MW",
"core:FlowInMeterCubePerHour":"m³",
"core:LinearSpeedInMeterPerSecond":"m/s",
"core:RelativeValueInPercentage":"%",
"core:VolumeInCubicMeter":"m³",
"core:VolumeInLiter":"l",
"core:FossilEnergyInWh":"Wh",
"core:FossilEnergyInKWh":"kWh",
"core:FossilEnergyInMWh":"MWh",
"meters_seconds":"m/s"
}
}
``

[lolodomo]

I implemented something working well for the device sensors.
For the target temperature of heating systems, we have to decide what to do as there is no specific attribute mentioning the API unit on the API device. Either the API is always working with degree Celsius and we can set this unit as default unit. Or we decide to replace Number:Temperature by Number for these particular channels.

[octa22]

I would go for the first option - set the degree Celsius as default.