stillwater

I am only offering a datapoint. Looking at my (smooth) ssh update/upgrade I find that my packages match the targets in @simplextech's log with the exception that my machine does not have pciids installed. So maybe that is the source of the problem people are experiencing? Again I am only offering data.

I upgraded via SSH without apparent problem (both PG2 and PG3 dashboards show up) but I wasn't running IoP or any nodeservers on Polisy before or after so perhaps not a very meaningful test...

Just got a Polisy and have some comments on the process just sort of fyi from someone new to polisy and polyglot. I mostly bought the polisy to future proof ISY/Insteon PLM combination from PLM or SD card failure. (Via usb plm or stick). So my intent was to just put it back in the box after I checked that it worked, and wait until IoP gets beyond ALPHA. I am NOT asking for troubleshooting or help -- just reporting my experience. I'm putting this on this thread because my positive suggestions relate to PG3. Caveats: (a) Because I wasn't making a permanent install I didn't initially set up a static IP address. Once I set one up in Polisy and in Router it didn't make much difference. Though Chrome did allow access (b) I didn't use with the ISY finder Experience: 1) Though I have a "modern router" (unifi edgerouter + unifi APs) i could not access the polisy using https://polisy on either chrome or opera browsers. (I could see on my router that it was indeed advertising the polisy name. ) Chrome also initially refused connection via the IP address owing to "scrambled" certificate.... I could access using Safari on MAC. Suggested work arounds (https://polisy.local and installing bonjour on a pc) made no difference. Also Putty on the pc wouldn't find the host polisy though it does find raspberry pis by hostname. Can ping raspberry pis by hostname (replies with suffix .local) but not polisy. Just weird but since I know its IP address it doesn't botehr me. 2) Polisy upgraded fine. I found it easier to SSH in rather than using the dashboard. Dashboard didn't always keep its promises on providing a second message if upgrade not required. So this didn't inspire confidence. 3) Despite looking at the wiki I could not find how to connect to PG3. Only by finding this thread did I discover I had to go to another port (3000). Since the wiki mentions PG3 how to access it should be included there too. 4) It was disconcerting that the default user/password combination still provides access via SSH and via PG3 dashboard even after password is reset to a different value via PG2 dashboard. I think the default behavior is that resetting the password in one place should reset the password in the other access modes as well. Since the stated plan is to get away from SSH the current behavior would leave the SSH access open forever via admin/admin. Not good! I hope this is useful to someone. Looking forward to moving from ISY994i to IoP when IoP and PG3 are more stable.

Use start.jnlp as detailed in the 5.34 upgrade instructions. Also upgrade to 5.3.4 which is the current release. See the first post on this page. https://forum.universal-devices.com/topic/33287-release-534-test-build-is-now-available/

Might as well upgrade to 5.3.4 (current release) at the same time. Follow instructions in the base post on this page: https://forum.universal-devices.com/topic/33287-release-534-test-build-is-now-available/

Hard to tell based on the very limited info you have provided but if it always happens at 3 am and you have the "Factory" Query all program set to run at 3 am (as many do) then I'd focus on the query all process -- first try disabling just that program and see what happens.

@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...)

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/

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?

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?

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.

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).

I took (what I thought was -- see "Partial Retraction", below) the previously offending (and thus replaced) 2477S apart. Without the case on it is pretty quiet but makes a buzz that is audible, especially with the stethoscope. I was able to confirm that there was no noise or vibration from the piezo electric noisemaker -- it's something on the main circuit board (not the RF daughter board). Probably it's a surface-mounted ceramic capacitor singing -- though I didn't look closely. Here is a reference about such "singing" capacitors and what can be done about them in designing printed circuit boards. (Unfortunately not much help for us) https://sound-au.com/pdf/acoustic_noise_MLCCs_TI.pdf Possibly some goo like the black rubber sold in hardware stores as an alternative to electrical tape would reduce the vibration at the board, or taking steps to decouple it acoustically from the wall box and the wall would help. Anyway it certainly has nothing to do with the ISY. Of course whether this is the same as the seemingly louder noise from the currently installed one I won't know for certain until I replace it with the the newer one. The one mounted in the wall box makes a more rounded tone but I think that is because of various things being vibrated and not the source noise at the device. Edit: Partial Retraction. I see from previous notes that I likely replaced the 2477S a little over a year ago for a completely different reason -- related to problems with the 2477s communications that were ultimately resolved by factory resetting the 2477D in the same box. So I really won't know much for certain about what is causing the noise in the currently installed 2447S until I replace it and test it on the bench. However the similarity of the sounds via the sterhoscope makes me pretty confident that the problem will be a louder version of the sounds I have heard in the other switchlincs. I will report back.

Thanks!

I do not believe that it's the piezo "beeper" that's making the noise, though this is possible. To be sure it would be good to know where it is on the pc board) I could look into removing or cutting into the case and feeling around with an insulated probe to see find the source of the vibration. Also more careful listening shows the one installed in the powder room that I thought was completely quiet actually makes more-or-less the same noise as the new-in-box v.45 2477S.

Further information -- Not sure I am much closer to solving the mystery but here is additional info: I located the v.43 switchlinc (for toilet fan) that I removed from the system more or less a year ago. This was indeed made toward the end of 2014. I hooked it up to a test harness to give it power (no load) and added it to the ISY (after yet another factory reset). With a stethoscope on the case I can hear a very quiet buzz on all insteon traffic through the case. Now this is located in a different place from when it was installed -- it may be on a different phase electrically and also in a different position re RF (in the toilet room the switchlinc has a 2477D right next to it, so that may be blasting RF and powerline signals right at it. I also have a new-in-box v.45 switchlinc manufactured in 2018. I did the same test with it and it makes the same buzzing --though even fainter. Neither seem anywhere near as loud as when the v43 switchlinc was installed in the wallbox. (or the current one). This may be because of mechanical resonance to the wall box or wires jammed into the box. But it seems a greater difference than I would have expected based on that. Based on the noise the switchlinc makes when switched remotely by ISY, it has a relay to control the load -- so I doubt the fact that it was connected (like yours) to an exhaust fan has anything to do with it. (If it did it could only be by feeding RF back into the case? ) Also looking at the circuit board through the clear case there does not seem to be much that could be affecting the resonances... though conceivably it might help to put some foam tape or some other sound deadening material on the case, and not fully tightening the screws attaching it to the wall box, or the screws attaching the faceplate to the device. Of course the less insteon traffic there is on your system the less you will notice the noises.. So reducing retries by fixing Comms problems and disabllng the Query All program (or rescheduling it for when you are unlikely to be in earshot of the switchlinc) may help if you can't eliminate the noise.

PS the noise from this switch is one reason I disabled the 3 am factory query all program. Both of the toilet fan switches are v.43 based on the banner in the administrative console.

I have had what sounds like the same problem for maybe a year. I first noticed it some years after original installation. Factory reset (followed by restore device with testing in between) didn't make a difference. Replacing the 2477s with another one of the same vintage (probably 2014 or 2015) , followed by factory reset, also didn't help. However I have another 2477s (probably also bought from Smarthome in 2014 or 2015 and also installed in 2015 ) in almost the exact same configuration in a powder room that is completely quiet. It switches the same model panasonic fan and the same electrician wired both -- but conceivably it could be something about the fan. I do not think this is the actual device beep but I could be wrong. With a stethoscope it sounds more like a buzzing/fritzing sound than a beep. It does occur whenever there is insteon traffic, not just traffic specifically for or from that device. Maybe there is a coil in the 2477d that is in contact with the case, or something like that. The switch is in a toilet room that is very small and for a long time I thought the noise was coming from the fan and not the switch, but it based on the stethoscope it does seem to be coming from the switch. If I were you I would indeed try replacing the 2477s and see if that makes a difference. I'd be very interested in what you find out. I tried to query the insteon engine for each of the two currently installed 2477s from the Admin Console to see if they are the same type of device -- I believe that in previous years this would give some sort of result on the screen. The query runs (there is a brief blue rectangle and a progress bar that goes by too quickly to read) but I don't see any results on the screen. I have 5.3.4 firmware and 5.3.4 UI.

@gzaharabove said "2448A7 holds half as many links as 2413U/S, so if you have a lot links in your current setup, you might want to go for 2413x. " I've seen this said elsewhere too. Smartlabs at one point said the 2413s/u could store 2000 links, but this seems to have been false. So maybe they have the same link memory capacity after all?