Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ISY994i Device Issues
#1
Recently I decided to upgrade from the old Insteon serial modem driver to the newer Insteon/ISY driver.  I did this because the PLM was basically unreliable and I didn't want to rewrite the CQC driver to handle all the lost commands and events with multiple retries.  I've run into one major and one minor problem:

I'm running CQC version 5.2.1 with the V2 version of the Insteon/ISY driver. I searched the forum and if this issue was corrected or a workaround exists, I couldn't find it.

Major issue:

I have 2 mini-remotes, both of version 2342-2. One is configured as a 4 scene remote and the other as an 8 button non-toggle style remote (meaning it sends "On" Keypresses only.  I have CQC set to trigger on the events using a "Is User Action From" style triggered event. The event then parses which button was pushed. Every time the ISY driver reconfigures, it sends a storm of Trigger Events, one for each of the 8 buttons and 4 scenes.  This activates every single one of my triggered actions. Because all of the buttons on my 8 button mini-remote are of the non-toggle style, I can't even get around this issue by creating triggers in the driver and watching for field changes.

Why the driver loses its connection once every day or two is a mystery but, in any case, one has to reconfigure every now and then anyways.   The driver shouldn't be doing this.  I turned on High verbosity and no "Got Click" messages are logged.  Just the Triggered Events that I am logging through the event actions.

Minor issue:

I have a 2663-222 dual outlet module.  This module has a button on it per outlet to control the power to the outlets.  The top outlet loads as a LGHT#Sw so it works fine and can be controlled.  The bottom outlet loads as a Button so it is read only and can't be controlled.  I don't care if the Button presses can be captured. And I'm just using the top outlet so this isn't a big deal.

Oddly, the one Button from the outlet module also sends an event from the driver on the reconfigure.  So, that problem is not inherent to the device, but is a problem with Button handling in the driver.

Thanks in advance for the help,
-AJ
Reply
#2
On the first thing, the sending out of triggers happens at a low level down in the guts of the driver infrastructure. It doesn't know that the values being written to the field are initial ones from driver startup. It just sees that the value changed and knows it's supposed to send a trigger when they change. So it's something that's always been a bit of a sore spot, but very difficult to get around. I'll take another look at it. There's always this balance between if you do it up higher in the code you have more control over context, but inevitably there end up being a lot more than one place where it has to be done, and that leaves you open to missing one of them if something has to be changed. Pushing it down lower means it's done in one place, but it doesn't understand the context of the value change.

The second thing I'm not sure about. So this guy has two outlets and two buttons? Maybe the driver is misinterpreting the information or something. Can you capture the XML description from the ISY for that button for me?
Dean Roddey
Software Geek Extraordinaire
Reply
#3
Dean,

Thanks for looking at that again.  You're right that I wouldn't want to miss a user Keypress, but my events are doing things like turning on lights, starting audio playback, etc.  Having 8 of these things happen randomly through the day and also at night is too weird to even be workable.  I'd have to abandon the driver completely.  I thought of a cheap bad workaround though.  What I'll do is store the $Reconfigured value in a variable.  Then I'll create a trigger on that field that will cause the other triggered event to pause for a few seconds then resume.  It's clunky but do you think that will work?

It took me a bit to figure out that I have to use the REST interface to get the XML. The ISY adds the Top and Bottom suffixes. Here is the XML description for the ISY device:

<node flag="128">
    <address>4C 68 1C 1</address>
    <name>Driveway.Outlet.Lights.Top</name>
    <type>2.57.68.0</type>
    <enabled>true</enabled>
    <deviceClass>0</deviceClass>
    <wattage>0</wattage>
    <dcPeriod>0</dcPeriod>
    <startDelay>0</startDelay>
    <endDelay>0</endDelay>
    <pnode>4C 68 1C 1</pnode>
    <ELK_ID>A11</ELK_ID>
    <property id="ST" value="0" formatted="Off" uom="on/off"/>
</node>
<node flag="0">
    <address>4C 68 1C 2</address>
    <name>Driveway.Outlet.Lights.Bottom</name>
    <type>2.57.68.0</type>
    <enabled>true</enabled>
    <deviceClass>0</deviceClass>
    <wattage>0</wattage>
    <dcPeriod>0</dcPeriod>
    <startDelay>0</startDelay>
    <endDelay>0</endDelay>
    <pnode>4C 68 1C 1</pnode>
    <ELK_ID>A12</ELK_ID>
    <property id="ST" value="0" formatted="Off" uom="on/off"/>
</node>
Reply
#4
They seem to be almost identical, so I'm not sure why it's treating them as different types. And the type is obviously the same. I'll look at it.

It has an Elk id, so you are controlling the ISY which is controlling the Elk which is controlling something else?

On the work around, until such time as it can be dealt with, I'd think maybe just a manual setting of a disabling field might be best. Do the reconfigure, and then enable it again or something like that.
Dean Roddey
Software Geek Extraordinaire
Reply
#5
I'm not using an Elk at all. I don't even have it configured in the ISY admin console. My guess is that it assigns every node an Elk ID automatically.

In CQC, the bottom outlet becomes: Button_DrivewayOutletLightsBottom
and the top outlet becomes: LGHT#SwDrivewayOutletLightsTop

I'll try the work around and report back.

Thanks,

-AJ
Reply
#6
In theory, both these issues should be fixed in the 5.2.914 beta drop later today.
Dean Roddey
Software Geek Extraordinaire
Reply
#7
(05-22-2018, 04:21 PM)Dean Roddey Wrote: In theory, both these issues should be fixed in the 5.2.914 beta drop later today.

I installed the new beta and will see how it goes. The device 2663-222 dual outlet module now reports correctly.

On loading the administrative interface, there is an error: The client side driver directory could not be cleaned out. That is probably not going to be a fatal error, but it should be investigated.  The log shows a corresponding: Loading a client driver in test mode, but no resource dir found in environment.  Guessing I can ignore it.

-AJ
Reply
#8
That would only happen if the CQC client service isn't running, which it always should be. You didn't disable or something did you?
Dean Roddey
Software Geek Extraordinaire
Reply
#9
(05-22-2018, 07:18 PM)Dean Roddey Wrote: That would only happen if the CQC client service isn't running, which it always should be. You didn't disable or something did you?

I didn't disable it but it wasn't running.  Rebooted and it's running now.  So far so good.  I'll watch for random triggers.

Thanks,
AJ
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  5.3.2 IsDeviceReady slow for non-existant device rbroders 10 212 10-04-2018, 04:17 PM
Last Post: Dean Roddey
  Echo Config file issues ghurty 6 448 07-08-2018, 07:13 PM
Last Post: ghurty
  What device model to put for a Jasco/GE switch? And a questions about V1/V2/V3. ghurty 1 215 05-16-2018, 09:06 PM
Last Post: Dean Roddey
  Redid server, issues with Nest and Elk ghurty 6 523 05-16-2018, 05:15 PM
Last Post: Dean Roddey
  CQC Server network issues znelbok 1 414 03-20-2018, 12:36 PM
Last Post: Dean Roddey
  NameSrv Issues with installing 5_2_10 pjgregory 4 748 01-30-2018, 08:19 PM
Last Post: Dean Roddey
  Lutron Caseta & Zwave Issues dangerlong 133 19,325 12-20-2017, 06:06 PM
Last Post: tom
  Passing device name as variable jokermac 12 2,142 11-18-2017, 12:38 PM
Last Post: jokermac
  Issues viewing threads on forums Acropolis 9 1,802 11-15-2017, 10:15 AM
Last Post: Dean Roddey
  Issues after fall Windows updates Ron Haley 3 984 10-24-2017, 06:35 PM
Last Post: Ron Haley

Forum Jump:


Users browsing this thread: 1 Guest(s)