This project is read-only.
1

Closed

insteon reaction inconsistent in its response after unplugging USB

description

Currently, I am only able to connect an ApplianceLinc controller to my Mayhem "INSTEON Command" reaction when I have the PowerLinc USB controller plugged into my computer and into the ApplianceLinc controller that I want to use in my connection. When I have that setup, I am able to use the commands. However, if I unplug the PowerLinc USB from the computer and attempt to trigger my connection(s), naturally, they fail since the controller is not detected. The problem lies when I plug the USB back in - the responses from triggering my reactions is inconsistent. Sometimes after plugging the USB back in, I'll have to reset the controllers to be able to trigger them, and sometimes they won't respond at all until I rewrite my connections from scratch.
Closed May 7, 2012 at 4:33 PM by INSTEON

comments

erikm1 wrote Apr 6, 2012 at 1:16 AM

NOTE If I unplug, replug, then unplug the USB and attempt to trigger my connection(s) again, I don't even get an error message in the error log. The connections seem to almost be invisible to the program at that point..

INSTEON wrote Apr 7, 2012 at 8:14 AM

Improved handling of the disconnect scenario. The code no longer closes the connection as it did when it detected a disconnect. Now, it reports to the user that a disconnect occurred, but it leaves the connection open so that communications can be restored by plugging the device back in. Should work much better now.

erikm1 wrote Apr 9, 2012 at 6:03 PM

Fix confirmed, though ideally the connections would not be able to be switched "ON" (if switched to an "OFF" position while the device was unplugged) if there are no devices found; when the user tries to switch the connections back "ON", an error should be displayed in the error log informing them of the currently missing device.

INSTEON wrote Apr 16, 2012 at 7:39 PM

Will add a check to verify the INSTEON connection when switching an event or reaction from OFF to ON, and disallow the action with an error if the verification fails.

TheSavior wrote Apr 18, 2012 at 7:58 AM

This is much better, but the on/off error log functionality isn't very consistent.

When I startup the app with enabled connections (and my modem unplugged), it shows the errors correctly. But if I have the connections enabled, unplug the usb cable for the modem, disable the connection and re-enable, that seems to work without giving me an error (but should give an error). Can you double check that this is fixed for you?

TheSavior wrote Apr 18, 2012 at 8:05 AM

It looks like in that situation it is because verifyStopwatch.ElapsedMilliseconds is 0 and that the timer isn't running.

INSTEON wrote Apr 18, 2012 at 5:18 PM

This issue is in good overall shape now. The bug around ElapsedMilliseconds=0 is non-critical and can be rolled into a next release when we have more feedback.

davetemplin wrote Apr 24, 2012 at 8:00 PM

Fixed ElapsedMilliseconds=0 issue.

davetemplin wrote Apr 24, 2012 at 8:02 PM

Fixed in 1.0.2.