Changes

OpenHAB ISY Binding rework

6 bytes removed, 23:32, 7 May 2018
/* current status and problems */
== current status and problems ==
The current ISY binding does a nice job of getting ISY device updates into the binding and abstracting the different ISY devices into the OHAB realm. However, there are a few shortfalls the require addressing to make the binding truly useful withing OPENHAB.
=== ISY bridge discovery ===
The binding currently doesn't support auto-discovery, although supported by the ISY after enabling UPNP in the network tab. It can be added manually, but that creates a slight problem since the binding assigns a unique ID (UID) that is generated, and not based on the UID of the actual device - thus multiple instances of the bridge could be added, which probably wind up stepping on each other.
; FIX: regardless if auto-discovered or manually added, use the UID of the ISY to create the OHAB UID. This way, each unique device can only be added once
=== structural changes to ISY setup ===
currently, the binding only scans the ISY REST API once to discover existing devices - on initial creation of the bridge. If the bridge already exists in the OHAB config as a thing, it will not call the REST API's scan/discovery again. This means, for any addition/removal of devices or scenes on the ISY, the OHAB bridge has to be removed, which will also remove any discovered and linked INSTEON devices - the user has to start over on each structural change to the ISY. What's worse: crating a "phony" change to the bridge configuration with the intend that a correction of that change will trigger a rediscovery ends in a NPE in bridgehandler.dispose() and the user being unable to reuse that bridge handler again.
; FIX: fix the ISY Web Socket Listener to listen to
Bureaucrat, administrator
963
edits