René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Better mechanism for optional characteristics needed","articleBody":"# TL;DR\r\n\r\nThe current mechanism of implementing additional interfaces to add support for optional characteristics is non-conducive to supporting dynamic sets of optional characteristics.\r\n\r\n# Background and current workaround\r\n\r\nIn my fork of Openhab-homekit, I support low battery notification. However, whether or not an accessory actually has low-battery notification support is based on the items configuration. As a workaround, in order to avoid creating two classes for sensors that potentially have battery status reporting support, [I create a faux-battery notification implementation that always returns batteryLow=false](https://github.com/timcharper/openhab2-addons/blob/v2.4.0-homekit-5/addons/io/org.openhab.io.homekit/src/main/java/org/openhab/io/homekit/internal/battery/NoBatteryStatus.java)).\r\n\r\n# Limitations of providing substitute static-values\r\n \r\nSuch workarounds are not possible when adding a characteristic that fundamentally changes the presentation of an accessory in homekit. For example, with the thermostat, the addition of optional characteristics `Characteristic.CoolingThresholdTemperature` and `Characteristic.HeatingThresholdTemperature` causes the UI to show a temperature range, rather than a single temperature, when the AUTO TargetCoolingHeatingState is active.\r\n\r\n# Proposal and way forward\r\n\r\nI propose that accessories classes only specify getters, setters, and subscribers for their base class.\r\n\r\nThen, for optional characteristics, I propose that the accessory has an overridable getter which gets some optional characteristic, with the default value being none:\r\n\r\n```\r\n@Override\r\nprotected Optional\u003cHeatingThresholdCharacteristicSupport\u003e heatingThresholdTemperatureCharacteristic() {\r\n  heatingThresholdItem.map(item -\u003e {\r\n\r\n    new HeatingThresholdCharacteristicSupport() {\r\n      @Override\r\n      CompletableFuture\u003cDouble\u003e getHeatingThresholdTemperature() {\r\n        ...\r\n      }\r\n      ...\r\n    }\r\n  });\r\n}\r\n```\r\n\r\nThe `HeatingThermostat` trait can be modified such that the interface methods are lifted out in to `HeatingThresholdCharacteristicSupport`, retaining backwards compatibility (and potentially marking as deprecated for removal in next minor release of HAP-Java). After such a lift, the interface would be effectively empty:\r\n\r\n```\r\npackage com.beowulfe.hap.accessories.thermostat;\r\n\r\nimport com.beowulfe.hap.HomekitCharacteristicChangeCallback;\r\nimport java.util.concurrent.CompletableFuture;\r\n\r\n@Deprecated\r\npublic interface HeatingThermostat extends BasicThermostat, HeatingThresholdCharacteristicSupport {\r\n}\r\n```\r\n","author":{"url":"https://github.com/timcharper","@type":"Person","name":"timcharper"},"datePublished":"2019-02-04T08:41:32.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":25},"url":"https://github.com/63/HAP-Java/issues/63"}