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.