Thermostat target Position in Home App

[apfelflo89]

Setting the target position within the Apple Home App with a GUI value like "20" exposes a coma value.

Item 'ThermostatKuecheSOLLKomma' received command 21.2

Changed target state of Thermostat Küche [ThermostatKuecheSOLLKomma] to 21.2

Is there a way you could except only values with .0 or 0.5 ?

[maisun]

Also experience this issue - is there a way to only allow integer values (adjust one degree at a time)? Thank you

[steilerDev]

In theory I could implement something like this in the logic of the home bridge plugin. However I don't understand where the issue with non-Integer values is? My setup uses point-values successfully and the HomeKit Specification explicitly allows float values with step values of 0.1 (See 8.35 of Apple's Docs, version 2017.06.07).

If you want to alter this behavior you should implement that in an OpenHab rule for your item, e.g.: When the item state changes, update it to the next integer. My homebridge plugin should then show the updated value automatically.

[maisun]

I think again it is about validation of user input and better to be implemented in UI (HomeKit). Basically the attribute minStep controls the minimal temp change. BTW maxValue and minValue controls allowed range, and if you don't define it, the maxValue will default to 38 degree (for my water boiler it's no good). My experience with float point is that when I adjust down 0,5 in HomeKit, it somethings only descrease by 0,4 in OH, I think it is a round issue somewhere.

[hartmood]

My Eurotronics Z-Wave Thermostat only supports increments of 0.5. Is there a way to add this to the following rule

rule "DG Thermostate Sync" 

when
    Item zwave_device_414e6662_node15_thermostat_setpoint_heating received command
then
    zwave_device_414e6662_node16_thermostat_setpoint_heating.sendCommand(receivedCommand)
end

[steilerDev]

@maisun: I absolutely agree, however I set the goal to validate against the HomeKit Accessory Protocol. If the protocol would specify increments of 0.5, I would do that, but it does not, and e.g. my thermostat allows 0.1 increments. If I would implement 0.5 increments, I (and probably other people) would loose this functionality.

Every accessory specific validation should be done in OpenHAB rules, since this is the integration layer, just as @hartmood suggested.

[maisun]

@maisun: I absolutely agree, however I set the goal to validate against the HomeKit Accessory Protocol. If the protocol would specify increments of 0.5, I would do that, but it does not, and e.g. my thermostat allows 0.1 increments. If I would implement 0.5 increments, I (and probably other people) would loose this functionality.

Every accessory specific validation should be done in OpenHAB rules, since this is the integration layer, just as @hartmood suggested.

Hi Frank, What I'm suggesting is to include some additional configuration varibales for users to control what input values are allowed in HomeKit. I did some change to your code (not the best place but my JS experience is very limited), in that way you can tell HomeBridge what are the expected range of values and minimal steps (0.5 or 0.1 for example). You can even define the allowed target running modes, for example, only HEAT or both HEAT/COOL. This will match the underlying device better and provide flexibility for users to choose best fits. class HeaterCoolerAccessory extends Accessory { constructor(platform, config) { super(platform, config); this._services = [this._getAccessoryInformationService('Heater/Cooler'), this._getPrimaryService(config)] } _getPrimaryService(config) { this._log.debug(Creating Heater/Cooler service for ${this.name}); let primaryService = new this.Service.HeaterCooler(this.name); primaryService.getCharacteristic(this.Characteristic.HeatingThresholdTemperature).setProps({ maxValue: config.tempMaxValue, minValue: config.tempMinValue, minStep: config.tempMinStep }); primaryService.getCharacteristic(this.Characteristic.CoolingThresholdTemperature).setProps({ maxValue: config.tempMaxValue, minValue: config.tempMinValue, minStep: config.tempMinStep }); primaryService.getCharacteristic(this.Characteristic.RotationSpeed).setProps({ maxValue: config.fanMaxValue, minValue: config.fanMinValue, minStep: config.fanMinStep }); addCurrentTemperatureCharacteristic.bind(this)(primaryService); addTargetHeaterCoolerStateCharacteristic.bind(this)(primaryService); addCurrentHeaterCoolerStateCharacteristic.bind(this)(primaryService); addActiveCharacteristic.bind(this)(primaryService); addHeatingThresholdCharacteristic.bind(this)(primaryService, true); addCoolingThresholdCharacteristic.bind(this)(primaryService, true); addRotationSpeedCharacteristic.bind(this)(primaryService, true); addSwingModeCharacteristic.bind(this)(primaryService, true); addTemperatureDisplayUnitsCharacteristic.bind(this)(primaryService, true); return primaryService; } }

[maisun]

BTW, those values are defined implicitely in HAP-nodejs anyways. For example for target temperature the max value is 38 - in general it is Ok but for my water boiler is is too low :)

[hartmood]

I found the following code - unfortunately I am not able to add this to my rule above. But @steilerDev could that solve the problem with the target temperature?

val myStr = String::format("Temperature is %.5f", Temperature.state as DecimalType)