"button groupings migrated/accomplished through scenes...

[mwester]

There's definitely a bug with the way the ISY handles keypadlincs - and I suspect the frustration felt by some of the posters on this thread is rooted in whatever this bug might be.

 

Here's how you can tell if this is at the root of the problem -- select the keypadlinc in question, then in the diagnostics section, display the device links table.  When that dialog box is completely populated (it will take a while), there's a compare button at the bottom -- click that.  You've tripped this bug if the result of that comparison shows that there are differences between what the ISY thinks the links are, and what the device really has.

 

If that happens, the only reliable way to fix it, and to restore your sanity, is to use the "restore" option to rewrite the entire link database to the keypadlinc.  Then repeat the comparison above to confirm that this time the keypadlinc was updated completely and correctly.

 

(And to those who would tell me I have "bad communications", you might be right - although I find that the numerous test scenarios I've used, which include a benchtop setup, make that unlikely.  But even if it is "bad communications" the ISY should report that error and not leave a keypadlinc incompletely updated!)

 

Try it - see if that is the root cause.  I now compare each and every device affected when I make any changes to anything with the ISY - and my life has become a bit more tedious but a lot less frustrating as a result.

[EricK]

Scyto,

It appears that you are receiving great help and hopefully you will resolve your issues.  Sometimes things dont work as expected and there are ways to work around this with programs.  This can preserve your sanity.  I have an older keypad that needs a correction program to adjust some of the kpl buttons.

For you create 4 scenes with 3 buttons as responders (ABC, ABD, ACD, BCD)..

Create 4 programs.  First is IF status A is on then set scene BCD off.  Create one for each of the other buttons.  (

 

I think you will need some programs anyway to monitor your scene buttons.  For example if A is on and one of the scene members is changed then you probably want A to turn off.  Check this tutorial which describes very well how to do this:

http://www.adamsj.com/isy/basementA.htm

Eric

[Scyto]

Yes the help here is awesome.

 

Turning off automatic writes never helped - still had the issue that at the end of writes the green 'writes still needed' logo would still appear with a subsequent write to devices causing a red bang.

 

However by increasing the PLM retries from the default of 1 to 2 for all of the KPL items seems to have fixed this - though I will do more testing tonight on other keypads to confirm.

 

mweseter - yes I am seeing the same issues and seem to have an identical experience to what you describe, I have awesome Insteon dual band mesh - so I do not think the issue is general comms issues, more something along the way that the ISY chooses to write/read to these devices. but that is just an intuitive guess. 

 

I think I may have left level 3 logging on form before and after the KPL retries change - I will post the log when I get home tonight.

For you create 4 scenes with 3 buttons as responders (ABC, ABD, ACD, BCD)..

Create 4 programs.  First is IF status A is on then set scene BCD off.  Create one for each of the other buttons.  (

 

I think you will need some programs anyway to monitor your scene buttons.  For example if A is on and one of the scene members is changed then you probably want A to turn off.  Check this tutorial which describes very well how to do this:

http://www.adamsj.com/isy/basementA.htm

Eric

 

I don't need to appear to have a program to do this, I think I have it working without programs.

[LeeG]

Prior to SmartLabs introducing the I2CS variant of the Insteon protocol Insteon devices used a retry count of 3. This number was embedded in the device firmware and could not be adjusted. With I2CS devices there is control over some of the retry activity. Right click on device node, select Advanced | PLM Communication to access a retry count (available only on I2CS devices).

[EricK]

Scyto,

My thought about the monitoring was this.  You have three responders for your scenes, switchlinc dimmers I presume.  Say you hit B and the responders go to 50%.  Then you go to one of the dimmers and turn a light off.  Then your B scene is no longer in effect so most people would want the B KPL to turn off.  The monitoring program would be something like this.

If Switchlinc A is not 50% and B is not 50% and C is not 50%, then set scene KPL B off (where B is the responder of the KPL B scene). 

You may also need if A and B and C are 50% set scene KPL B on.

If you do not use the monitoring program then consider the toggle status of the ABCD buttons, toggle vs non-toggle on.  Or if you have inline or microlincs where you do not control loads individual then forget what I wrote.

Eric

[Scyto]

@EricK - ahh I get your point this is about the other responders that actually control the load.  Yes you are right if I fade up or down the dimmers or turn off the load then the A/B/C/D buttons don't reflect that.  so great suggestion on the monitoring program.  I will give that a go.

 

@Everyone Else - after more testing I think I can say that setting the PLM access retry count to 2 has cured all the comms issues to the , sped up writing to the KPL (2334-2's) and cured the strange behaviors where they didn't do what they were supposed to do.

 

---edit---

spoke too soon, while this fixed the issues with my KPL's in the bedroom it did not for the ones in the basement, I think it is either faulty unit or issue with my mesh - is it possible to work out if both the RF and on-wire comms paths are working?

 

---edit 2--

For the basement KPL relocating the PLM solved the issue, so I guess there was a mesh issue for that node