I have the same problem with HomeKit showing 38 degrees for temperature sensors. In my case, the sensors are reporting the correct temp in OpenHAB, and the temps are all different. What they have in common is they all have a decimal point in the value. It appears HomeKit doesn’t like the format and reports it as 38 degrees no matter what the value. Does anyone know if there’s a fix for this?
Apple has defined default max and min values for temperature. if the value is above or below min/max it gets replaced by min/max. the default max value is 38 degree celsius.
usually it gets more tricky with Fahrenheit as numbers are higher there. if you use Fahrenheit please make sure you have set Fahrenheit in unit in homekit binding settings.
you can also overwrite the default the min/max values via minValue/maxValue at openHAB item.
e.g.
Number thermostat_current_temp {homekit = "CurrentTemperature" [minValue=5, maxValue=100]}
Thanks for the reply. I realized the resolution was not the problem. The sensor without a decimal point was only 29 degrees F. The others were over 38 degrees, so you are correct.
I already have Fahrenheit set in the HomeKit settings, so I tried adding the minValue/maxValue to the metadata. I’m using the GUI, so I added it to the Metadata:stateDescription. The code is as follows:
value: " "
config:
min: “0”
max: “100”
Unfortunately this didn’t fix the problem. It’s still showing 38 degrees. Any idea what I’m doing wrong?
Is there an option or config item to remove the decimal place? Maybe HomeKit is expecting whole numbers not fractions (decimals)…
I will say, this was a difference in OH2.5, which displayed the temps properly in HomeKit…
Kristian Guntzelman
you need to add minValue and maxValue to homekit metadata.
if you use OH 3.2 then main ui has already input fields for min/max value so that you dont need to touch textual configuration.
here are the screenshots from my setup
just check the specification and implementation - fractions / decimals are fine. according to spec temperature can be float, i.e. with decimal, and the implementation also support it.
also works correctly for me
That was the problem, thanks! I should have noticed these settings in the HomeKit metadata. Just curious why the defaults are in Celsius? I understand the HomeKit protocol uses Celcius, however shouldn’t they be Fahrenheit values when “Use Fahrenheit Temperature” is selected? That would really simplify it for the user.
With regard to thermostats, I was able to get the correct temps by setting the min/max values for Thermostat.CurrentTemperature and Thermostat.TargetTemperature. However I can’t get the modes to work. I have a Leviton OmniPro and RC2000 thermostat (via OmniLink binding), so I added numbers (0,1,2,3) to the global HomeKit Heating/Cooling mappings. However this didn’t work. Any suggestions?
Also, this thermostat supports humidity, but there’s no support for thermostat humidity in HomeKit. So I decided to make it a separate humidity sensor. I tried adding HumiditySensor.RelativeHumidity to the thermostat humidity item in the thermostat equipment group, but it did not work. I had to create another item outside the group for it to work. Does this sound correct?
Where are you looking? openHAB chooses default temperature units for display based on the local that you told it.
I needed to add min and max values for the HomeKit temperature items. (As I noted, my sensors were limited to 38 degrees max.) This doesn’t seem like it should be necessary if I already set the HomeKit global setting to Fahrenheit. OpenHAB should know this and adjust accordingly without the need to do anything else. That said, what’s the purpose of these limits anyway?
More details here: (Homekit temperature sensor won't go below 10°C - #16 by dirkdirk)
do you know which version of openHAB you have? actually the issue with default min/max not being converted to Fahrenheit was fixed recently and should work with OH3.2
if not, i would need to check it again.
Apple has defined max/min values for all characteristic and not only temperature. sometimes it helps to do proper visualisation in home app, e.g. gauge, sometimes it has no benefit.
regarding humidity at thermostats: this will be supported in the next release. currently you need to create humidity sensor outside of the thermostat group
regarding the modes:
- settings should apply without restart, but just to be on safe side, please restart openhab
- check in main UI which value the item for mode gets. is it 0,1,2,3? What home apps shows? if you change the mode in home app, what happens to value at openhab item?
I just installed it last week. It shows “3.2.0 Release Build” in the UI.
Good news about support for humidity. Thanks!
Regarding the thermostat modes, the current and target items are both numbers. They show the following in the UI:
Target Mode (0, 1) : Off, Heat
Current Mode (0, 1) : Idle, Heating
Note that I only have heat. (No AC)
- After restart, the UI shows the correct status from the OmniPro (i.e. “Heat”). HomeKit shows the mode as “OFF”.
- If I manually change the mode in HomeKit to anything other than “OFF” and then change the mode in the UI to anything (incl. “Off”), HomeKit will change it to “OFF”. Closing the Home app and reopening it also changes it back to “OFF”.
- Changing the mode in HomeKit does not change the mode in openHAB.
- Changing the mode in HomeKit to “HEAT” will show the setpoint temp. Changing the temp will change the set point in openHAB.
I hope this helps.
I think the mapping is not working as it should. Can you make a screenshot of your mapping settings in UI?
but you have mentioned that you have to map to 0 or 1 values
so, put them in OFF and HEAT fields and remove mapping from others, i.e.
The screenshots are of the last values I tried. I previously tried using numbers instead of names. Both with and without entries for cool, cooling, and auto. Nothing seems to work. Here’s a summary of the 4 sets of values tried.
hm. do you see any messages in the log files related to heating modes?
if you put empty value for “cool” for target mode it should disappear in the home app from the list of possible modes. please check it. so we check whether the mapping is working in general
Yes, putting values for Off and Heat will only show a circle instead of a list. Adding Cool and/or Auto values will add those modes and show the selection list.
When I select heat in the Home app, I get this message in the log. It doesn’t matter if the values are numbers or text.
2022-02-21 14:14:40.786 [WARN ] [ssories.AbstractHomekitAccessoryImpl] - Unsupported item type for characteristic TARGET_HEATING_COOLING_STATE at accessory Downstairs_Thermostat. Expected class org.openhab.core.library.items.StringItem, got class org.openhab.core.library.items.NumberItem
right, the homekit binding expect a String item type for modes and does not support Number.
not sure whether you can just replace “Number” with “String”. probably your thing channel need a number. in such case the only way is to introduce one additional “virtual” item of type string and have a rule that keep “Number” item linked to Thing and “String” item linked to homekit in sync.
here is example from my setup.
i have
- item called “valve_workroom” which is Number and express how much heating valve is open. it is linked to a corresponding KNX device via a Thing. it has no homekit metadata
- item call “workCurrentThermostatMode” which is String and has no channel / Thing linked to it. it has homekit metadata
and then i have this rule. it is older one done without UI but i hope you get the idea. the rule in my case is one-directional - from openHAB to homekit as i cannot set a mode on my physical thermostat. you would need to have a similar one for homekit → device mapping
rule "Map Workroom Heating Mode for Homekit"
when
Item valve_workroom received update
then
if (valve_workroom.state > 0) {
workCurrentThermostatMode.postUpdate("HEAT")
workTargetThermostatMode.postUpdate("HEAT")
} else {
workCurrentThermostatMode.postUpdate("Off")
workTargetThermostatMode.postUpdate("Off")
}
end
Thanks for your help. I was able to get this working using a proxy. However, there’s still an issue with synchronizing the mode, since it can be changed from both HomeKit and OH. I will end up with an endless loop using rules. Any suggestions?
important is to select sendCommand or postUpdate correctly. sendCommand triggers rules, postUpdate not.