dex

I did a Rube Goldberg-esque experiment similar to this, mostly for a daylight basement that, on dark or cloudy winter days, stays too dark even when the rest of the house gets ample ambient through windows. I live in Oregon, and we do get a cloudy day every once in a while. ☂️ I access a personal weather station via the AmbientWeather node server (on Polisy) and then use the 'solar radiation' reading within a program to trigger "light" and "dark" responses based on an external brightness reported by the weather station. The correlation between external brightness and internal brightness was high enough that the desirable threshold was easy to find. The challenge: Depending on how often you poll for a new reading, you can get a lot of off-on-off-on, which can be annoying. I started playing with some hysteresis logic to avoid this annoying oscillation. That made it better, but I got busy with other things and haven't perfect it, as the value wasn't quite as high for me.

Show ISY Links Table responds quickly with the same results each time I do it. I haven't forensically gone through each of the 78 links, but there's nothing glaringly incorrect when I inspect list. Firmware and UI versions are 5.6.2. The KPL is v.45

Thanks, @MrBill. It was a pretty quiet time on the powerline network and I've watched the detailed log during the process. There were a few runs at this where I had no other Insteon traffic, but still saw the inaccurate link lists. That said, the behavior you describe (which is good to know about) strikes me as a flaw in how the link inventories are taken from a device. Some error-checking logic would be prudent, it seems. No?

I have a KPL that inconsistently reports device links when I choose Diagnostics -> Show Device Links Table. For example, I just ran that Device Links command 3 times over a 15-minute period. No changes were made to the system. No comms errors were reported. See the comparison in the attached image. The number of links in the KPL always comes up short of the 78 that should actually be there. On a few occasions, I get a "Record Missmatch" for a link or two. Never the same links, and it doesn't always happen. I've done it perhaps a dozen times this morning, and the device table is different each time. When I do the same for other devices in the system, no problem -- the table is repeatedly the same and matches the table in IoX (as I'd expect). I've done a complete factory reset and restore. There was no improvement; the link table is reported slightly different each time. Is this a communication issue that's not generating the "Cannot Communicate With ___" message? Could it be a bad sector of memory? Something else? Any troubleshooting tips before I spend $80 on a new KPL? I'm running 5.6.2 on Polisy.

@KConover I feel your pain. I am a user experience design leader, too. There are too many cringe-worthy aspects of the UI and interaction design of this system to count. I would love to see a brilliantly usable, beautiful system UI on all of this. It would be transformational for UDI to do so and would likely yield a substantial ROI through dramatic adoption and growth and greatly reduced per-user support costs. But I suspect the investment and commitment required may be out of reach or, more likely, not a priority for the UDI business. That said, my perception is that UDI's primary focus is to equip developers and solution integrators with robust advanced capabilities, leaving it to those folks to make robust, usable end-consumer experiences. Along the way, they also serve a substantial community of complexity-tolerant enthusiasts. I will say that @Michel Kohanim and team have a phenomenal track record of listening to this community and responding. Feedback like what you posted above is the kind of thing that can incrementally work its way into improvements here and there. It doesn't address the systemic Ux issues, but does help. - Dex

The Replace <olddevice> With command works well, in my experience. Unfortunately, I've had to use it a lot! I would estimate I've replaced 30 devices over the past 5 years; mostly first-generation Insteon (>10 years old). It's counter-intuitive, but before the Replace command shows up for a device, you must remove the device from its current folder. One tip: The name you choose for the new device is temporary, so I find it easiest to choose a name that sorts to the top of the device list. I use "0new" whenever I do this process (that's a zero). Then, when you choose Replace <olddevice> With, the new one will be right at the top of the list. After you confirm you want to replace the old device with the new one, the process can take several minutes. It's annoying, but after the Replace command completes, the Admin Console exits without any feedback or summary. Feels like it has crashed. When you restart the AC, move the new device (which will now have the original name) back into the folder from which you moved it at the beginning. Also note, if there were any communication issues while making the change, there could be pending updates for the device. If you see the little "11010" icon on the new device, be sure you right-click and choose Write Updates to Device.

I signed into Admin Console (5.6.0) and got a "System Busy" message saying "Started Z-Wave interview thread." I've never had any Z-wave devices, nor have I ever enabled Z-Wave support. I navigated to Configurations to check (screenshot below). This process took ~10 minutes, then disappeared and went to Ready state. Other than the hassle of waiting, I don't notice any other issues. Should this worry me that something might be configured incorrectly or corrupt?

My ISY configuration matches the Wiki instructions (localhost; http; 8080). Admin username and password match what's set in the Admin Console. I deleted and re-added the ISY on a few prior attempts to start from scratch. Each time the Polisy automatically discovered the ISY (IoP, of course) and the problem persisted. I think I made progress, though: I deleted the ISY again. This time, however, immediately after deleting it, I manually added it (ISYs > Add New ISY). The Node Server running on PG3 now shows up in the Admin Console. I think I'm up and running again. Thanks!

It appears PG3 is not fully communicating with my ISY (IoP). Two symptoms: If I try to reboot the ISY from the PG3 UI (System > Reboot ISY), I get an error "Failed to send reboot to ISY" (screenshot attached). If I add and configure node servers (following wiki instructions) and they show "connected" status in PG3, there is absolutely no sign of them in the IoP Admin Console. The Node Servers menu shows no node servers (screenshot attached). It feels like some authentication thing, so I've gone through all logins (Portal, PG3, IoP) to ensure they are entered carefully in all the places they are supposed to be entered. What are the pitfalls here that I may have missed? What else could be causing this? Thanks! - Dex Version: 3.1.11Status: ConnectedFrontend Version: 3.1.11ISY Version: 5.4.4

Restore Devices made no observable difference. Device events are not being seen by ISY unless the device is deleted and re-linked.

Thank you, @lilyoyo1. I have done factory resets and restores on individual devices and that still doesn't enable events to get through to ISY. UD (Michel) is having me do a full "Restore Devices" action that goes through all devices (ISY-99i/ISY-26 INSTEON:File Menu - Universal Devices, Inc. Wiki (universal-devices.com)

After my migration to IoP (5.4.4), none of my scenes would function from the ISY interface until I did the following... For each device right-click > Diagnostics > Query Insteon Engine Go into each scene and, for each device in the scene, at least click the "Update" button (in the lower section). For many scenes, I also had to provide the desired settings for that device for that scene. This seemed to trigger some final cleanup or configuration that then made the scenes function properly from ISY and from programs. This was quite tedious, but worked consistently on all scenes.

After several days of troubleshooting and experimenting, it's clear that device events (on, off, fast on, fast off, etc.) are not getting picked up by IoP. If I factory reset a device, then restore it, no change in behavior. If I delete a device, relink it, then restore it, then device events are seen by IoP -- it works! However, I have so many devices, scenes, and programs that doing a complete delete/add/reconfigure for everything in my system will take weeks (or more). In coming up with an approach to re-add devices to the system while preserving configuration details, I tried using a 'surrogate' device. 1. Add a same-type device to the system (the "surrogate"). 2. Replace the target device with the surrogate. 3. Re-add the target device back to the system. 4. Replace the surrogate with the target device. This mostly worked. I was able to use an extra dimmer switch as a surrogate for existing dimmer whose events are not seen by IoP. After the process, the target device's events are now being seen by IoP. The target device is also back in the original scenes and programs as it was before the process. The only anomaly I noticed was the "local" settings like on-level and ramp-rate did not survive the journey to the surrogate (temporary host) and back to the original. All other configuration seems to have made it as I had hoped. I've done this with a few devices, and it consistently works. Clearly there are things that happen when a device is initially added (linked) into the system that do not happen when restoring an existing device, even if you factory reset that device. So, here's a feature request for IoP: when executing a Restore Device function, provide an option to completely remove and relink the device. This new option would hold temporarily the device configuration (preserving links, scene membership, program references, etc.) but deletes and re-adds the device to IoP, then restores the saved configuration. It would likely take longer than a simple Restore, but take the device through the new linking procedure that seems to be critical in solving this problem. Might show up something like this (in the Restore Device dialog)... It's also semantically similar to Replace [device] with ... itself. Though that seems a convoluted place to put it in the UI. Am I missing a way to do this that already exists (short of a complete system reconfiguration)?

Well, I happen to have a dimmer switch wired so I can plug it in. I added it (new device) and all on/off events from that switch are seen by ISY, no matter where I plug it in in the house. With 180 nodes, deleting and reinstalling devices would take me days. Perhaps that's a last resort. I have factory-reset and restored devices and that does not seem to resolve the issue. I have also restored the PLM, but I haven't tried factory reset on the PLM before a restore. I think I'll try that next.

Thanks for the note on the UI issue, @Geddy. My firmware and UI versions are identical to yours. I power cycled the PLM again, this time waiting several minutes before booting Polisy. No change in behavior -- DON (Device On) and DOF (Device Off) messages are not being received from any dimmers, switches, or KPLs.

Also discovered that when I look at the Event Log via the Portal, I get this (with NaN in all of time/date fields). Device Control Value Time User 4F 85 64 1 ST Off NaN/NaN/NaN NaN:NaN:NaN System 5 0 null NaN/NaN/NaN NaN:NaN:NaN System 1 0 null NaN/NaN/NaN NaN:NaN:NaN System 1 A 94 26 1 ST Off NaN/NaN/NaN NaN:NaN:NaN System 5 A 94 26 1 OL 100% NaN/NaN/NaN NaN:NaN:NaN System 5 A 94 26 1 RR 4.5 secondsNaN/NaN/NaN NaN:NaN:NaN System 5 3E 99 B0 1 ST Off NaN/NaN/NaN NaN:NaN:NaN System 5 3E 99 B0 1 OL 100% NaN/NaN/NaN NaN:NaN:NaN System 5 [...] There are a few lines scattered throughout the log that look like this (long string of zeros). [...] 17 88 A5 1 ST Off NaN/NaN/NaN NaN:NaN:NaN System 5 3F BB 2 1 ST Off NaN/NaN/NaN NaN:NaN:NaN System 5 4B A0 E3 1 ERR 0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000NaN/NaN/NaN NaN:NaN:NaN System 5 4B A0 E3 1 NaN/NaN/NaN NaN:NaN:NaN System -2 43 9F 54 6 ST Off NaN/NaN/NaN NaN:NaN:NaN System 5 [...] Perhaps related? Perhaps yet another issue?

I have restored the KPL. I'm also seeing the lack of DON or DOF events from any physical press of a button on any device in the house. I did discover this Not sure what this means, but I assume some bad (or improperly formatted) memory?? I'm running Insteon on Polisy (5.4.4) using an upgrade SSD from UD about a week ago.

Thank you @MrBill! I haven’t had Insteon noise/interference issues for some time. I have several access points and mostly dual-band devices now. That said, are there any good tools these days for troubleshooting comm issues?

In the Event Viewer (set to Level 3 visibility) ... Program-triggered events: Yes Query events: Yes Motion Detector events: Yes Button events: No There are no events showing up from KPLs or dimmer switches. It appears this issue is not rooted at the KPL, but across all devices. Button-controlled scenes are working, the device-to-device signals are getting sent. But ISY is not picking any of them up. What could be causing this?

Prior to migrating to IoP (from ISY 994), the following was working. Now, buttons on KeypadLinc (KPL) do not trigger programs. For example, I have a button on a KPL dedicated to launch a "goodnight" program that sets several scenes and states. The button's toggle mode is set to Non-Toggle [Off]. Image attached. Here's the program that used to execute whenever this button was pressed: Goodnight - [ID 0012][Parent 0001] If '*LR Panel - H Goodnight' is switched Off Then Set 'Kitchen Bedtime' On Set 'Livingroom' Off Else - No Actions - (To add one, press 'Action') There were more 'then' program lines, but I have simplified the program while troubleshooting this issue. I have rebooted the IoP, done a factory reset/restore of the KPLs, and walked through every device option that I can see. I have three different KPSs with buttons and programs like this and none of them work. The 'last run time' (in the Summary tab for programs) doesn't show that any of these programs have run when I've pushed the respective buttons. What am I overlooking?

@MrBill I am using an Insteon Motion Sensor II. I have several of them and had them working just fine for a few years with ISY 994. Confusing Observations: I put an MSII into linking mode and then Query the device. Status: Battery Level: 80% Temperature: 70.3F Battery Powered: False Luminance: 59% The devices have a battery and it's even reporting a battery level, yet the Battery Powered state is False. That's puzzling. Since all of my MSIIs are working the same way, I have to believe the communication issue is something with the Polisy or IoP. Those are the only new things in the equation. Heartbeat Program I do not have a heartbeat program. Do MSIIs send a heartbeat pulse that could get received, even if motion events are not getting through? Or, do the motion events serve as a heartbeat? Just wondering what I'd learn from having such a program. And, is there a simple one you'd recommend? I do have several motion-detection programs. They are all pretty simple, such as this one... Gar Motion/Entry Lights On - [ID 000B][Parent 001A] If 'Garage Sensors / Garage 43 Motion' is switched On Or 'Garage Sensors / Garage 47 Motion' is switched On Or 'Garage Sensors / Garage 4D Motion' is switched On Then Set 'Garage / Garage Overheads' On Else - No Actions - (To add one, press 'Action')

@ISY4Me Have you discovered a fix for this? I am in a nearly identical situation. Migrated from ISY to ISY on Polisy (IoP) earlier this week and my insteon motion sensors (v. II) states/events are not being picked up. No pending updates (per @MrBill's suggestion). Plenty of dual-band coverage (per several commenters). All sensors are behaving the same way (7 of them). In linking mode they restore fine, they respond to Query, etc. When operating mode, the LED flickers with motion. When I do a Query (in linking mode) the admin interface instantly gets temperature, ambient luminance, etc., but Status and Battery Level are not reported. Is that possibly a clue? Any hunches or suggestions?

Perhaps one of the easiest approaches is to buy the RS232 port with wiring terminal, cut off one end of an ethernet cable and make the three connections needed. Amazon.com: YIOVVOM DB9 Breakout Connector to Wiring Terminal RS232 D-SUB Male Serial Adapters Port Breakout Board Solder-Free Module with case( Female Serial Adapter) : Electronics

Yep -- just search the web for "AWS outage" and there are many, many reports over the past 2-3 hours.

My Google devices are also now not responding to Alexa. This suggests the problem is on the Amazon side of things (AWS or things running on AWS).