Releases: PatchworkBoy/homebridge-edomoticz
v2.1.40
v2.1.38
Additional fix for dimming lights ; see #210
Again, thanks to @sander1988!
Minor update for some fixes...
See #219 - thanks to @sander1988 for his work on all this...
v2.1.34
There are some wonky WW light implementations out there, where the lights identify as WW but then don’t provide a Color object via the Domoticz JSON API. There are zigbee2mqtt and yeelight examples of this thus far. I've attempted to work around this and fall them back to being plain old dimmers again if a Color object isn’t found or is there but empty when heading to http://domoticz.ip.address/json.htm?type=devices&rid= , so they basically go back to how they worked in 2.1.18 - See #192
Also, a word of warning on the iOS13 HomeKit TV device type: sanders1988 committed a patch where a multi-selector with a TV Icon is mapped to the iOS13 TV device type, however, it’s wonky and disassembles itself after creation - sanders1988 is looking into this at the moment, so best to avoid using this combination in the short term - See #194
BUT, that aside, if you rely on an AppleTV3 or old iPad on iOS10-12 as a homehub for remote access, and add an iOS13 TV type device to HomeKit, that home hub will cease to function. ALL devices will be seen as "not responding" by the hub. The ONLY fix is to delete your home from HomeKit, and start again WITHOUT the TV accessory. As soon as you add one, your home is broken until you delete it. If you have an AppleTV4, HomePod, or iPad on iOS13 acting as your HomeHub then all is ok. This isn’t anything to do with homebridge-edomoticz / homebridge (so if you’re curious to try the sky-q-experimental plugin alongside edomoticz for instance, don’t, because you’ll get the same problem).
This is entirely a limitation at Apple’s end - the TV Type device will only work when the client device is iOS13, and the HomeHub device is on a "current" version of it’s OS. I may add a config flag to config.json that users have to manually override in order to enable the TV Device Type to avoid them having to erase their entire Home in the not-too-distant future.
v2.1.32
Fixes...
- excludedDevices: has been inoperable for a while. Add device IDXs to array, restart homebridge. Existing devices for that IDX will be automatically removed, new devices with that IDX will be ignored.
- Temp sensors: will now reflect StatusFault if they’re in a timeout state in Domoticz. Applies to Temp, Temp+Hum, Temp+Hum+Baro sensors.
- Temp+Hum+Baro sensors: eDomoticz will now create a multi service device, one for Eve containing all 3 types, one for native HomeKit containing just Temp+Hum.
v2.1.31 - *sigh*
I’m not having a good weekend... hopefully THIS resolves excludedDevices!
Advice: Remove cachedAccessories after changing excludedDevices array, then restart homebridge.
v2.1.30
Update Help entry for Config-UI-X excludedDevices listing to mention clearing cachedAccessories file.
v2.1.29
Apparently 2.1.28 wasn’t the last oopsie... I have difficulty knowing when my souped autistic brain can and can’t deal with coding sessions - sorry.
Hopefully 2.1.29 fixes issues introduced. Please note that for this update, you will need to clear your cachedAccessories file.
On vanilla installations, this would usually be handled by rm -rf ~/.homebridge/accessories/cachedAccessories
v2.1.28 - last oopsie of the day?
Rogue StatusActive had crept in to Eve Weather / Temp + Hum + Baro... should’ve been StatusFault.