stillwater

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?

I am confused about the max number of links on the various PLMs... Elsewhere in the forums the 2413s is reported to have a maximum of 992 links, which seems precise and based on knowledge (Search 992). So does the 2448a7 have order of magnitude 1000 link capacity, equal to the 2413s? If half of 992, then @waffles may have too many links to fit into the 2448a7? You see my confusion...

Thanks @mwester and @bumbershoot. Dyalog directly supports RPM- and DEB-based Linux distros and AIX (IBM Unix) but apparently not FreeBSD. So I'll stick to the raspberry PI (32 bit) and continue co-processing... Thanks!

I have an unusual motive for asking this question but the answers might be useful in other contexts also. 1) Is the BSD Operating System for the Polisy 32 bit or 64 bit? (Not the hardware) 2) Does the processor have a Floating Point Unit? My reason for asking is I am wondering whether I can install Dyalog APL for Unix. If not I can continue to use it on a Raspberry PI, which might be easier anyway. This motivates a third question: 3) Does the Polisy have any additional facilities (compared to the ISY 994i where I currently use the REST interface) for moving data back and forth to another computer (in this case a Raspberry PI) ? Thanks very much

+1

I haven't seen that. Did you unzip the firmware file before uploading to ISY? If so that would likely be the problem. ISY expects to install the still zipped file just as saved from the download.

Right click and "save as" either of the links on the first page that look like the following. Has always worked for me. 3. Download firmware - ISY 994i Series including Z-Wave support - ISY 994i ZW, Z, or ZS Series (Z-Wave/Zigbee and/or if you do NOT have a PLM)

I just triggered on time and reset the KPL brefore reenabling the program. It wouldn't surprise me if there are more elegant ways.

I don't see how a cumulative set of release notes would be possible because it would have to be different for each starting point. (Those upgrading from some 4.xx version would need something completely different from those upgrading from 5.0.16c). It's reasonable to expect that when the 5.x release is official UDI will release a guide for upgrading from the current 4.x official release but for those who already in some stage of 5.x how hard is it to look at the historical pages? Congrats to UDI on the certification and on being this close to an official 5.x release!

This is a low priority question and I apologize if I have misunderstood the state of play or missed a key message. It appears that the emphasis in 5.x RC2 and RC3 are on Zwave. At some point it would be good for those of us with no Zwave devices to be advised regarding what version above 5.0.16C has benefits for those without Zwave without undue novel risks from the Zwave-targeted changes. I am letting the dust settle but would be glad to upgrade when appropriate to increase the beta test base. In my experience versions 5.0.x have been stable for quite a while including many insteon devices, a small but important program base mostly migrated without undue problems from 4.7.3, a rudimentary home-brew local (Raspberry PI) node server, and lots of REST commands and network resources.

I believe @MrBill is correct about the unintended consequence of triggering when the portal goes down. The contention of @MWareman that the programs don't work to trigger on loss of local internet is empirically disproven by the fact that I have the programs @bmercier suggested working (with some modifications) to reboot my internet service ( using an insteon switch) when the ISY loses connectivity to the ISY portal. I also receive an email notification once the internet has restarted. It is true that I don't (and didn't expect to) receive email that the internet is out.

Thanks , @larryllix .I don't think anything happened that should have changed the status of just 3 nodes in the kpl without changing the state of the lights, unless perhaps cosmic rays or something... whatever happened either changed the state in the KPL without actually turning on the light or caused ISY to believe the state was ON when it wasn't. I should have queried the KPL manually but at 4 AM I probably wasn't think clearly. When I pressed the buttons on the KPL (even before factory reset) the lights and state in ISY changed appropriately. Last night's query went smoothly with no repetition of strange state changes. I've installed a fail safe program to prevent the state changes during the query from causing action, and correcting changes in button status that are incompatible with scenes during the period when programs are disabled, so at this point its mostly a curiosity. I did also change the program to be triggered by control rather than state, but I have no idea whether that would make a difference.

I can see from the ISY Event Log that when the Query All program ran 4 buttons (E,F,G,H) on a particular KPL changed their Status to ON in ISY. (However the lights in those buttons never turned on). Two of these buttons have zero role in my ISY programs or scenes. One (G) is a responder to a scene and also is tested in a program to open a window when the button is ON. I have seen other forum entries suggesting that a failing KPL or PLM or communication issues may be to blame. My insteon network is usually very reliable -- many nearby dual band devices, a phase bridge, noise generators/signal suckers isolated behind filters, etc. We did have recent power failures during which my UPS that powers the ISY ran out of battery, as well as lightning storms though my house is protected by various devices. I can turn off the program that opens the window during the time the Query All is active and reset the button to OFF in ISY based on the corresponding scene before reactivating the program, so I have already acted to avoid having the window open in the future. I have factory reset the KPL and restored from ISY. Will watch to see what happens in future nights. (Will set Event Log to level 3) My immediate question is: If I had tested in the program on the CONTROL is Switched ON rather than Status is ON would the change in Status in ISY based on Query ALL have triggered the program? I am running an ISY994i Pro with 5.0.16C RC1 though I doubt the software version is material here. Insteon devices through PLM and a home-brewed raspberry PI node server and various network resources and rest interconnections but no ZWAVE. I checked that nothing in the network interconnections was changing the state of the KPL or scenes. Thanks for any illumination on this.

Now it appears to be working normally (with an error log with only a couple of handfuls of lines)

Yes using the 16B console and firmware. Rebooting did not change anything. I clicked to clear the error log while the cursor was still rotating and the file menu appeared to save the log, and indeed the log was saved properly (with content back to October). The log was not cleared despite having said yes to clearing it. After the log was saved to a file then perhaps I was able to clear the log (when I tried to access the log after clearing it I get an error message (first could not access some portal file and then "request failed", which is the error it gives now. So I'll follow up later after it generates some content for the log (?). I see the last time I tried to generate an error log was on 5.0.15A on October 11 so I don't know when this behavior started

5.0.16B is working great for me ... with one possible exception... I have no reason to believe this is a problem specific to 5.0.16b but also no way to know it is more general. I tried to view the error log from the Tools menu in Admin Console and the cursor turns into a circular "working" icon but other than that nothing happens-- for over 9 hours... Admin console functionality is fully available with the funny cursor. I vaguely remember that some months back I increased the size of the error log so maybe the problem is related to that. I am open to any suggestions that would help diagnosis. I don't really have a serious need to look at the error log, so I could try to clear it and then see what happens. Happy New Year!