WayneW

previously: 02/07/2014 7:21 PM 03/03/2014 6:36 PM – garage entry 04/10/2014 7:53 PM – watching TV 08/14/2014 8:34 PM – garage entry 01/06/2015 7:17 PM – garage activity 994i v4.2.54 & 2413s v9B v1.B 1343 I do have one RemoteLinc, but nobody was near it in the majority of cases. I do not have any Insteon motion sensors, Insteon thermostats or other Insteon battery devices. I do have an Elk with the ISY module and hardwired motion or door activity does trigger some of my programs. I am working on cleaning up the rules involving the hardwired garage doors, hardwired motion sensors, powerline only lights & KPLs to reduce signal collisions, but virtually nothing in the garage is RF.

Thank You very much. I had heard of ISYlogger and it was in the back of my mind for if/when I started doing more with variables. But the ability to log programs will bump this way up my priority list.

Is that a question or a statement? Yes, I have them available, but I cannot see anything in the that documents when programs are run, but maybe I am not reading them right or looking in the right place. If that post was in regards to the "all on" aspect, then, no, I don't see anything in the logs related to the "all on". The GUI showed devices as they were before the "all on" occurred. Once I ran the "query all", the GUI much more accurately reflected the devices that were turned on.

Is there an audit log of when ISY programs have run? I know that the admin console displays the "last run time" and "last finish time", but I am looking for details of the previous program runs. The log (UDReport.txt) doesn't seem to document programs run, just the scene and device executions, which can lead to speculation about which actual program executed the actual events. Lacking a automatic log system, is there a way to "force" a comment/entry into the log (UDReport.txt) as a event line? This would allow me to self document when key or suspicious programs have run. BTW, this is investigation of another "all on" event last night. This particular "all on" might have been triggered by multiple simultaneous programs, so I am trying to determine what got triggered when forensically to see if I can programmatically reduce the likelihood of this trigger happening again. I know that this is not the root cause to all my "all on" events, but I am trying to prevent what I can.

My subscriptions are back. Thanks! I think the old actually got merged with the new, as I think I see new stuff that I wasn't subscribed on the old board. I also noticed that one of my threads is locked. snooping around it seems that all many pinned threads are locked. Is that intentional? Or is that some the thread author did? Seems to impact multiple authors, so I assume not the authors choice. http://forum.universal-devices.com/topic/7293-isylogger-latest-version-v062/ http://forum.universal-devices.com/topic/7664-devlink-latest-version-v071/ http://forum.universal-devices.com/topic/7045-elk-wiki-connection-troubleshooting/

I am not sure if I got counted as I first mentioned it many posts ago. Yes, all my old subscriptions are gone. New subscriptions/follows that I make seem to be working properly. I am sorry that bookmarks are lost, that was a nice way to find "good stuff" that wasn't active anymore, but I can do that in my browser, until the URLs break.

Did the bookmarks feature make the migration? That was probably a vendor specific feature that doesn't exist here? It looks like all thread subscriptions got dropped? Am I looking at this wrong or is there a way to get thos back? Losing both my bookmarks and subscriptions leaves me floundering for references that I had.

My version is the same as ferdies, v9B for the PLM. Purchased 12/02/2013 from SH.

Since I upgraded back in January, I have had ALL ON happen twice. Nothing obviously weird in the ISY log, that I saw. old: ISY-99i, 3.3.10, 2412 PLM new: ISY-994i, 4.1.2, 2413s PLM & power supply

The ISY assumes that the switch is on because the ISY turned the scene on. I suspect that you could add a query of the switch with some retry logic in your program, but I would be afraid of an infinite loop. What if the switch failed to respond at all? If you did a manual query of the switch, the ISY would get properly updated with the switch status. But that requires you to see that the light is in the wrong state before you intervene. There is a fundamental difference between turning a scene on and turning a device on in that when a specific device is turned on, there is a method to make sure that the switch actually receives and responds. A scene is blind faith. Like the difference between TCP & UDP, if you are into networking. Also to clarify, Lee is perfectly correct. His post gets more to the "real" solution, whereas my method simply documents that something has gone wrong. IMHO, the best way to know that something is broken is to have it logged. Once you have a log, you can start to figure out a pattern or frequency. And determine how many resources should be devoted to fix the issue. Once a month issues are very hard to test & fix & confirm the fix. Daily issues are easier. To clarify, my first quote is a error handling separate program, not an addition to your program. Your program would become something like:

from viewtopic.php?f=27&t=13392&hilit=Java

IMHO, this is one of the weaknesses of Insteon scenes (the lack of a device error). My workaround was for add extra lines in the program to manually set critical items to the desired state. If the devices fails to respond to a direct command, then the ISY knows. Then I notify myself for logging & investigation. My notification:

Genius! Thank You! Actually, it wasn't an IP conflict, but when checking my router to confirm, I saw that my DHCP pool was all used up by visitors and new gadgets. Therefore the new 994i was the first device to not get an IP address when it asked... Murphy's law strikes again. So, after I expanded the DHCP pool, the ISY-994i booted properly and I was able to connect. I restored my backup, reset my lat/long/time stuff & user/password. And I am back on my static IP. I just had to boot back to the old unit to get the uuid to transfer my modules because I failed to write it down. Looks like everything is working fine now. Thanks a lot.

I am trying to upgrade my ISY and running into issues. have: ISY-99i, 3.3.10, static IP, 2412 PLM goal: ISY-994i & 2413s PLM & power supply I am aware of the Java issue and am using the 4.1.2 GUI as a workaround. First I tried to follow http://wiki.universal-devices.com/index ... r_ISY-994i and I kept my old PLM. I got the blinking MEM & ERR LEDs. I tried adding the power supply, no help. This page http://wiki.universal-devices.com/index ... tart_Guide says: Does the ISY-994i require something different on my router? Is this related to my ISY-99i using a static IP? I am using the same cables for my 99i and 994i. I have tried reseating the micro SD card. Every so often the blink pattern changes and the MEM LED does a short blink, while the ERR LED does a regular blink. Does this mean I have a file system error? I switched back to my ISY-99i, but added the 2413 PLM & power supply. I followed the "Replace PLM" instructions. That seemed to go OK. So, I am now running on the 99i and 2413. What do I need to do to migrate to the 994i?

re: Do you use the custom notification system to write to any file(s) on the ISY webserver? no, I don't use that (yet) and I don't even think that is supported on the version I am using. I haven't made the transition to the 994 and newer software yet. Of course, now that I have changed my SMTP provider to Gmail AND increased the timeout to 5000 ms, I haven't had any SMTP issues in 4 days, so hopefully I won't have a need to look at the error log for a long time. My error log is about 2 MB. Is that an acceptable size? Or is it a best practice to clear it at a certain size?

Is there a way to force the flush? Would writing the log file twice in a row give better results? I consider my system to be pretty lightly loaded, so I have no idea what would prevent the log file from getting updated for over 9 hours. I find the 9-24 hour delay a bit of a challenge to interactive troubleshooting, but it is not the end of the world.

Yes, the clock on the ISY and the PC are correct. I don't know where the time in the filename comes from from, I assumed it was the ISY, but it could be the local PC. But they seem to match, so i don't think the filename time is the error. And I have seen this happen multiple times where I go look for an SMTP error as I had a hunch I was missing an email, but there was no SMTP error logged, but then a few days later, when it happens again, I now see the error entry for the first SMTP error I was looking for.

Is it expected/common for the error log to not be complete & up to date? For example, the last entry in file ISY Error Log.v3.3.10__Wed 2013.11.06 11.22.43 PM.txt is Wed 2013/11/06 12:30:03 PM System -50001 -11 but the last entry in file ISY Error Log.v3.3.10__Thu 2013.11.07 02.51.47 PM.txt is Wed 2013/11/06 02:03:26 PM System -50001 -11 How come the 11/06 2:03:26 PM entry isn't in the file created 11/06 11:22:43 PM?

To close the loop on this thread, and hang my head in shame, I think I found the problem. I am using my own domain host for SMTP. But when I set up the ISY notifications, I failed to enter an SMTP user ID & password. I don't remember why, but it worked fine without it when I was testing it. Now I assume that was because Outlook (mine or the wifes) had been running the whole time I was testing. I had all email activity shut down overnight last night and tested my ISY notifications this morning. It failed, as expected, which was a good thing this time. I then added my username and password to the ISY, then I re-tested ISY, which worked. Thanks for the advice about using gmail, I will keep that in mind.

Ah ha! Sorry, i was following the instructions on the Wiki page, which don't lead to the actual .txt error log you desired. Maybe that wiki page can be updated to clarify what info comes from which log location? Guess when I was on vacation? Or more significantly, guess when I shut down my PC and Outlook? I highlighted the predictable emails that match the sample rule I gave earlier that fires at 12:30. Obviously, this shifts all the blame away from the ISY. I can only assume that my SMTP server no longer accepts emails from the ISY after Outlook has been off for "a while". I suspect that the last time that my Outlook was shut down for any long period of time was before I started sending emails from the ISY. Are there any SMTP experts that can confirm my timeout assumption? So, I guess I need to find another SMTP server, or figure out how to keep this one accepting mail (which I suspect is controlled by my webhost and I have no control over it). My thanks to everybody for the help so far.

I have no negative numbers at all in the second column of the Excel log. And no mention of SMTP in the log. I do have a few "-1" and "-2" in the "log type" column, but those all appear to be Insteon comm issues. There is nothing in the -50xxx range. My log goes back about 13 months. Thanks.

Thanks for the clarification and feedback. I have multiple programs that should have fired, so I am pretty confident that it isn't an error in one program, but a global issue is certainly a possibility. Is there anything that could have disabled all of my emailing programs without my knowledge? And then somehow re-enabled them as none of my email programs appear to be disabled now. Here is one program: Could my " 'email & cell' " choice be an issue? Is it best practice to make that two lines, one line for email and one line for cell? I believe that all of my email rules use the same distribution list concept.

Can you be more specific? What kind of program error? My programs are pretty simple and none of them should have acted any differently due to the vacation. In other words, there is no "vacation mode" logic involved. For example, one of my programs sends an email every weekday at a fixed time with the alarm status and some temperature readings. The ISY log shows that the last ISY startup was from a power glitch a few days before we left. So I am assuming that there was no reboot or lockup of the ISY while we were gone. The ISY log appears to indicate that the Insteon aspect was working properly while we were gone, but I am no expert at decoding the log. I do use my own SMTP server, not the UDI SMTP server. But this is the same SMTP server that I use for HomeSeer and Elk, so I don't think it is an SMTP issue, but I honestly don't know how to confirm.

We recently returned from a vacation. When we left the house, I got the expected email from the ISY that the Elk was armed. That was the last email I received from the ISY for a week. Once we returned, I connected to the ISY admin console and manually ran a "then" part of a program that sent the expected email correctly. While gone, I continued to receive emails from HomeSeer and my Elk, so I assume that the house had no obvious internet connectivity issues. I have no idea why I stopped receiving emails from the ISY, but this sounds very familiar to me. I recall that somebody reported something similar happened to them on a vacation, but I cannot remember if it was with an ISY or something else. I cannot remember the forum or source, and my searches have failed to find what I think I remember, but the proper keywords are elusive. The most obvious change to the house was the shutdown of all non-essential computers, but I don't understand how that would have any impact on the ISY. My ISY is configured to notify my cell phone (via SMS email gateway) & a traditional email address. Both failed for the one week period, so I am assuming the issue is on the sending side. Is this familiar to anybody? Is there any troubleshooting that I can do now? It works now, so if it ain't broke, it is hard to fix. Is there any way to prevent this?

try mms.att.net more discussion here viewtopic.php?f=7&t=10520&hilit=at%26amp%3Bt+sms