* [mqtt.espmilight] Automatically convert color values to color temp for RGB+CCT bulbs
Yes, it's lots of math, but references are provided. This supplants
whiteThreshold for RGB+CCT bulbs since it is far more flexible and
accurate.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
otherwise if your step is 1.0 in fahrenheit, then your
values will get rounded to 1.0 celsius, and you might not
even notice you've lost precision in the Home app.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [mqtt.homeassistant] support non-RGB lights
dynamically decide which type of channel to expose. also send "down-typed"
commands to the proper topic. this also sets the groundwork for supporting
template and JSON schemas
Signed-off-by: Cody Cutrer <cody@cutrer.us>
So that other pieces of openhab can know what unit it's going to be,
without it having a value yet. Importantly, any necessary conversion
that need to be applied to the other portion of the state description -
min, max, and step.
See also https://github.com/openhab/openhab-core/pull/3132
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] increase flexibility of ColorTemperature
allow Number or Dimmer items, and mired or Kelvin units.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] Improve output of console's `homekit show` command
* include the full JSON from all the characteristics, so you can confirm
everything is configured correctly.
* only use simple class names; the fully qualified package is just a
distraction.
* show linked services if they exist
* include the class name of services, not just the GUID
Signed-off-by: Cody Cutrer <cody@cutrer.us>
If you have many instances, it can take a while. So stop all the
instances in parallel. Also, fix a race condition where the update
debouncer might get called again after being stopped, because the
change listener was deregistered _after_ the debouncer was stopped.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] fix BooleanItemReader to work with DimmerItems
DimmerItems have a PercentType state, which is easily convertible
to OnOffType, but is not inherited from it. So take that into account.
i.e. a variable speed fan can use a single DimmerItem for both
ActiveStatus and RotationSpeed.
* [homekit] Document that Dimmer is a possible item type for several booleans
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] allow configuring maxValue on VOCDensity
the default of 1000 is quite low in reality. tested and confirmed
working with iOS 16
* [homekit] allow step value to be configured for VOCDensity
Signed-off-by: Cody Cutrer <cody@cutrer.us>
this helps to auto-configure if the binding is providing the necessary info
metadata config still overrides
Signed-off-by: Cody Cutrer <cody@cutrer.us>
HASS registers availability topics before calling start(), so
the AbstractMQTTThingHandler was never subscribing/starting the
availability channel(s). So do so in start() of the base class.
I checked other implementations, and either they already handle
re-registering availabilityTopics in their start()
(GenericMQTTThingHandler), or they don't use availabilityTopics
at all from the base class and manage it themselves (Homie).
Note that this shows up as newly-added HASS things not having
a problem (because the components aren't discovered until after
the ThingHandler is started), but if you restart OpenHAB or
disable/enable the thing, the channels (and components) are
cached, thus how availabilityTopics are known before starting.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
pass the actual class objects through, and post-process in Ruby, to
avoid the rescue nil -- and by extension, any issues with visibility
into private objects from JRuby.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
Range is 0..255, not 0..250.
rgb -> hsv -> rgb still isn't perfect, but it's better. In
particular, I found this when using HSBType.BLUE in a test,
and it was coming out as 0,0,250 in RGB. It now comes out as
a proper 0,0,255.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
this is a theme, and I've extracted a helper method and applied it to several
other locations as well
example, I have a double-sliding door, with two contact sensors
in the alarm system, defined as:
```
Group:Contact:AND(CLOSED,OPEN) DeckDoor_Contact "Deck Door [%s]" <door> (gExteriorDoors, gWarningVisibility_Contact, gDoor, lMainFloor, gInflux) { homekit="ContactSensor" [instance=2] }
Contact DeckNDoor_Contact "Deck Door North" <door> (gInflux, DeckDoor_Contact, gGreatContacts) { channel="dscalarm:zone:46c52f35:zone11:zone_status" }
Switch DeckNDoor_Tamper "Deck Door North Tamper [%s]" <warning> (gTamper, gWarningVisibility_Switch) { channel="dscalarm:zone:46c52f35:zone11:zone_tamper" }
Contact DeckSDoor_Contact "Deck Door South" <door> (gInflux, DeckDoor_Contact, gGreatContacts) { channel="dscalarm:zone:46c52f35:zone12:zone_status" }
Switch DeckSDoor_Tamper "Deck Door South Tamper [%s]" <warning> (gTamper, gWarningVisibility_Switch) { channel="dscalarm:zone:46c52f35:zone12:zone_tamper" }
```
This allows the Group:Contact to be used for the ContactSensor.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
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