OpenHAB ISY Binding rework - Revision history

Thomas: /* Structural changes to ISY setup */

2018-05-09T23:59:41Z

‎Structural changes to ISY setup

Thomas: /* ISY bridge doesn't accept configuration changes */

2018-05-09T21:20:08Z

‎ISY bridge doesn't accept configuration changes

Thomas: /* No Scene updates from ISY */

2018-05-08T00:17:07Z

‎No Scene updates from ISY

Thomas: /* Structural changes to ISY setup */

2018-05-08T00:14:04Z

‎Structural changes to ISY setup

Thomas: /* Structural changes to ISY setup */

2018-05-08T00:10:50Z

‎Structural changes to ISY setup

Thomas: /* Current Status and Problems */

2018-05-08T00:09:10Z

‎Current Status and Problems

Thomas: /* No Scene updates from ISY */

2018-05-07T23:47:20Z

‎No Scene updates from ISY

Thomas: /* No Scene updates from ISY */

2018-05-07T23:43:56Z

‎No Scene updates from ISY

Thomas: /* current status and problems */

2018-05-07T23:34:41Z

‎current status and problems

Thomas: /* current status and problems */

2018-05-07T23:32:52Z

‎current status and problems

@@ Line 12: / Line 12: @@
 ; : * Scene Add/Remove
 ; : * Scene Link Add/Remove
-; : * Variable Add/Remove (I don't use ISY variables)
+; : * Variable Add/Remove (I don't use ISY variables) <-- no useable WS events
 ; : 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 interface. 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?).

@@ Line 14: / Line 14: @@
 ; : * 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 interface. 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?).
 == No Scene updates from ISY ==

@@ Line 14: / Line 14: @@
 ; : * 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 interface. 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?).
 == No Scene updates from ISY ==

@@ Line 7: / Line 7: @@
 == 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.
+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. Also: attempting to create 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

@@ Line 13: / Line 13: @@
 ; : * 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?).
+; : 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 interface. 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?).
 == No Scene updates from ISY ==

@@ Line 1: / Line 1: @@
 = 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.
+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 within OPENHAB.
 == ISY bridge discovery ==

@@ Line 16: / Line 16: @@
 == No Scene updates from ISY ==
-Although the ISY binding discovers ISY scenes, and lets the user change the state, any state changes from the "real world" are not reflected into the binding. See PR
+Although the ISY binding discovers ISY scenes, and lets the user change the state, any state changes from the "real world" are not reflected into the binding. See PR https://github.com/QuailAutomation/openhab2-addons/pull/129
 == ISY devices go ONLINE indiscriminately ==
 Currently, any ISY devices that are added to the config are set ONLINE regardless of communication status (or if the device is still around). If the device is not communicating with the ISY (or defective), the binding status of the device does not reflect that.
 ;FIX : the binding for the device should only set the device status ONLINE once there has been confirmed communication/update from the ISY. This works ok for devices that are already established (after a reboot of the OHAB system) since the Web Socket will create a initial update which can be used to set each established thing in the configuration.  However, when the device is just created, there is no initial update (that update was missed when the binding started the Web Socket) and therefore the device will not go ONLINE. Therefore, initial creation of the thing needs to get an update from the REST interface for the new device.

← Older revision		Revision as of 23:43, 7 May 2018
Line 17:		Line 17:
	== No Scene updates from ISY ==		== No Scene updates from ISY ==
	Although the ISY binding discovers ISY scenes, and lets the user change the state, any state changes from the "real world" are not reflected into the binding. See PR		Although the ISY binding discovers ISY scenes, and lets the user change the state, any state changes from the "real world" are not reflected into the binding. See PR
		+
		+	== ISY devices go ONLINE indiscriminately ==
		+	Currently, any ISY devices that are added to the config are set ONLINE regardless of communication status (or if the device is still around). If the device is not communicating with the ISY (or defective), the binding status of the device does not reflect that.
		+	;FIX : the binding for the device should only set the device status ONLINE once there has been confirmed communication/update from the ISY. This works ok for devices that are already established (after a reboot of the OHAB system) since the Web Socket will create a initial update which can be used to set each established thing in the configuration. However, when the device is just created, there is no initial update (that update was missed when the binding started the Web Socket) and therefore the device will not go ONLINE. Therefore, initial creation of the thing needs to get an update from the REST interface for the new device.

@@ 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.
 ; 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 ===
+== 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