(→structural changes to ISY setup) |
(→current status and problems) |
||
| Line 1: | Line 1: | ||
== 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 === | === 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. | 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. | ||
Revision as of 17:32, 7 May 2018
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
- * Device Add/Remove
- * Scene Add/Remove
- * Scene Link Add/Remove
- * Variable Add/Remove (I don't use ISY variables)
- and add/remove ISY devices to/from OHAB Inbox. Also, add a ISY REST scan each time the system starts up, and reconcile any changes to the device structure - this way the inbox can be updated. Existing devices should be set OFFLINE (or REMOVED?) if the device is no longer part of the REST document. If the Web Socket indicates a removed device/scene/variable, remove from inbox if present -if the ISY device/scene/variable is already added as thing, then set OFFLINE (or REMOVED?).