Jump to content

Recommended Posts

Posted
now two KPLs cannot be written to, all going haywired

 

I had this happen to me when I moved my PLM. Don't know if that helps but moving the PLM or adding some electronics can mess up the communication pretty badly. A PLM dying is a possibility too. I had a lot of trouble with one KPL that had the little reset button get stuck from time to time, too. It would get wedged between the decorative faceplate and the G/H buttons so when you pressed them it would go in a little and not come back out.

 

mark

Posted

Thanks for asking.

 

After loading an older backup from a few days ago and trying to restore the two KPLs it worked OK. So good new is I got it all working again, bad news is I do not know what the problem is/was. It was very strange.

 

Joe

Posted

Hello Joe,

 

No ... i was just wondering what happened above and beyond loading an old backup.

 

With kind regards,

Michel

no I did not. just loaded older backup and did a restore. In the future would it be better to do a factory restore first?
  • 2 weeks later...
Posted

Is the following list just a bug list in 2.7.13 or a bug list and improvement list? Is it a list of what's BROKE or FIXED in 2.7.13? I'm a little confused because some of the items in the list sound like problems and some sound like improvements.

 

Bugs in 2.7.13

- 2476D w/sense ... no on levels in programs

- KPL sub button status not reflected correctly in the case of All On/All Off

- Crash while migrating IRLinc TX files

- UD Chart showing invalid dates

- Log shows invalid characters when done through HTML interface

- Alphabetical sorting of groups/nodes in the Chart utility

- Replace does not update the Adjust Scene settings

- Added Device/Node paths in the programs

- More consistent naming/icons for batch/battery devices (PRO only)

Posted

I have a scene that includes five responders and three controllers. The three controllers are three buttons on a KPL. For each of the three, I've set the on-level for the other two to zero. When I press one of the three buttons, the other two go off (desired behavior). One of the responders is a button on the same KPL.

 

When the scene is turned on (either via program or manually), all three controller buttons turn on and the responder button does not turn on. So I have two questions:

1. Should the responder button turn on when the scene is turned on?

EDIT: When I push one of the controller buttons, the responder button turns on. When I activate the scene in admin console, the responder button doesn't turn on. Shouldn't these two operations have the same result?

 

2. If all three controller buttons turn on, this isn't mutual exclusion. How do I set it up so only one button turns on? (I realize that there would have to be a way to specify which button should turn on).

 

The KPL is V.36. ISY is running 2.7.12.

 

Thanks.

 

Scott

Posted

Hi intellihome,

 

Apologies for the confusion. These are bug FIXES and enhancements. We do not yet have any confirmed bugs in 2.7.13.

 

I am going to update the post and making it more clear.

 

Thanks for bringing this issue to our attention.

 

With kind regards,

Michel

 

Is the following list just a bug list in 2.7.13 or a bug list and improvement list? Is it a list of what's BROKE or FIXED in 2.7.13? I'm a little confused because some of the items in the list sound like problems and some sound like improvements.

 

Bugs in 2.7.13

- 2476D w/sense ... no on levels in programs

- KPL sub button status not reflected correctly in the case of All On/All Off

- Crash while migrating IRLinc TX files

- UD Chart showing invalid dates

- Log shows invalid characters when done through HTML interface

- Alphabetical sorting of groups/nodes in the Chart utility

- Replace does not update the Adjust Scene settings

- Added Device/Node paths in the programs

- More consistent naming/icons for batch/battery devices (PRO only)

Posted

Hi Scott,

 

The problem is as follows:

1. Mutual Exclusivity only works locally on the same device

2. As soon as activation of any scene for which these buttons are members of, the Mutex relationship is broken

 

The best approach would be to use the Button Grouping button instead of a scene. Then you must have programs that sense any conflict and update the status. I know this is quite convoluted but - and unfortunately so - this is the only way around the problems stated above.

 

With kind regards,

Michel

Posted

Thanks Michel. That's what I thought but wanted to make sure.

 

 

Apologies for the confusion. These are bug FIXES and enhancements. We do not yet have any confirmed bugs in 2.7.13.

 

I am going to update the post and making it more clear.

Posted

Hello all!

 

This program:

 

If
       Status  'Thermostat' is Calling for Heat

Then
       Send Notification to 'Email Shawn'

Else
       Send Notification to 'Email Shawn'


 

... never triggers when the thermostat calls for heat. If I manually run the program the notfications are sent properly (so notifications are working), but when the thermostat calls for heat, the program does not run.

 

I wanted to see how many cycles and how long the heat runs so I wanted an email when it turned on, and another when it turned off.

 

What am I missing?

 

BTW, I upgraded from 2.7.6 to 2.7.12 flawlessly, then again to 2.7.13, again without issue.

 

Thanks!

Posted

Hi sceaton,

 

Would you be kind enough to check the following and let us know:

 

1. Ensure that your program is Enabled AND that you have V2 thermostats (V1 will not work)

2. Go to Program Summary so that you can see the status of programs. Then, please go to Tools | Diagnostics | Event Viewer and choose Level 3.

3. Cause your thermostat to call for Heat then:

1. Check out the traffic in the Event Viewer

2. If you see the events that change the mode to Call for Heat, then look at the program summary page and check the last runtime

 

In short, we want to make sure that your ISY indeed receives that event. If it does not, then we have to figure out where the signal is lost.

 

With kind regards,

Michel

Posted

Hi Michel!

 

The program is enabled, and the back of the adapter says "Rev 2.0" The ISY reports the thermostat adapter as "v.91"

 

Indeed my L3 event viewer comes up empty. I adjusted the setpoint on the thermostat so that it was calling for heat, and no traffic was observed.

 

I'm still old school with signalincs for phase coupling and just added a dual-band lamplinc for the thermostat. I know there have been issues with the DB lamplincs but other communication to the thermostat has been flawless. Programs change mode and setpoints just fine.

 

It seems as though the thermostat isn't sending out its status updates like it should. I don't have the adapter linked to any other device, I just added it through the ISY admin console. (I read that it will only send updates to the last linked device.)

 

Should I remove the thermostat and re-add?

 

As a separate issue:

Looking at the node in the admin console, the Fan Status often says "ON" even though the thermostat is set to Auto. This remains incorrect, even after I query the device. The other info (temp, setpoints, etc.) are correct.

 

Manually selecting "Auto" (does nothing, since the thermostat is already in auto) then Selecting "ON" turns the fan on, and changing back to "Auto" turns the fan Off. I'm not sure how the ISY loses sync with the fan status, and further why it doesn't re-sync when manually Queried.

 

Anything else to try?

 

TIA!

 

~shawn

Posted

Hi Shawn,

 

Excellent!!!!

 

You see, at least we know that we are not getting status updates from the thermostat. This could be caused by two scenarios:

1. Access Point ... I doubt this is the case since you mentioned that you get the correct status for your setpoints when they are changed (even from the thermostat?)

2. Misconfiguration ... please note that if you added your thermostat in any mode other than OFF then this could certainly happen

3. You are not waiting long enough for the thermostat to send you the status. Usually for Fan and Heat/Cool calling events, the thermostat waits between 30 seconds to 2 minutes (haven't figured out exactly how long) to account for fluctuations

 

You might want to remove the thermostat and add it back this time ensuring that it is indeed in the OFF mode when registering.

 

If you don't mind, we'll address other issues when we have solved this one.

 

With kind regards,

Michel

Posted

So when I change the setpoint on the thermostat, the new setpoint is NOT reflected in the ISY. If I manually query the thermostat from the admin console, the setpoint values are updated correctly (except for the fan status, which remains at "ON").

 

I added the thermostat in the OFF mode originally, but to be sure, I removed from ISY, and re-added. I then changed the setpoint via the admin console to create a heat demand (see below code) and waited 4 minutes, but didn't see anything in the log and of course my program didn't trigger.

 

Mon 03/22/2010 05:32:56 PM : [iNST-ACK    ] 02 62 14.06.CC 0F 6B 06 06                 (06)

Mon 03/22/2010 05:32:56 PM : [iNST-SRX    ] 02 50 14.06.CC 0C.A5.8D 23 6B 06           (06)

Mon 03/22/2010 05:32:56 PM : [standard-Direct Ack][14.06.CC-->ISY/PLM Group=0] Max Hops=3, Hops Left=0

Mon 03/22/2010 05:32:56 PM : [   14 6 CC 1]    CLIMD   3

Mon 03/22/2010 05:32:56 PM : [iNST-ACK    ] 02 62 14.06.CC 0F 6A 20 06                 (20)

Mon 03/22/2010 05:32:57 PM : [iNST-SRX    ] 02 50 14.06.CC 0C.A5.8D 23 6A 20           (20)

Mon 03/22/2010 05:32:57 PM : [standard-Direct Ack][14.06.CC-->ISY/PLM Group=0] Max Hops=3, Hops Left=0

Mon 03/22/2010 05:32:57 PM : [iNST-SRX    ] 02 50 14.06.CC 0C.A5.8D 03 6A 9C           (9C)

Mon 03/22/2010 05:32:57 PM : [standard-Direct][14.06.CC-->ISY/PLM Group=0] Max Hops=3, Hops Left=0

Mon 03/22/2010 05:32:57 PM : [   14 6 CC 1]    CLISP  32

Mon 03/22/2010 05:32:57 PM : [   14 6 CC 1]   CLISPC 156

Mon 03/22/2010 05:32:57 PM : [   14 6 CC 1]   CLISPH  32

Mon 03/22/2010 05:33:16 PM : [iNST-ACK    ] 02 62 14.06.CC 0F 6D 94 06                 (94)

Mon 03/22/2010 05:33:17 PM : [iNST-SRX    ] 02 50 14.06.CC 0C.A5.8D 23 6D 94           (94)

Mon 03/22/2010 05:33:17 PM : [standard-Direct Ack][14.06.CC-->ISY/PLM Group=0] Max Hops=3, Hops Left=0

Mon 03/22/2010 05:33:17 PM : [   14 6 CC 1]    CLISP 148

Mon 03/22/2010 05:33:17 PM : [   14 6 CC 1]   CLISPH 148

Mon 03/22/2010 05:37:55 PM : [iNST-ACK    ] 02 62 14.06.CC 0F 6D 90 06                 (90)

Mon 03/22/2010 05:37:55 PM : [iNST-SRX    ] 02 50 14.06.CC 0C.A5.8D 23 6D 90           (90)

Mon 03/22/2010 05:37:55 PM : [standard-Direct Ack][14.06.CC-->ISY/PLM Group=0] Max Hops=3, Hops Left=0

Mon 03/22/2010 05:37:55 PM : [   14 6 CC 1]    CLISP 144

Mon 03/22/2010 05:37:55 PM : [   14 6 CC 1]   CLISPH 144

 

I also changed the setpoint from the thermostat, waited 5 minutes and the change was not reflected in the ISY. I manually queried the thermostat:

 

Mon 03/22/2010 05:56:55 PM : [iNST-ACK    ] 02 62 14.06.CC 0F 6A 00 06                 (00)

Mon 03/22/2010 05:56:55 PM : [iNST-SRX    ] 02 50 14.06.CC 0C.A5.8D 23 6A 94           (94)

Mon 03/22/2010 05:56:55 PM : [standard-Direct Ack][14.06.CC-->ISY/PLM Group=0] Max Hops=3, Hops Left=0

Mon 03/22/2010 05:56:55 PM : [   14 6 CC 1]       ST 148

Mon 03/22/2010 05:56:56 PM : [iNST-ACK    ] 02 62 14.06.CC 0F 6B 02 06                 (02)

Mon 03/22/2010 05:56:56 PM : [iNST-SRX    ] 02 50 14.06.CC 0C.A5.8D 23 6B 03           (03)

Mon 03/22/2010 05:56:56 PM : [standard-Direct Ack][14.06.CC-->ISY/PLM Group=0] Max Hops=3, Hops Left=0

Mon 03/22/2010 05:56:56 PM : [   14 6 CC 1]    CLIMD   3

Mon 03/22/2010 05:56:56 PM : [iNST-ACK    ] 02 62 14.06.CC 0F 6A 20 06                 (20)

Mon 03/22/2010 05:56:56 PM : [iNST-SRX    ] 02 50 14.06.CC 0C.A5.8D 23 6A 8E           (8E)

Mon 03/22/2010 05:56:56 PM : [standard-Direct Ack][14.06.CC-->ISY/PLM Group=0] Max Hops=3, Hops Left=0

Mon 03/22/2010 05:56:57 PM : [iNST-SRX    ] 02 50 14.06.CC 0C.A5.8D 02 6A 9A           (9A)

Mon 03/22/2010 05:56:57 PM : [standard-Direct][14.06.CC-->ISY/PLM Group=0] Max Hops=2, Hops Left=0

Mon 03/22/2010 05:56:57 PM : [   14 6 CC 1]    CLISP 142

Mon 03/22/2010 05:56:57 PM : [   14 6 CC 1]   CLISPC 154

Mon 03/22/2010 05:56:57 PM : [   14 6 CC 1]   CLISPH 142

Mon 03/22/2010 05:56:57 PM : [iNST-ACK    ] 02 62 14.06.CC 0F 6A 60 06                 (60)

Mon 03/22/2010 05:56:57 PM : [iNST-SRX    ] 02 50 14.06.CC 0C.A5.8D 23 6A 4C           (4C)

Mon 03/22/2010 05:56:57 PM : [standard-Direct Ack][14.06.CC-->ISY/PLM Group=0] Max Hops=3, Hops Left=0

Mon 03/22/2010 05:56:57 PM : [   14 6 CC 1]   CLIHUM  76

And the setpoint updated correctly in the ISY, but the fan still said "ON".

 

If I can query the thermostat and get the correct setpoints back, then the access point shouldn't be the problem since that proves 2-way communication between the ISY and the thermostat, right?

 

It still seems as though this thermostat isn't sending updates like it should.

 

Anything else to try?

Posted

Hi sceaton,

 

But, indeed you are getting setpoint changes from the thermostat:

Mon 03/22/2010 05:56:57 PM : [   14 6 CC 1]    CLISP 142 (Set point)

Mon 03/22/2010 05:56:57 PM : [   14 6 CC 1]   CLISPC 154 (Cool set point)

Mon 03/22/2010 05:56:57 PM : [   14 6 CC 1]   CLISPH 142 (Heat set point)

 

Do these not get reflected in the Admin Console on the thermostat's main node?

 

What are you are not getting is fan mode and the heat/cool calls.

 

Is this the only thermostat you have?

 

With kind regards,

Michel

Posted

Those setpoint updates came back only after I manually queried the thermostat from the Admin Console -- I didn't get them automagically after changing the setpoints on the thermostat.

 

It seems I'm never getting updates when the thermostat is supposed to send them "on its own". If I ask for them (query) it will respond (except the fan) but it not sending updates on its own accord.

 

Yes, this is the only thermostat. Do you think it or the adapter could be defective?

 

Thanks!

Posted

Hello sceaton,

 

Apologies for a tardy reply. You are correct, I didn't notice that.

 

If you are sure that you linked your thermostat at the OFF mode, then I have no choice but to suspect the thermostat dongle. This said, I am also wondering if you have thermostat from a batch with different firmware (this has happened before) ...

 

As such, although I do recommend replacing your thermostat, I am going to keep an eye out for others with the same issue.

 

With kind regards,

Michel

Posted

Following up on a previous question I posted.... Is there a way to programmatically turn on the LED of a KPL button (other than 'A') without turning on a scene in which the button is a controller? I believe I used to have the buttons in scenes as responders and could turn on the button by turning on the scene. Has this been lost in the newer KPLs or newer ISY firmware (KPL=V.36; ISY=2.7.12).

 

Requiring that the button be a controller is very limiting since the button can only be a controller in one scene and the entire scene must be turned on.

 

Maybe I'm missing something. Any help would be appreciated.

 

Scott

Posted

Hi ScottK,

 

I am not certain I understand the question since you can always add KPL buttons as responders to as many scenes as you may wish. And, there's no limitation of the buttons to have to be controllers.

 

With kind regards,

Michel

Posted

Michel,

 

If the KPL button is a responder in the scene and a program turns the scene on, the KPL button (LED) does not turn on. Is this something specific about my configuration? (if the button is a controller, it does indeed turn on).

 

I have a button as a controller in a scene. I want to be able to turn the button on/off independent of the scene. I created a separate scene with the button as a responder hoping to use this scene to turn on the button but it doesn't do it.

 

Scott

Posted

ScottK,

 

It should turn on/off when you activate/deactivate the scene regardless of controller/responder. I recommend doing a restore on your KPL.

 

If that does not help, please do a compare between ISY/KPL links. Last resort: factory reset your KPL and then restore from ISY.

 

With kind regards,

Michel

Michel,

 

If the KPL button is a responder in the scene and a program turns the scene on, the KPL button (LED) does not turn on. Is this something specific about my configuration? (if the button is a controller, it does indeed turn on).

 

I have a button as a controller in a scene. I want to be able to turn the button on/off independent of the scene. I created a separate scene with the button as a responder hoping to use this scene to turn on the button but it doesn't do it.

 

Scott

Posted

Michel,

 

Restoring the KPL fixed my problem. Thanks!

 

The KPL worked in some scenes (where it was controller) so I made the (wrong) assumption that a restore wouldn't help.

 

Scott

  • 8 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing

    • No registered users viewing this page.
  • Forum Statistics

    • Total Topics
      37.2k
    • Total Posts
      372.5k
×
×
  • Create New...