srm

No open ports to the ISY. I send rest commands locally from some 8266 devices, but that's TCP. I'll open a ticket. Thanks for the input!

I've had several occasions where an ISY backup failed with messages "Could Not Create the Zip File" and "Could not Retrieve File /CONF/MAIL/NTCLIST.CFG". (I'm running firmware 5.3.4 on an ISY994I.) The most recent occurred just 5 weeks after the same problem led me to do a new install of firmware 5.3.4 onto a new High Endurance SD card followed by restoring a working backup. Telnetting into the ISY indicates that the NTCLIST.CFG file exists and has a size of 19122 bytes. However, many of my functioning backups don't include an NTCLIST.CFG file, so I presume I could create a backup of my current ISY programs if I simply delete the NTCLIST.CFG file from the SD card first. (The NTCLIST.CFG file seems to be a concatenation of all 334 of my email customization files (*.NTC)). Accordingly, I have three immediate questions: (1) Is there a way to delete a file from the SD card by Telnetting into the ISY? (2) If not, is there a way to do a safe shutdown of the ISY so I can then remove the SD card and delete the file using another computer. I'm always concerned that the SD card might become corrupted if I simply disconnect power from the ISY while it is running. (3) Does anyone know what might cause this repetitive problem so I can avoid it in the future. Thanks!

Is there a way to perform a safe shutdown of the ISY? I don't want to just disconnect power when the ISY might be writing to its SD card.

I didn't even know that WD made SD cards. But I now see that https://shop.westerndigital.com/ includes WD Purple Ultra Endurance microSD cards with "Card Health Status Monitoring Capability", as well as several SanDisk models, including "High Endurance" and "Max Endurance" models. When I restored my ISY last week, I used a SanDisk High Endurance model. I think that next time I'll try to find one with a spec sheet that specifically mentions Wear Leveling. WD and SanDisk both have "Industrial" models that use that terminology.

I suspect that my overuse of statements setting initial values of integer variables (about 100,000 times in a year) is the cause of an apparent SD card failure in my ISY. I present the reasons for this conclusion below. This post is not a request for help, but simply an effort to inform; however, comments are welcome (especially ones that may offer a different explanation for my problem). I had been running firmware v.5.0.16C for 11.5 months on a new SD card when this problem occurred. Here's what happened and my reasoning for attributing the problem to INIT TO statements. (1) About two weeks ago, I found that all attempts to backup my ISY failed with the following error messages: -- Could Not Retrieve File /CONF/VARINIT.1 -- Could Not Create the Zip File (2) I tried deleting the offending file through telenet using RF /CONF/VARINIT.1 based on a response by @Michel Kohanim to the blog post below regarding the same type of problem; however, the delete was unsuccessful and attempts to backup still failed. (3) Through telnet, I learned that the file /CONF/VARINIT.1 had zero length. I don't know whether the failure to delete was caused by the zero length of the file or whether both the zero length and the failure to delete were caused by SD card corruption. In any case, SD card corruption was suggested by @Michel Kohanim as likely cause in both the blog thread above and in another thread about a different zero-length file that had prevented backups. My solution was to start with a new, high-endurance SD card, upgrade to v.5.3.0, and restore from an earlier backup. However, I wondered about the cause of failure of a 1-year-old brand name (SanDisk Ultra) SD card (if it was a failure). (4) I'm assuming that the failed file, VARINIT.1, is used to store the initial (i.e., boot up) values of type-1 (Integer) variables and that it is rewritten every time my ISY runs a statement, {Variable} INIT TO ... I evaluated my ISY programs and concluded that I was executing such statements roughly 100,000 times per year for type-1 variables. That's a lot of rewrites to the same file. (5) I have not found recent authoritative information on the number of write cycles that an SD card can handle, but the 2003 SanDisk Secure Digital Card Product Manual v1.9 says the following under a section called endurance: "SanDisk SD Cards have an endurance specification for each sector of 100,000 writes typical... For instance, it would take over 10 years to wear out an area on the SD Card on which a file of any size (from 512 bytes to maximum capacity) was rewritten 3 times per hour, 8 hours a day, 365 days per year." If the VARINIT.1 file was always being rewritten to the same sectors, then my failure was right in line with the expected failure point based on that old SD spec. However, that out-of-date SanDisk manual, as well as more recent documents, also mention "wear leveling", which is supposed to ensure that a given physical sector isn't written to excessively. That might mean that those 100,000 writes were distributed across lots of sectors and should not have caused a failure. I should note that I also do a lot of data logging with the ISY, which involves a lot of writes--though in the form of appending to existing files rather than rewriting the same file. In any case, the facts that VARINIT.1 is the file that failed, and that my code wrote to it on the order of 100,000 times in the 11.5 months that the SD card was in service, suggests to me that those writes *might* have been responsible for the failure. I have now changed my code to reduce the use of INIT TO statements by about a factor of 10. Though this assessment is by no means conclusive, it is something to think about if you get carried away with using INIT TO statements like I did.

LeeG, The test you proposed was quite enlightening. I queried the Low Battery Node of a different motion sensor and got an Event-Viewer response just like you showed. However, when I queried the problem motion sensor's low-battery node, the Event Viewer showed nothing! Both of these motion sensors function reliably--communicating motion events to the ISY. Since I had used the ISY software to do a "replace" of the problem motion sensor with a brand new one and the problem was transferred to the new one, I think there is nothing wrong with the motion detector. Thus, your test seemed to show something wrong with the installation of this motion sensor into my ISY software, so I deleted the motion sensor from the ISY and from all programs, then re-installed it and added the "new" motion sensor nodes to back into my programs. When I right-clicked the low-battery node and selected query, the ISY's display of the node status went from blank to "OFF" and the Event Viewer responded as you had indicated. I think my problem is solved, but will reserve final judgment until after a few days of operation. Thanks everyone!

Xathros, Thanks for the reply. However, I had previously read the same advice on the forum and tried it (including again tonight). The status indicated by the ISY still shows ON. As I understand it from a previous thread, right-clicking and querying the low-battery node is supposed to reset the ISY's status for that node--without even communicating with the motion detector, but it doesn't happen in this case. I don't understand why. I did try the query approach two more times tonight, 5 minutes apart. The status indicated by the ISY still shows ON. I also re-measured the battery voltage--without disconnecting it from the motion sensor. My Fluke multimeter, which I believe to be accurate, measures the alkaline battery at 9.30 V. Other ideas?

The low-battery node for one of my Insteon 2842-222 motion sensors reported by my ISY994i is perpetually in the ON state (every time I check it). The ISY also receives low-battery messages to my ISY one to two times per day. I have followed guidance in other threads on this forum, which I’ve listed at the end of this message. Here’s what I’ve tried: -- Replacing the battery 4 times—always measuring the new battery voltage to confirm it was greater than 9 V. -- Querying all three device nodes (motion, dusk/dawn, and low-battery) both with and without placing the motion detector in linking mode. (Querying was done by right-clicking the device node and selecting Query.) -- Right clicking on the motion detector and selecting “Write updates to device”; -- Right clicking on the motion detector and selecting “Restore Device”; -- Performing factory reset on the motion detector (Remove battery for > 15 seconds; while pressing the set button, reattach the battery; wait for the LED will turn on; continue pressing the set button for 5 seconds and then release). -- Out of desperation, I even bought a new motion sensor, installed it (after testing the brand new battery that came with it) and then told the ISY software to replace the old motion detector with the new one. Amazingly, the low-battery state was apparently transferred to the new motion detector! -- With the new motion detector in place, I repeated the query tests above to no avail. For what it’s worth, the motion sensor exhibits only a single flash in response to motion. (This is true at least of the new motion sensor. I did not check the flashing behavior of the previous one.) Where have I gone wrong? Firmware version of ISY994i: UD994 v.4.4.6 Old motion sensor: Insteon 2842-222, 4814 Rev 2.6 New motion sensor: Insteon 2842-222, 1715 Rev 2.6 Other threads explored: http://forum.universal-devices.com/topic/15079-motion-sensor-low-battery-event-or-lack-thereof/ http://forum.universal-devices.com/topic/11115-how-to-monitor-for-low-battery-on-motion-detector/