stillwater

@lilyoyo1Thanks for the reality check! I agree with you (though the young Sheldon reference is beyond my detailed knowledge). Sorry for your headache!

"The only thing I can say is buy additional devices as they become available." Yes, and more may become available on ebay if Insteon owners panic and sell their stuff. Even if it's in the wrong color you can substitute your existing faceplates. The failure rate for individual (recent dual band) devices is not that high, and people who have been fixing PLM power sections (capacitor replacements) for long enough now to suggest high quality replacement caps should last a reasonably long time -- and can be replaced again. The other thing you can do is make sure you have a whole-house surge protector. What with "Matter" or whatever they are calling it now and Zwave 700 and RA3 things are really in flux. For reasonably small systems wifi with robust routers or a dedicated 2.4 GHZ router should be fine. I've looked closely at Shelly devices and though there are some things that make them hard to use (control lines not isolated from line voltage, and very scarce documentation even for basic things like what various button presses will do on the dimmers), they can be installed with no connection to the outside world the move to a scripting language in the Gen2 (Pro/Plus) devices and the existence of the low voltage Uni and the possibly low voltage I3/I4 input devices are promising as is the relatively quick development cycle time. I don't know if they will be around in 2 years but if they aren't someone else will be doing similar things with the ESP32 microcontroller that has built in wifi (and improved range and security compared to the ESP8266) . And for KPL replacements there are already DIY Raspberry PI devices with touch screens and also something like ELGATO Stream Deck mini (tactile buttons with tiny controllable LCD images on each of them ) could also be promising. (People already have home assistant integration with stream deck ). Not to mention more expensive things like the Brilliant control system. The pieces are all over the place but we'll have to wait and see the best ways to put it together. I have a little construction project underway right now and for it I am going completely technology agnostic by installing modern versions of retro 24v keypads (Kyle Touch Plate) that can be wired by low voltage to a central control unit and/or to distributed dimmers/relays (in this case Shellies with DIY isolated connections. I am pretty sure I can replicate the Insteon KPL pattern of button presses of toggling on/off brighten/dim with long push and maybe fast on/off as well.

@asbril I am very sorry that this has happened again. Did it happen immediately on plugging in the new amp? Did the speakers make noise? If so what? At least if it fried the amp immediately you have an immediate problem rather than an intermittent one -- easier to diagnose if so. Please don't do anything else until someone can get a meter on those speaker wires. Treat them as if they have house voltage on them until proven otherwise. (I know this is unlikely but so is the whole scenario!) Please check AC and DC volts to ground from each unconnected speaker wire, and AC and DC volts between each pair. Check resistance of each pair and between pairs. (It's possible that the two channels are bridged by the speaker wires which could cause certain types of amps to fail. ) Your expert may also be able to learn something by taking apart the failed amp and seeing whether damage is in the power supply section or elsewhere. (it's possible that the amp has an internal fuse or fuses and if so can be brought back to life). Then before reconnecting any amp. (assuming you haven't found the problem from the voltage and appropriate resistances), to protect the new amp. : - have it at minimum volume if it has a voiume control - short the inputs to signal ground using analog inputs. - As someone else suggested, put an 8 ohm resistor in series with each channel (or even better a 4 ohm resistor in series with each side of each channel. Also if the voltage/resistance tests are good, consider replacing the speakers as the source of a weird intermittent problem. (What kind of speakers are they? If they have a tweeter they may have a misbehaving cross-over network) . Good Luck!

@Techman I just checked. You are correct, at least mostly. At least in one instance on 5.3.4. ISY did not delete the device from the program as listed. The name was still there. However the program did not run and the lines in the IF and Then sections needed to be updated and the program saved for it to work.

I am not positive but based on limited recent experience programs should still work as long as the added device has the same name in ISY as the old one. But yes if the ISY links table is the problem you'd have to manually add the re-added device to the scenes. Do you have a recent back-up from before the problem appeared? Restoring ISY from that backup that and then restoring the KPL device from the ISY inks table could test whether there could be some problem in the ISY links table. It would not be dispositive if the problem is caused by corrupting something in the KPL's internal program as as a byproduct of restoring a valid link table to the device If you want to try removing and re-adding the device you could do a backup first and then if it doesn't turn out to fix the problem (before adding back all the scenes) you could just restore the system from backup and restore the device and you'd be back to where you are now. OH -- before doing anything more with the KPL -- Did you try doing a factory reset of the PLM and restoring the PLM link table from the ISY? Perhaps a corrupt PLM link table is the source of your problem.

I don't have any specific ideas for you but here is a story that may give you hope: I noticed that a 2477s that controls a bathroom exhaust fan was acting strange -- a tap of the "on" part of the paddle when the switch was already on would turn it off. This was true irrespective of program or scene membership, The communications log showed only a DON message from the switch, as you would expect. On a factory reset of the switch it would behave normally. Restoring device from ISY would restore the weird behavior. Deleting the device from ISY, doing a factory reset of the device, and linking to the device all over again fixed the problem (at least for now). I don't know if there was something strange in the ISY links table or if the act of writing the links table to the switch was making it misbehave. (Or something else...)

Thanks. I looked a little further and it looks like the wired CO sensors would have to be replaced with wireless ones. I was looking for a conversion that would not entail adding any wireless elements. (Current RF is limited to the cellular network link) Probably just best to stick with Concord 4 (with LTE communicator) until it dies.

This isn't completely on topic but perhaps you ELK experts will help anyway. I know very little about alarm systems. Homeowner X is required by the insurance company to have an alarm system with central station reporting. X has a Concord4/Alarm.com system that was installed in 2015 to fill this requirement. It has no wireless sensors -- just wired door open/shut , wired smoke and heat alarms, and wired motion sensors. Interlogix has gone out of business. X has the module that uses 3G to communicate to alarm.com. 3G is going away at the end of 2022. X has reserved the LTE module for installation by a local alarm company (They had a few in stock -- not enough for all their customers, they say). This isn't a permanent solution, though probably I can help X fix any electronics that die for some time. There are no ionization detectors so I think none of the components has a fixed life. The local alarm company proposed converting to Qolsys with some sort of wireless bridge. This seems overly complex. They do install ELK but the what they quoted for a conversion seemed like what a whole system might cost, including sensors. ( I think $4600 -- this is not a huge house). Would ELK or another brand of alarm panel that reports to a central station be compatible with the existing sensors? X really doesn't want to have people going through the house replacing sensors. Replacing the Concord4 control interfaces at each of two entry doors would be fine if the new ones fit in the same size box. Connection to ISY would be nice but not necessary. So: Should X spend $500+ now for the new communicator and hope the system lasts for some time, or convert to another system now, hopefully one that can use the existing sensors? If so which one? Thanks!

Slow ramp rate is probably set on for the specific controller as part of a scene definition -- Go to the scene on the left pane of the admin console, click on the appropriate red controller entry, view entries in ACTION column, edit by clicking on the line and entering correct settings in boxes at bottom, click update and all should be fixed.

This thread explains how to use a Raspberry PI (could be a zero or an A) to bridge between the ISY and the USB 2448A7 if Polisy is not available to you for whatever reason. I looked into using a RP2040 based board (Pico, $4) but none of the software packages (C, micropython, circuit python) currently support host mode USB beyond HID class devices. https://forum.universal-devices.com/topic/32546-insteon-2448a7-raspberrypi-isy994/

Sure. Invisible link. Also who wants an extra keyboard and mouse? Added later: Why was I annoyed by this comparison (even if actual information had been provided and not just an assertion ? It isn't because of the misinformation provided (not just the fan but also a Pi4 or Pi400 can easily boot from a USB 3.1 SSD -- one of mine does.) It's for two reasons: 1) Even thought the PI 4 can drive 2 HDMI displays, most people on this forum aren't looking to use a Raspberry Pi as a general purpose (desktop substitute) computer or for doing machine learning or video processing or similar tasks for which computing power or large memory spaces are particularly relevant. Most people on this forum are interested in the PI as a relatively easy to use device that they can use to run Python programs or packages that can serve as integrators or translators for other digital devices. Compared to Microcontrollers the full linux system has advantages (for example high level drivers for hosting USB devices), and compared to most Linux boards the PI provides low level interfaces (SPI, I2C, UART serial, GPIO) not typically available on general purpose linux boxes. People on this forum already use a Windows machine or a Mac already to get to their ISY so they don't need a keyboard or mouse to access the PI. So comparison to some Quad core processor with a keyboard and mouse was irrelevant. 2) Even if some other vendor provides a marginally cheaper solution, buying a PI helps support a whole ecosystem that makes computing more accessible to a wide variety of people worldwide, including those who do need an inexpensive alternative to traditional desktop devices. For students and others who are not yet accomplished computer geeks, the community of PI users makes entree into the world of many types of computer use and "making" (including programming microcontrollers) much easier. Oh -- and by the way, the Raspberry PI people just eliminated the one major criticism people had about the official operating system by issuing an official 64 bit version of RaspiOS. They had held on to 32 bit OS to maintain commonality across older boards but so many proprietary linux packages are only available in 64 bit version that they accepted the need for change.

@larryllixI was just answering the originally posted question and did not think to discuss Polisy. I am sure you are right for the long run Polisy will be superior to adding on a Raspberry PI to ISY but the Polisy could be seen as a large investment for dipping a toe into Polyglot now.. What I said was helpful and accurate. I did not recommend purchasing anything directly from raspbberrypi.com -- the page I linked to has direct links to the Pi 4 boards at North American official suppliers that charge the MSRP for the boards. I specifically recommended Adafruit and Canakit but also have bought successfully from Sparkfun and Chicago Electronics Distributors. @io_guyis correct based on my experience. I have multiple Raspberry Pis and have never needed a fan. I did have one 3B that ran hotter than others but it was fine with just heatsinks. On the other hand I wasn't mining bitcoin... or trying to render video. It is simply untrue that a full-fledged pc can be had for the price of a raspberry pi 4b or Pi 400 +peripherals at anything close to official prices. I am sure you can find someone who will charge $400 for a Raspberry Pi but you can find people who will charge $400 for an Insteon switch also. The difference is we know that more Raspberry Pis are being produced.

All Raspberry PIs are in short supply owing to chip shortages and their use in commercial products. There are several approved dealers in North America that sell the boards at the official (low) prices. (They sell others as part of kits at what may be higher margins). If you go to the Raspberry PI official website and choose the model you want under the Hardware tab and the region that applies to you it will give you links to these official suppliers. EG https://www.raspberrypi.com/products/raspberry-pi-4-model-b/?variant=raspberry-pi-4-model-b-4gb Recently there were some Raspberry PI 4B 2 GB boards available at Adafruit but they sold out quickly and others available for delivery in a month at (I think) Canakit.... I do not have experience with Polyglot and thus can't comment on how much memory you will need. If you want to have the pi run with a display you'll want more than if you go "headless" and just ssh in from another computer. In fact the latest raspiOS (Bullseye) doesn't even install the new fancy display manager in boards with less than 4GB. (It installs an older one). I IMAGINE that polyglot would run fine on a Headless 2GB Pi 4 but you would want to confirm that from someone who knows or from official Polyglot info somewhere. If you are just getting started with rPI it's reasonable to get a starter kit with a case and a power supply and cables etc. I am familiar with and can recommend ones from Adafruit and Canakit. Probably others are fine also.

More likely to be a ground loop problem if the noise was steady 60 cycle hum than motorboating, but still hard to see how it would work perfectly and then fail dramatically. Also with only two devices connected to the powerline (amp and supply for the HDMI converter) most likely changing the way one or the other plug is plugged into the power (assuming at least one has an unpolarized plug) would likely change the amount of hum. Also this is line level input, not small signal like a dynamic microphone or a phono cartridge, so the hum would have to be really large to be audible at the amplifier. On the whole a classic ground loop problem seems hard to square with the situation and history.

No, no need. If I were you given the current shortage of Insteon devices I would clip the wire to the beeper and hope that it works otherwise.

Interesting. Did you try a factory reset of the "problematic" one?

I fixed the problem. For @dywicked this is what I found: I finally remembered to look at the screen in the admin console for the controller button in question. This isn't displayed on the main scene page -- you have to go to the controller button entry (in red) under the scene on the left main pane. On mine the communication type was somehow set to Default rather than Insteon. I changed it to Insteon (press Update after) and made sure that the entry in the main matrix for the load was set to 100% with the preferred ramp rate and not 9 minutes... @Michel Kohanim Never mind the previous question. It's likely the only problem was operator error...

Clutching at straws here -- before replacing the ISY I'd try the following 1) I assume you've tried rebooting the ISY? If not that's an easy thing to try 2) Maybe a new SD card? ( @Michel Kohanim would have a better idea whether this is a conceivable fix for the problem)

Based on the communication being sent it sounds like the program executed to that point, and so I doubt changing a variable will provide additional diagnostic utility. I think this is beyond my experience/expertise. It's hard to understand both why the failures of the two modes of communication started happening at the same time and why they are continuing. The Insteon issue could be a PLM failure but that doesn't explain the seeming failure of the network resource to execute properly.

Sounds like your ISY is on the whole time so I doubt it's an ISY power issue. If you test (manually run) the network resource that does the notification does that go through immediately? Maybe add a line to the program that increments a variable so you can confirm that the whole program executed? If you look at the ISY logs do they show appropriate device activation and communication?

Thanks @Michel Kohanim I just compared the ISY and Device links table for a currently offending KPL . It turns out there was a mismatch in one link. Doing a restore device cleared up the discrepancy (all links now read identical in the compare function) but did not change the behavior. Is it possible that the KPLs (not the PLM) or the KPL link tables in ISY have a limited capacity to store links and this symptom is the result of me trying to exceed this capacity? The "count" of links in this KPL is 103. The KPL in question has one scene (on button C) that includes the load that works fine in turning the load on and off and another, larger, scene (on button D) that also includes the load does not turn the load on and off when turned on/off from this KPL button D. The scene works fine when turned on/off from the admin console or from buttons on multiple other KPLs. Communication link type is set to Insteon for all scene elements. I've tried factory resets to everything. The only things (that I can think of) that I haven't tried are (a) reducing the number of buttons controlling the scene and (b) deleting the scene and recreating it.

The logs should give you some idea. It's possible the power supply (wall wart) is dying and the ISY is rebooting after some time, in which case replace the wall wart. Power supplies are the most common source of failure in electronics in my experience. Other than that I can't figure out what might be going wrong.

Looking through my emails I find that on December 31 2018 in a thread I opened called "KPL Scene weirdness" I said I couldn't be sure but that this behavior seemed to have started with an upgrade from version 4 to version 5. @IndyMike found similar behavior on his system and @Michel Kohanimresponded: "@IndyMike, Thanks so very much for the verification. #648. With kind regards, Michel" I thought at the time this meant that this was assigned a bug tracking # (648) but I don't know for sure that was what this meant I was able to make it sort of work by using the communications mode "Command" rather than "Insteon" but there was an annoying delay in turning on and off the load. It's also possible to program the ISY to monitor the buttons and correct the scene -- or to do the "scene" entirely as a program in ISY. All the obvious things did not work -- factory resetting the KPL, restoring the KPL from ISY, Restoring the PLM, changing the PLM, etc. did not work. The scene works from other KPLs and from the admin console. My system generally does not have communication problems. So it's just weird.

Conclusion of my saga, which may or may not be relevant to @tbuchber. I removed the 2477S that was making audible buzzing/ringing on insteon traffic. On the test bench in the basement it was maybe a little louder than the other v.43 2477S I had and quite a bit louder than the v.45 2477S but it was indeed the same noise -- coming from the main board and not the beeper. Possibly I had overtightened the screws on mounting and that or something else distorted the board or strengthened the acoustic coupling between the wall and the box. Anyway the replacement v.45 2477S installed there now is inaudible to the naked ear. I hope this experience is helpful to someone!

Assuming these are Insteon devices it sounds to me like a failing or failed PLM, or if your lucky just a corrupted PLM links table. (Assuming you haven't connected new electrical devices that is completely clobbering insteon signalling). If a failed PLM the problem is usually the power supply capacitors and there is a thread in the forum on how to replace them. At a minimum try unplugging the PLM and letting it cool, plug it in, reboot ISY. Could also try factory reset of PLM followed by Restore Modem (PLM) from the ISY Admin Console File Menu followed by reboot or restart of ISY. (This is all from memory -- others more expert than I will have better knowledge of procedures and sources of info, or you could try searching forums and/or wiki).