see reference in code comment, but a measurement sensor is assumed to
be numeric, even if it doesn't have a unit
Signed-off-by: Cody Cutrer <cody@cutrer.us>
given:
```
Group eThermostat { homekit="Thermostat" }
Number:Temperature Thermostat_AmbTemp (eThermostat) { homekit="CurrentTemperature" }
Number:Temperature Thermostat_SetTemp (eThermostat) { homekit="TargetTemperature" }
Group gThermostatZoneContacts
// in reality there are multiple thermostats and multiple of these groups,
// so that a rule on members of gThermostatZoneContacts can find the related
// thermostat to turn it off when a window is open
Group:Contact:OR(OPEN,CLOSED) gWindows (eThermostat, gThermostatZoneContacts)
Contact Window_Contact (gWindows) { homekit="ContactSensor" }
```
When constructing the Thermostat accessory for eThermostat, detects the
Window_Contact as a mandatory characteristic, because it's a base accessory
in a nested group. This leads to lots of warnings about the temperature
value of a contact item being out of range.
The fix is two-fold - first of all, there's no reason to search nested
groups for characteristics of a complex accessory. Second of all,
even if for some reason you were to nest an accessory in an accessory,
the nested accessory does not actually belong to the outer accessory,
so don't add it as a mandatory characteristic of the outer.
I suspect there's still one more bug, because AbstractHomekitAccessoryImpl.
getCharacteristic(HomekitCharacteristicType.CURRENT_TEMPERATURE) was
returning Window_Contact, which is only tagged as a ContactSensor. But
after fixing the above two bugs, it was no longer reproducible, and I
didn't continue digging.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [jrubyscripting] check if gems are installed before installing them
this avoids unecessary downloads and overwrites, or even more importantly
errors if the GEM_HOME is not writable by the openhab user.
this also adds a configuration option for if you want to check for
updates every time configuration is applied (or openhab restarts). this
is useful if your OpenHAB system can't access the internet regularly.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
this is especially important if you use the same item for both
TargetTemperature and HeatingThresholdTemperature characteristics,
since the former was already doing unit conversion for min/max.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
fixes#10711
technically this code is in mqtt.generic, but it's only used by Homie.
in particular, if an incoming string doesn't match an enum, this will now
just ignore the value instead of raising an exception to be caught somewhere inside
of Hive MQTT, and eventually timing out and logging that mandatory topics weren't
received, instead of logging a pointer to the actual problem. this makes it so that
if there's a homie $datatype openhab doesn't understand (like duration), it will be
able to get to the point of just choosing a string channel
also did some minor debug logging cleanup for mqtt:
* fixed a typo
* when logging homie device name from the thing handler, use the config deviceid,
since we likely don't have the attributes from MQTT yet
Signed-off-by: Cody Cutrer <cody@cutrer.us>
if an Item associated with a temperature characteristic has a QuantityType
(of dimension Temperature) as its state, regardless of current unit,
use that to convert to celsius instead of any other configuration.
Note that this is only for supply values to HomeKit; commands coming from
HomeKit will still send a DecimalType with units according to the HomeKit-wide
useFahrenheit configuration.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
Cody CutrerandGitHub