Is there any way to determine a thermostat's temperature sensor?

[Neo Andersson 230]

Guys,
Anyone with any idea, how can we with 100% certanty deteremine what is the ID of a thermostat's temperature sensor???
There are possibilities when we have a linked device type thermostat, so whithin its "devices" property we can filter for the one with role temperatureSensor
But in case of others?? Like real zwave thermostatsdo  not expose anything like linked sensor, or temeprature sensor in their device's JSON
(Even worse is, when the device is a virtual thermostat )
For now i would be satisfied if i only could determine the sensor of a zwave thermostat somehow..
It is a bit strange for me, why API doesn't provide such an essential information..
Anyone any idea??

[m.roszak 763]

You got the structure of the Z-Wave device in hierarchy, Z-Wave temperature sensor will have the same parentID as the HVAC device.
Unfortunatelly even from ZW perspective it is not always clear on the protocol level, some thermostats has for example 2 sensors - one for room temperature, 2nd one for the floor probe.
On the device model/Z-Wave protocol there are no indications which is which, the only way is to check the device manual.

At least you can know from common parentID that those devices originates from the same phisical device. 

[Neo Andersson 230]

22 hours ago, m.roszak said:

You got the structure of the Z-Wave device in hierarchy, Z-Wave temperature sensor will have the same parentID as the HVAC device.
Unfortunatelly even from ZW perspective it is not always clear on the protocol level, some thermostats has for example 2 sensors - one for room temperature, 2nd one for the floor probe.
On the device model/Z-Wave protocol there are no indications which is which, the only way is to check the device manual.

At least you can know from common parentID that those devices originates from the same phisical device. 

 

---

Yes, this is exactly what we are doing at the moment.
However, there is another important issue related to linked thermostats.

1. Missing heating / cooling information for linked thermostats

For linked thermostats, a critical piece of information is missing. From the device’s JSON structure, we cannot determine which linked device is responsible for heating and which one is responsible for cooling.

This makes it very difficult to create reliable plugins. At the moment, we are forced to hard-code this information into our own tables. Ideally, heating and cooling devices should be clearly separated in the device JSON.

2. Missing thermostat demand information

Another very important issue is that, except for Fibaro radiators and physical wall thermostats, we generally do not know the real thermostat demand.

• Radiators expose heatRequired

• Wall thermostats expose thermostatOperatingState

• Linked thermostats expose neither

• Thermostat QuickApps also expose neither

Because of this, we have no reliable way to know whether heating or cooling is actually requested. This is one of the hardest problems we are facing.

Currently:

• For virtual thermostats, we manually compute and guess the demand

• For linked thermostats, we do the same

This is error-prone and unreliable.

Suggested improvement

From our perspective, this could be solved with a very small change on the Fibaro side, which would bring huge benefits.

We kindly ask you to consider the following enhancements:

1. Linked devices

   • Clearly separate heating and cooling devices in the device JSON structure

2. All thermostat-type devices (linked and QuickApps)

   • Add a thermostatOperatingState field to the device API structure

For linked thermostats, Fibaro can easily set this field based on the internal thermostat logic.
For thermostat QuickApps, this field would give us a standard property that we can update ourselves using our own calculations (setpoint + hysteresis).

---

Would you be so kind as to check whether these two improvements could be incorporated?

Thank you very much for your time and support.

 

Edited January 20 by Neo Andersson

[m.roszak 763]

41 minutes ago, Neo Andersson said:

1. Missing heating / cooling information for linked thermostats

If you create a Linked thermostat for heating it has a property supportedThermostatModes with "Off", "Heat" modes supported. So its a heating device.
In cooling one its the same, just supported modes are "Off" and "Cool".

 

 

41 minutes ago, Neo Andersson said:

Missing thermostat demand information

Our termostatic heads, yes - its a dedicated feature.
Wall termostats MAY support thermostatOperatingState depedning on the model, is related with the device itself - its a generic system feature but based on actual capabilties of the thermostats.
Linked thermostats - I will add a task for adding this feature as currently the only way is to compare setpoint and measured temperature directly or looking at the configured output actor state.

Quickapps - already doable, its not added by default to not enable something which may not be programmed by the users.
 

41 minutes ago, Neo Andersson said:

Linked devices

• Clearly separate heating and cooling devices in the device JSON structure

As described, already separated by supported modes property.
The HVAC systems model is like this and its combined for supporting more modes than one to not grow the number of entities in the system without the actual reason.

 

 

41 minutes ago, Neo Andersson said:

All thermostat-type devices (linked and QuickApps)

• Add a thermostatOperatingState field to the device API structure

As for the QuickApps, those can do it if you program them to do it - just add interface "thermostatOperatingState" which will bring the feature of most of the wall thermostats.
Available emums for property which will be added are:
enum ThermostatOperatingState {
  "Idle",
  "Heating",
  "Cooling",
  "FanOnly",
  "PendingHeat",
  "PendingCool",
  "VentOrEconomizer",
  "AuxHeating",
  "2ndStageHeating",
  "2ndStageCooling",
  "2ndStageAuxHeat",
  "3rdStageAuxHeat"
}

Regards,
Michał

[Neo Andersson 230]

11 minutes ago, m.roszak said:

If you create a Linked thermostat for heating it has a property supportedThermostatModes with "Off", "Heat" modes supported. So its a heating device.
In cooling one its the same, just supported modes are "Off" and "Cool".

 

 

Our termostatic heads, yes - its a dedicated feature.
Wall termostats MAY support thermostatOperatingState depedning on the model, is related with the device itself - its a generic system feature but based on actual capabilties of the thermostats.
Linked thermostats - I will add a task for adding this feature as currently the only way is to compare setpoint and measured temperature directly or looking at the configured output actor state.

Quickapps - already doable, its not added by default to not enable something which may not be programmed by the users.
 

As described, already separated by supported modes property.
The HVAC systems model is like this and its combined for supporting more modes than one to not grow the number of entities in the system without the actual reason.

 

 

As for the QuickApps, those can do it if you program them to do it - just add interface "thermostatOperatingState" which will bring the feature of most of the wall thermostats.
Available emums for property which will be added are:
enum ThermostatOperatingState {
  "Idle",
  "Heating",
  "Cooling",
  "FanOnly",
  "PendingHeat",
  "PendingCool",
  "VentOrEconomizer",
  "AuxHeating",
  "2ndStageHeating",
  "2ndStageCooling",
  "2ndStageAuxHeat",
  "3rdStageAuxHeat"
}

Regards,
Michał

Thanks for th answer Michal, but the problem is, linked Thermostat with heat, cool, auto , and off supported modes we are blind.
And as we dont know its real demand  /*as u wrote earlier we can determine by the actor state only/, yes an here is the thing We dont know from the code, which actor is for what, so we dont know
which heatpump, coolpump to turn on, off (user has cooling system in the floor, same as heating. He just changes the water source to cool or heat and we drive the heat/cool pumps) Many users have the same system here.
So we need to hardcode a table for thermostat -> heatVentils , coolVetnils etc, and the demand is calulcated from setpoint, and hysteresis

Thats its

thanks a lot
 

[Neo Andersson 230]

34 minutes ago, Neo Andersson said:

Thanks for th answer Michal, but the problem is, linked Thermostat with heat, cool, auto , and off supported modes we are blind.
And as we dont know its real demand  /*as u wrote earlier we can determine by the actor state only/, yes an here is the thing We dont know from the code, which actor is for what, so we dont know
which heatpump, coolpump to turn on, off (user has cooling system in the floor, same as heating. He just changes the water source to cool or heat and we drive the heat/cool pumps) Many users have the same system here.
So we need to hardcode a table for thermostat -> heatVentils , coolVetnils etc, and the demand is calulcated from setpoint, and hysteresis

Thats its

thanks a lot
 

@m.roszak Michal one last question. Can we use any interface, that would include into QA theromstat's device structure the heatingThermostatHysteresis and coolingThermostatHysteresis fields?
There is no hysteresis fields in the device's structure. It appeares only when its an auto type thermostats. (then it got autoHeatingThermostatHysteresis or something like that)
What interface could be added to have the hysteresis values??
Thanks

Edited January 20 by Neo Andersson

[m.roszak 763]

4 hours ago, Neo Andersson said:

Thanks for th answer Michal, but the problem is, linked Thermostat with heat, cool, auto , and off supported modes we are blind.
And as we dont know its real demand  /*as u wrote earlier we can determine by the actor state only/, yes an here is the thing We dont know from the code, which actor is for what, so we dont know
which heatpump, coolpump to turn on, off (user has cooling system in the floor, same as heating. He just changes the water source to cool or heat and we drive the heat/cool pumps) Many users have the same system here.
So we need to hardcode a table for thermostat -> heatVentils , coolVetnils etc, and the demand is calulcated from setpoint, and hysteresis

Thats its

thanks a lot
 

Understood, its already quoted by the team to support Heating, Cooling and Idle operating states for linked devices.
I hope we can get it pretty soon.

 

 

3 hours ago, Neo Andersson said:

@m.roszak Michal one last question. Can we use any interface, that would include into QA theromstat's device structure the heatingThermostatHysteresis and coolingThermostatHysteresis fields?
There is no hysteresis fields in the device's structure. It appeares only when its an auto type thermostats. (then it got autoHeatingThermostatHysteresis or something like that)
What interface could be added to have the hysteresis values??
Thanks

Histeresis control is something you need to program manually at this point, making this the system feature inside the QuickApps may cause issues in specifc cases (like integration with phisical thermostat which actually has the histeresis already supported natively). Its a native fuction of the linked thermostat, its not something you can just enable.
I will discuss it with the team, if there is a way to make it in the way that it will be usefull without making a mess in existing and new integrations. 

EDIT
So in this case, variables for histeresis and the rest in the code

[Neo Andersson 230]

2 hours ago, m.roszak said:

Understood, its already quoted by the team to support Heating, Cooling and Idle operating states for linked devices.
I hope we can get it pretty soon.

 

 

Histeresis control is something you need to program manually at this point, making this the system feature inside the QuickApps may cause issues in specifc cases (like integration with phisical thermostat which actually has the histeresis already supported natively). Its a native fuction of the linked thermostat, its not something you can just enable.
I will discuss it with the team, if there is a way to make it in the way that it will be usefull without making a mess in existing and new integrations. 

EDIT
So in this case, variables for histeresis and the rest in the code

Strange what you say, becuase it has hsyteresies for auto mode by default. It only misses for heating, or cooling modes. Anyway, thanks

[m.roszak 763]

ah, you mean the deadband between heating and cooling (not the control histeresis) - thats another thing, yes. 
Its set globally in the system for 2*C.