andrewm

Isy reports 2486D v.2C. for both devices. I see I added additional notes for the devices into Isy that say "Purchased: 12/12/2006. Re-flashed by SmartLabs Jan 2008". So they're old - I'm amazed they still work! I don't use button groupings but I can reset one of them and restore it and log the restore as well as any required additional delete/re-adds. Would that work for you?

That's correct.

This happened yet again to me on two different KPL devices over the last few days. I'm now using rev 4.2.1, and had a power outage here causing failures on 2 KPL requiring reset / restore (as also documented in this other thread). The link databases were compared after restore, but cross linked buttons in the same KPL didn't operate correctly and had to be deleted from scenes and re-added. Unfortunately I'd forgotten about this issue so didn't take logs.

Obviously if nothing was on a UPS it would be no problem. That's not the case for me. For historical reasons the Isy power supply (NOT the PLM) is plugged into a Synaccess Netbooter, which is shared by other devices and is in turn plugged into a UPS . The Netbooter can remotely power on/off the attached devices (which are not in a very convenient physical location) or even monitor and automatically reboot the Isy if network connectivity is lost to the Isy; this used to happen often for me, back when Isy was less stable. Tbh I don't know if it's still needed for monitoring, though the remote power control is useful if things lock up. I was hoping the PLM could provide (or Isy could infer from the PLM) poweron / poweroff events. Oh well, I can always improvise another solution. - Andrew

Thanks for responding. The PLM is not connected to the UPS. Your solution would fall under the "work around" I mentioned in the OP. I know that would be an option, but it wouldn't be the best solution for me.

We had a power outage today for a couple of hours, so we left the house and went out. I was initially surprised on returning as the power was back on but I had no lights on. However on further review I realized the ISY was operating correctly because its power supply is on a UPS (the PLM isn't). This made me wonder if there is any way the ISY can detect and raise events on power failure / recovery when its power supply is on a UPS and its PLM is not? Ie whether it can detect the PLM's state? Note in my case I don't want to move the ISY power supply from the UPS because it's actually connected to a multi-outlet Synaccess Netbooter, which provides services to the Isy and other devices. A work around could be to add an additional Insteon device that would send a power on status notification to the Isy, but that's less elegant and there's a danger that signal could get lost in the initial power-on noise.

Thanks. I'll look out for it.

It should be 3.2.6

We recently had a power outage here that resulted in me having to reset one of my KPL's and restore it. As expected from earlier in this thread the cross links didn't work post-restore, and required manual removal and re-creation. However this time I logged the restore operation, as requested by Michel, and have attached it. This was originally a 6-button KPL and now operates in 8-button mode. Iirc (I'm not near the device) buttons B, G & H all operate the local load (A) - others do as well, but I don't recall which off hand. Hope the log helps nail this one. - Andrew EventLog.zip

I did wonder if it was some sort of induction from the motor. The only hesitation I'd have on that is that I did see a correlation between the light-level and the requested fan speed. Hard to narrow down in the manner you suggest because it can't be reproduced on demand - it occurs only occasionally (for me). Assuming its a hardware problem, do you think this is common to all Fanlincs, or do we have faulty units?

Fanlinc experiences with 3.2.1 Mixed bag of results installing 2 new Fanlincs over the weekend, though no disasters. [*:1efvxq85]After adding each of the new devices, ISY showed the initial motor status as LOW, when the actual status was OFF. [*:1efvxq85]Neither Fanlincs would respond to scene commands after initial install, though they would respond to direct control from the ISY. Investigation showed the links table only had the ISY in there, not any of the scenes. After a few manual "Restore Devices" things worked OK. Seems a bit suspicious the same thing happened with both devices, but it could just be bad luck. [*:1efvxq85]Observed weird behavior on one of the Fanlincs, whereby the Fan light would occasionally come on at varying power levels, when the fan motor was being controlled. The motor control was being initiated from a RemoteLinc by way of ISY Programs/ State variables. This happened 3 times, but I couldn't reproduce it on demand, nor when I was capturing events! I don't know at this stage if this is an ISY issue or Fanlinc issue. Questions / suggestions: [*:1efvxq85]Can ISY be made to operate the internal Fanlinc beeper? This would be useful to provide feedback when changing speeds. [*:1efvxq85]Could I suggest using the word "motor" when auto-naming the device when it's added, rather than "fan". Reason being is that The root device name probably already includes "fan", in which case you end up with two new devices: (eg) "fan-light", and "fan-fan"! using ""motor" would makes things more obvious and less ambiguous.

Following is part of a set of 9 programs to handle cycling the fan speed. The ELSE conditions are unused so removed for brevity First set of programs controls the modifications to a state variable based on user actions from 2 RemoteLincs and 1 keypad. Only one button is used on each. State variable values are 0 to 3 representing the fan speeds off through high. RemoteLinc Key operations are: On - Turn on at last speed Off / Fast off - Turn off Fast On - Turn on at max speed Fade up - Step speed up to max Fade down - Step speed down to min KeypadLinc operations are identical except that both FADE UP and FADE DOWN step up the speed to max. This is because with KPL its difficult to know the fade direction #Program: Fan increase speed If ( Control 'Bedroom 1 / Remote 1 / Be1, Rem1 - KeyE: Fan' is switched Fade Up Or Control 'Bedroom 1 / Remote 2 / Be1, Rem2 - KeyE: Fan' is switched Fade Up Or Control 'Bedroom 1 / Keypad / Be1 - KeyF: Fan' is switched Fade Up Or Control 'Bedroom 1 / Keypad / Be1 - KeyF: Fan' is switched Fade Down ) And $sBed1FanState < 3 Then $sBed1FanState += 1 #Program: Fan-Decrease-Speed If ( Control 'Bedroom 1 / Remote 1 / Be1, Rem1 - KeyE: Fan' is switched Fade Down Or Control 'Bedroom 1 / Remote 2 / Be1, Rem2 - KeyE: Fan' is switched Fade Down ) And $sBed1FanState > 1 Then $sBed1FanState -= 1 #Fan turn on at max speed If Control 'Bedroom 1 / Remote 1 / Be1, Rem1 - KeyE: Fan' is switched Fast On Or Control 'Bedroom 1 / Remote 2 / Be1, Rem2 - KeyE: Fan' is switched Fast On Or Control 'Bedroom 1 / Keypad / Be1 - KeyF: Fan' is switched Fast On Then $sBed1FanState = 3 #Program: Fan turn on If Control 'Bedroom 1 / Remote 1 / Be1, Rem1 - KeyE: Fan' is switched On Or Control 'Bedroom 1 / Remote 2 / Be1, Rem2 - KeyE: Fan' is switched On Or Control 'Bedroom 1 / Keypad / Be1 - KeyF: Fan' is switched On Then $sBed1FanState = $iBed1FanOnValue #Program: Fan turn off If Control 'Bedroom 1 / Remote 1 / Be1, Rem1 - KeyE: Fan' is switched Off Or Control 'Bedroom 1 / Remote 1 / Be1, Rem1 - KeyE: Fan' is switched Fast Off Or Control 'Bedroom 1 / Remote 2 / Be1, Rem2 - KeyE: Fan' is switched Off Or Control 'Bedroom 1 / Remote 2 / Be1, Rem2 - KeyE: Fan' is switched Fast Off Or Control 'Bedroom 1 / Keypad / Be1 - KeyF: Fan' is switched Off Or Control 'Bedroom 1 / Keypad / Be1 - KeyF: Fan' is switched Fast Off Then $sBed1FanState = 0 Second set of programs has one program per state variable value and sets the fan speed appropriately. It also maintains the last ON state and any scenes to indicate fan state. Only one representativie on state is show here - the others are very similar. #Program: Set High Speed If $sBed1FanState is 3 Then Set 'Bedroom 1 / Be1 - Fan-Motor' High $iBed1FanOnValue = 3 Set Scene 'Bedroom 1 / Sc: Be1 Fan Status' On #Program: Set Off If $sBed1FanState is 0 Then Set 'Bedroom 1 / Be1 - Fan-Motor' Off Set Scene 'Bedroom 1 / Sc: Be1 Fan Status' Off

Hi Michel, 1. The device was added initially via ISY - I don't do any non-ISY linking! 2. I can't be 100% accurate on characterizing the misbehavior. Iirc one aspect was that button A failed to operate the local load, whereas button B (which is linked to button A) would; I know that makes no sense, but I've seen that behavior on more than one KPL. The KPL is in 8-button mode. Sorry, the earlier posts made me think it was being viewed as a feature rather than a bug, so I never thought to include logs. I'll have to remember in future if the problem recurs, or maybe purposefully factory reset a KPL and go through the procedure again but this time capturing logs. As things stand at the moment the devices are functioning correctly. - Andrew

I just got bitten by this one again on v3.1.17. Again I had a misbehaving KPL, so after verifying that the ISY & device link databases matched, I decided to reset the KPL to factory config then restore the device config from ISY. After doing this, the local "intra-KPL" button operations weren't working - eg pressing my master ALL AREA OFF button (H) didn't change the local load button (A), nor did it change the state of another button (D) which controls a separate linked device (though it did turn off the device itself). Everything else not related to intra-KPL links worked fine. So I deleted the KPL controller buttons from those scenes and re-added them as controllers and everything worked correctly including intra-KPL links. So the act of restoring the device fails to completely restore KPL functionality ("RESTORE"), but the subsequent act of deleting and re-adding the buttons as a scene controller succeeds in fully restoring capability("RE-ADD"). Earlier comments indicate that intra-KPL link functionality is not achieved using the regular device links table. This would seem to indicate ISY needs to be sending other commands as part of its device restore functionality in order to achieve success. The very fact that we can "re-add" the intra-KPL links manually via ISY shows that ISY has the capability to perform the required functionality. Having to manually delete and re-add controllers is a pita!

Actually I think you're on a slight slippery slope there, searching for devices, because the links table doesn't display "devices" - it displays a table of entries with each containing 8 unlabeled bytes. The format can be found, but isn't shown. Now if you were to identify / label the fields in the list, then searching for a device would make more sense - and would be extremely helpful. In fact that'd be true in many places in ISY - I go back to my earlier comment that for those of us who don't do this for a living, anything that can be done to make life easier would be appreciated; field labels / breakdown would be very helpful (incidentally it's another benefit of looking at the XML). As useful as this would be, it really this isn't getting at the main issue I was trying to solve in my original post, namely to find where things had got out of whack. A diagnostics tool to identify where the link database (even better, all the link databases) does not match ISY's Network representation, and to provide some assurance of "system integrity" would be invaluable.

I take your point, but actually I'd see hex representation as avoiding that situation, since it would make the associations with the Insteon device specs and your own link database listing more obvious. The current decimal format obscures those unnecessarily imo. As someone who only looks at this stuff only occasionally, ie I don't make a career of it but it's certainly within my capabilities, I have to relearn it every time I analyze an issue. And I'll use the tools I'm most familiar with to solve a problem. Anything that makes that process easier is to be encouraged! Thanks - Andrew

Sorry - meant to tell you I was on 3.1.16. I've since upgraded to 3.1.17 The link databases in both the KPL and IOLINC matched ISY's own records - there was no mismatch on those. The link was in the KPL link database but wasn't in the IOLINC's database (I don't think - I don't do this regularly), so I think the link was broken and the KPL was responding to the wrong group command. I don't know how the link became broken - I only ever link things via the ISY, but I had taken that device out of my network a year or so ago. Stuff happens! My point is that the KPL believed it was supposed to respond to the IOLINC, but there was no indication of that in ISY's Network tree (ie no scene) or diagnostic tool that I could run to compare (or evaluate) the link database against the network tree and help me identify the problematic link. Put another way, your link comparison tool makes sure that the ISY link database is in sync with the device's database. It doesn't verify that the ISY UI's representation of the network matches what is in the link database. That shouldn't happen, but it did in this case and I spotted it and could work it out. I wonder how many other similar issues I've got that I'm not noticing or just putting down to general flakiness - a diagnostic tool would answer that question. Point taken but it can serve a useful purpose because it's searchable and editable. I used it to search for a link to the IOLINC (after translating from hex address to decimal). I could also have edited it and reloaded it to fix the bad link (again I'd have had to do the numeric conversion). Creating the values in the doc as hex values should be low hanging fruit - I'd hope it would be pretty much zero overhead. Thanks, - Andrew

I had a situation where an IOLINC I installed was activating a KPL button light for no apparent reason. Deeper investigation revealed that there was an active entry in the KPL link database relating to the IOLINC; but this link didn't show up in the ISY Scenes - it was probably a remnant from some testing I did with the IOLINC a year or so ago. I didn't see a matching link entry in the IOLINC's database. The KPL link entry was as follows (annotated with hex values): 3936 (0f60) 162 (a2) 1 (01) 1243294 (12.f8.9e) 16719621 (ff.1f.05) The 162 (a2) value incorrectly indicates the link is in use. Note that the ISY database matched the device database. This was somewhat painful to diagnose and brings up a number of issues: The ISY diagnostics I know about didn't help catch this - it required manual examination. It seems like there should be an ability for the ISY to re-evaluate the link database and detect issues such as this, maybe using some technique similar to that used when adding a new device and keeping existing links. God knows how many other such "half-links" I have causing problems. I used the SAVE option from the link database dialog so I could examine / search the link database table in a text editor. The XML document ISY produces for this uses decimal values, which is at odds with the ISY UI, Insteon itself, and generally a pita! Can you not write this out using hex numbers?! The ability to search for a device in the ISY UI using it's Insteon address would be very helpful In the end I managed to get the database entry invalidated (by recreating the link in a scene and then deleting it) and everything's now working.

The only firewall running is Windows Firewall. I'd made no changes to my network since using ISY successfully earlier in the day. I don't remember when I last made changes to Windows Firewall - a long time ago. Attempting to access ISY now (my PC hasn't rebooted), and I get in first go. Go figure... maybe a timing issue. But there are really two issues here. First is a problem accessing the ISY - no biggie, s**t happens and hiccups can be tolerated. But the second is another usability issue in that I don't get an explicit indication telling me I have the first problem; I have to work it out for myself by eventually realizing things aren't working as I'd expect, then spotting the telltale 9-minute ramp time (which is a learned behavior requiring familiarity with ISY).

Yeah you're right - must be an older version of one of those I was reading - that RL I just installed had been sitting in a box for a long time. Nice how SmartHome move the goalposts! However, given that the ALL ON / ALL OFF command just uses the predefined group 255, ISY should still be able to setup other devices to respond to those ALL ON/OFF buttons, shouldn't it? And I see the event code on the ISY diagnostics log, so ISY programs should be able to be triggered from those button pushes.

And another issue - this condition I've seen several times, but never reported. I just logged in to the ISY, but the device status info is all incorrect (eg seeing on levels of zero, and maximum ramp rates). Additionally trying to query a device doesn't do anything (no progress bar is displayed). Looking at the error log gives me the following for the time period concerned: Sun 2010/10/10 01:07:58 AM System -5012 - Sun 2010/10/10 01:07:58 AM System -5012 - Sun 2010/10/10 01:07:58 AM System -5012 - Sun 2010/10/10 01:07:58 AM System -5011 uuid:00:03:f4:02:b0:0e,29 Sun 2010/10/10 01:07:58 AM System -5011 uuid:00:03:f4:02:b0:0e,29 Sun 2010/10/10 01:07:58 AM System -5011 uuid:00:03:f4:02:b0:0e,29 The last line repeats multiple times. I have to think the errors are related, but the info displayed is not helpful to me!

I just noticed an issue - it could be classified as a bug or feature request. The RemoteLinc product has ALL ON / OFF buttons which according to the docs can be linked to additional Insteon devices. However this functionality is not possibe from the ISY that I can see. In my case I'd use it to perform additional cleanup (eg turning off status lights on my keypads), either through scenes or through an event trigger

I used the usual http://your.isy.ip.address/admin form. OK, I thought that was the way it used to work (though I still think from a usability perspective the dialog should operate as I describe above). This wasn't a one-off... I tried multiple times, even rebooting, re-clearing Java cache, regenerating new self-signed certificate, always trusting the UDI certificate... I was getting quite frustrated because it was very late and I didn't want to have to revert. One observation (take with grain of salt, especially as I'm not connected to the ISY right now) is that it looks like your code-signing certificate has changed, as I had to re-add the certificate to my list of trusted certificates. Iirc, there was also some warning about the certificate validity. I confused this with the comment in your release notes about self-signed certificates, which is why I regenerated a new self-signed certificate for myself, to see if that would fix my device-add issue.

I don't know if something's changed in 2.8.2 wrt linking or whether I've not done it for a while, but either way the usability of the UI when you add a new device is poor. The New Insteon Device Dialog requires you to enter info in both the NAME field and ADDRESS field. If you leave the NAME field blank and press OK, then the dialog closes and nothing happens. I thought it used to default the NAME to the ADDRESS and continue with the linking, and that I had a problem with 2.8.2 The way the dialog should work is those two fields should be reversed. The first field to be entered should be the ADDRESS (because that cannot be inferred/defaulted), and once entered that should become the default value for the NAME field. At which point the user should be able to optionally overwrite the default with another name if they so choose. The OK button should be disabled until both fields have valid entries.

If a power-cycle is necessary I'd like to see ISY displaying a popup reminder to that effect. However I just tried air-gapping the KPL, and the crosslinks still aren't working. Thanks for the detail wrt the device links table vis-a-vis crosslinks. This raises the issue then that, while the ability to compare the ISY links with the device links is useful, it doesn't tell the whole story - eg, in this case these crosslinks won't be shown and therefore won't be verified. In which case, how are you supposed to diagnose this? At this point I think I'll work-round this partial-restore by just recreating the crosslinks manually in ISY. But lack of a reliable / verifiable restore is a PITA.