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?