I am trying to troubleshoot a new "tick" my house has developed.  When we go to bed we press a button I call "bedtime" (MB Door Keypad 709BC0All On in the log).  It is used to start a program that shuts the house down, checks the alarm status, power grid status and if not in a power restricted status, turns on the thermostats which lately has turned on the A/C.  

I can see in the logs where everything shuts off and pretty quickly, it acts as if we "woke up", this requires one of three motion sensors to be triggered, the garage door to open, the alarm to be turned off or the "on" button on the keypad by my bed to be turned on.  We use the Off on the same keypad as the "bedtime button"

My guess was that it is the motion sensors when the AC kicks on but the logs don't show it so I feel like I am on the wrong path. The log shows the lights coming on and the keypad status changing from "off" to "on".  So I am also looking at spurious signals.  The on/off buttons on the 6 button keypad are not a responder or controller for any devices.  They are only used to trigger programs.

So is there a way to see the history of the programs during the night like a log?  The Programs summary tab only shows the last run. If I get up to walk to my office to look at the admin panel, the sensor runs the program to wake the house up and that is the "last run".  

718 log.pdf

So is there a way to see the history of the programs during the night like a log?

The short answer is no.

Bummer, at least now I don't feel like I was missing a simple source of data.  I will keep troubleshooting.  If it happened every night or if I knew a certain sensor was doing it, that would be great, but the log doesn't have the same status changes in the same order when it happened last night several times.

Hopefully the flush after the upgrade today helps.  If not I will unplug my keypad (tabletop mount) and see what that does.

 

3 hours ago, CoolToys said:

My guess was that it is the motion sensors when the AC kicks on but the logs don't show it so I feel like I am on the wrong path. The log shows the lights coming on and the keypad status changing from "off" to "on".  So I am also looking at spurious signals.  The on/off buttons on the 6 button keypad are not a responder or controller for any devices.  They are only used to trigger programs.

So is there a way to see the history of the programs during the night like a log?  The Programs summary tab only shows the last run. If I get up to walk to my office to look at the admin panel, the sensor runs the program to wake the house up and that is the "last run".  

718 log.pdf 616.93 kB · 1 download

As @Techman indicated, the logs do not identify programs for Insteon device (I get program identifications for X10, but that's not helpful here).

On the flip side, you should absolutely be able to see motion sensor On/Off activity in your logs.  I don't see that type of activity in the file you posted.  Actually, I can't identify a program trigger in the file.

If you could post your program, we might be able to assist further.

Yes, I also suggest posting the goodnight program as well as the wake up program(s).

I am still running an older ISY994 running ver 5.0.15 firmware and noticed that some IR sensor on/off activations do not show in the log.

I have 8 IR sensors total and 6 of those 8 report all on/off actions to the log.  Those 6 are configured to only trigger at night.

The 2 that do not report to the log are configured to be active both night and day and send On only.   I have found that a little frustrating when trying to debug program issues.   I am not sure why that the lack of reporting happens for that configuration. I always assumed it was a bug that was fixed in newer releases but perhaps not? 

Edited July 19, 20241 yr by ELA

@ELA

Can you post a copy of a program that's not working correctly.

Techman

No I am not asking for assistance in debugging programs.

I was sharing that two of my  IR sensors, that are configured to report both day and night, and to send only the ON command,  do not show up in the log.   That fact can make debugging more complicated.

I am just a little curious if that particular IR configuration, coupled with certain firmware versions, and failing to report to the log,  is unique or if others may also have experienced this.

 

Edited July 20, 20241 yr by ELA

@ELA

Can you post the program for one of the sensors that are active both day and night but that doesn't show up in the log.

Are all the IR sensors identical, i.e. same manufacturer, same version.

 

Techman,

   What I was sharing has nothing to do with programs.

The older style MS Sensor by default sends both ON and OFF commands.

Link the MS sensor to the PLM via ISY994 - no programs created.

Activate the sensor several times and read the excel log. You see both On and Off commands logged.

Install jumper #4 for ON only mode.

Activate the sensor several times and note that the log contains no commands from the MS sensor.

This is what occurs in my ISY994 rev 5.0.15 firmware.  I have always assumed this was a bug in the ISY firmware and that it was likely fixed in later versions.

 I was curious if this might be the case in the EISY and its versions of firmware or if it has been fixed.

 

Edited July 21, 20241 yr by ELA

@ELA

Is the issue with IR sensors (infrared sensor) or Motion Sensors?

If it's with the motion sensors, are you referring to the older Motion Sensor 1 or the Motion Sensor 2?

If you're referring to the older Motion Sensor you should have Jumper 5 (remote management) installed

Edited July 21, 20241 yr by Techman

21 hours ago, Techman said:

@ELA

Is the issue with IR sensors (infrared sensor) or Motion Sensors? P(IR) or MS

If it's with the motion sensors, are you referring to the older Motion Sensor 1 or the Motion Sensor 2? old style 1 MS

If you're referring to the older Motion Sensor you should have Jumper 5 (remote management) installed Why- has no affect on  this issue.

No need to respond any further

 

Install jumper 5 (remote management)

Select ON commands only in the ISY

Put the sensor into linking mode and then click on write updates to device.  The ON command should then show up in the log.

 

 

@Techman, I don't believe you are understanding the point that @ELA is trying to make.

If you configure your Motion sensor for "ON Only" commands, the Log will show ONLY the 1st on command.  Following 'ON" commands will NOT show up in the log. 

Please do try this for yourself...

The ISY LOG resembles a state machine.  If a device (relay, door switch, motion sensor) turns on 40x and off 1x the log will show 2 entries.  Dimming devices are different due to the 255 different states they can attain.

ELA is EXACTLY correct in saying that he doesn't have motion sensor entries in the log.  The initial "on" may have been many months ago (years?) when the ISY was last re-booted.

@IndyMike

My thinking was that link tables may be missing. He never mentioned whether or not the admin console showed the on status when the sensor was activated, If so then it should also show up in the log.

2 hours ago, Techman said:

@IndyMike

My thinking was that link tables may be missing. He never mentioned whether or not the admin console showed the on status when the sensor was activated, If so then it should also show up in the log.

@Techman, I understand the thought process.  The fact that multiple (repetitive) on commands are NOT recorded in the logs is not intuitive.  Some would call it a bug (or a feature).

Regardless, I would encourage everyone to try this for themselves to understand how/what events are logged.  Events that show up in the "Event Viewer" do not necessarily show up in the logs.  It's confusing until you gain a knowledge of how the ISY treats events and triggers. 

...and I will confess to re-learning from time to time...

Hello all, Thanks for the responses, and I found the issue.  @IndyMike is correct there weren't any sensor activations in the logs and unlike Ela's problem my sensors do show in the log so I stopped looking down that path.  It took watching both the logs, the event viewer and keeping my laptop next to the bed to find it.  But as Yoda would say "Fixed, problem it is".

What I found:

Button C on one of the 5 button keypads by the bed was a responder to the front lights being on.  The idea was if the front lights came on because someone entered the gate we had a visual since the "siren" as a doorbell is highly unreliable.  In my office I use the center four buttons to show me motion at each of the four sensors.  When one is activated the light is on.  Makes it easy to find the dog or see if someone comes in the house while I am working.

July 3rd I set the front yard lights to remain on from sunset to sunrise so we could leave a flag up correctly for the entire 4th weekend.  This was activating that keypad, which in turn changed a state of the Master Door Keypad back to On that I did notice in the logs.  It was confusing, but if you look at the log I posted it looks like I pressed the "on" side of the same keypad I just pressed "off".  I thought motion at first because of the A.C. coming on.  I think the timing was somewhat random due to the PLM and communications limitations.  

I did remember that I had once added a program so that if someone showed up at our gate after "bedtime" that the lights in our room would come on to alert us.  I saw that program get a green stripe in the admin panel just after pressing the "off" to activate "bedtime".  

The solution was to remove the .c key as a responder to the front lights.  I did some testing and for some reason if any of the 4 middle buttons are "on" the state of "master keypad" returns to on. The keypad is Keypadlinc Dimmer 5 buttons v.45.  

I don't really understand this because the .b.c.d. keys should be read independently.  I have upgraded to 5.8.4 and will retest or try to find another way that it can all work.  I also have a spare keypad, but there could also be a spurious signal where the .c of the keypad address isn't being received.  I have had noise issues with Cyberpower surge protectors and thought I had it all cleaned up, but maybe not.  For now I have had two nights of good sleep.

 

7 hours ago, CoolToys said:

The solution was to remove the .c key as a responder to the front lights.  I did some testing and for some reason if any of the 4 middle buttons are "on" the state of "master keypad" returns to on. The keypad is Keypadlinc Dimmer 5 buttons v.45.  

I don't really understand this because the .b.c.d. keys should be read independently.  I have upgraded to 5.8.4 and will retest or try to find another way that it can all work.  I also have a spare keypad, but there could also be a spurious signal where the .c of the keypad address isn't being received.  I have had noise issues with Cyberpower surge protectors and thought I had it all cleaned up, but maybe not.  For now I have had two nights of good sleep.

 

@CoolToys, If I understand you correctly, your KPL C button was a scene responder and in turn activating the KPL A button.  That is very odd unless there is another program involved (something that monitors the C button status), or possibly the buttons are manually linked or buttons are grouped.  I don't have experience with button grouping. 

You can search for programs that might operate on the KPL A button.  Manual links should show up if you do a device link table scan/compare.  I am not sure how button grouping would show up.  You may need to factory rest/restore the KPL to delete.

@IndyMike. Sort of, the KPL C by the bed was simply a responder so I got a polite alert of someone at the gate.  We use a KPL in the office to see motion in the house. Each sensor lights up a key while it is on.  I found it an easy way to find our previous dog based on motion when she was going deaf.  I don't know why it activated the A button, but removing it from the scene fixed it for a while but....

Well, now it gets fun.  After a few months of flawless operation, the lights have a mind of their own again.   I went through this list until I caved and unplugged the plm.  I wish I could blame the white hat hacker next door but I am sure this is me again.  Only program changed since last time this appeared fixed was an auto garage light and that was a week ago.  I changed the duration the light was on and removed a trigger from the if statement.

Here are todays logs and as requested the "bedtime" program.  The error at the end is the time of wife tolerance limit and PLM unplugging.  I included last nights logs showing what happened.  The error in my office is sporadic, and I have replaced the outlet with the new i3 and added a dual mode switch to control it on the same phase and still have comm errors from time to time.  It was way worse with Cyberpower UPS in the house.

Here it is.

I pressed the "bedtime" button at 9:23, "Kelly Watch Winder" is off.  That is at the top of the program so I know the eisy/plm "heard" the command.  The lights started coming back on so at 9:41 I set the alarm and tried again.

The hallway curio is the first device that turns off and right back on at 9:23 and again after the alarm set and I press bedtime again at 9:43:56.  The "MB Door Keypad 70.9BC0Foyer" button does also change from off to on which was the issue I fixed before by removing it from the "front lights" scene.  I also notice later that the MB Window Keypad.Office and .Stairs come on.  Almost like the programming rolled back.  .Stairs should only light up when the stair motion is on. and then the closet.stairs should come on as well and it does not so this makes little sense.  The thermostat is changing from "night" to "day" temps also at the end which is odd.

After I try and get some sleep, I will plug the PLM back in.  This is a new MB Door Keypad btw.  I replaced it as a precaution last time, so this is very likely another "feature" I accidentally programmed in, or created by a manual link.  Again I will check after some sleep, you can see the lights have been turning on for hours, and not in any consistent way like a program running.   Unlike other threads, this isn't hourly and I don't see a pattern yet.

I left the program in .iox since I can't seem to copy in a readable format.  There is as much as I can put in a screenshot here too.  I thought the export feature would let me paste a formatted version, but it created a solid blob. I use a Mac so was hoping to drag copy paste, but... there I go again wanting things to work the apple way. 

BedTime.v5.8.4__Wed 2024.09.11 02.30.00 AM.iox UDReport truckated.pdf UDReportNormalNight.pdf

Edited September 11, 20241 yr by CoolToys
typo

Hey @CoolToys, sorry to hear that problems are rearing their heads again.

I looked over your logs.  There's a couple of things that I see, and some that I don't:

1. I do not see a trigger for your program.  Neither your "MB Window Keypad.ON" nor your "MB Door Keypad 70 9B C0All On" show as having been switched on.  It's possible that you have these set as Non-Toggle On.  In this case the Log would only show the 1st on event.  Please confirm.
2. Your HallwayOutletCurio is showing a "ON" status and is immediately followed by an "ON".  This can sometimes happen when a device like a lamplinc is connected to a non-resistive load.  The load can provide and electrical kick-back and fool the lamplinc into thinking it has turned back on.  Please confirm the device type and model.  Turn off the local load sensing if equipped.
3. You have many devices and scenes in your program.  11 devices and being addressed individually and you are using 17 additional scenes.  Why not put all of them in a single "bedtime" scene and issue a single "fast off" command?  This would eliminate a ton of communication and program waits.  Are you experiencing issues communicating to some of the devices?

Beyond the above, I would guess that you have another program that is being activated and turning (some) things back on.  Look at the program summary tab for programs that have run in the same timeframe.  You can sort by "Last run time".

@IndyMike Thank you for looking over the logs.  

I am not super clear on the first question.  I simply use the press of the MB Door Keypad off button as the trigger to start the program.  Maybe I am using trigger in the wrong context.  Maybe I mean to say it creates a temporary state? Either way, I am not sure how that relates.  Selecting "Buttons Toggle Mode" at the bottom of the admin panel for the MB Door Keypad shows all 5 buttons as "Toggle".  I do agree it is interesting that the MB Kelly Watch Winder goes to off, and there isn't anything about MB Keypad All On - off.  side note, I do hope UDI can make the bottom bar scroll someday in the admin panel.  I just discovered "buttons grouping" when I stretch it across two screens to find the toggle mode button.  What else am I missing?

As far as the second question, yes I used to have a 3 watt bulb in the curio and after talking with Steve (UDI/Insteon) I went to a 6 Watt and turned off the "auto on sensing" feature.  Since then,  the curio has been stable except during these events. The i3 Outlet in my office has a 9 watt bulb and regularly shows "communication error" for some reason. I have replaced the outlet twice and can't find any interference there. 

Third question.  Short answer: A scene isn't consistent in its order of operation and doesn't give the illusion of being lived in.  Also a program lets me set the lights in the guest bedroom if no one is there but not turn out the lights if they are there.  Same program three less lines based on the state of "sOccupied_Guest"

Long Answer (if interested else skip to next paragraph) When I owned a Lutron Dealer that was also a Security company we sold HAI Omni's and Lutron because they created a "vacation mode" with random light changes.  Through the security company we learned the more it looks like a person walking through the house the more likely the baddies move to the next house. It was more effective than an alarm or a dog. Eventually, Lutron created "learning mode" which was amazing.  After a month I never touched a light again.  The whole reason I went ELK M1/ISY 16 years ago is that HAI was no longer available and the ISY could do this quite well with a little effort.  And I sold the Lutron dealer and was too cheap to pay retail for it with SmartHome just down the street from me.  Also when I walk in at night there is button downstairs I can press that does a similar thing and the house follows me to bed.  Cool nerd stuff I guess.  The program itself has worked pretty solid for over 15 years.  Unless I do something stupid like attach a button to an alarm event and also to a scene that is.

You are probably sending me down the right path. I now realize I made that C button a Panic/status button by making it a controller/responder to the elk.  That may have been "on" last night and as you noted with the off button it doesn't show in the log.  I have no way to know without going to my office and logging in (which does all kinds of other things) since I haven't figured out a way to make the led dark on all six buttons when they are off and on only when one of the buttons is "on".  In my bedroom I didn't have instant feedback of the status.  

I took a green sharpie and made my own color change kit with the clear keypad covers.  On the off button, I colored both sides and the back of the off button so hopefully that is dark enough.  I am going to leave all programming as is and see if that was the problem.

Yes you are correct about other programs, and here is the odd one.  Each time the lights came back on a different program ran.  One is based on Sunset the others based on the ELK alarm status just as the C button problem that started this thread was. The eisy is on a large battery back up and didn't reboot so it isn't a catchup problem.  Learned that one already and the first Cyberpower UPS did all kinds of weird stuff to my system.

Stay tuned...

Edited September 11, 20241 yr by CoolToys
correction

16 hours ago, CoolToys said:

@IndyMike Thank you for looking over the logs.  

I am not super clear on the first question.  I simply use the press of the MB Door Keypad off button as the trigger to start the program.  Maybe I am using trigger in the wrong context.  Maybe I mean to say it creates a temporary state? Either way, I am not sure how that relates.  Selecting "Buttons Toggle Mode" at the bottom of the admin panel for the MB Door Keypad shows all 5 buttons as "Toggle".

That's it.  The top "On" button and bottom "Off" button on the 5 button KPL are essentially Non-toggle buttons.  The ON can only send On commands (or bright) and the Off can only send Off commands (or dim).  As we discussed above for the Motion sensor, multiple consecutive ON commands will NOT show up in the Log (same for multiple Off).  The device communicates and will show up in the event viewer (and trigger programs), but repeated commands will not be reflected in the logfile.  

I have never used the "buttons grouping" feature.  As recommended by UDI, I use scenes to accomplish similar things.

16 hours ago, CoolToys said:

As far as the second question, yes I used to have a 3 watt bulb in the curio and after talking with Steve (UDI/Insteon) I went to a 6 Watt and turned off the "auto on sensing" feature.  Since then,  the curio has been stable except during these events. The i3 Outlet in my office has a 9 watt bulb and regularly shows "communication error" for some reason. I have replaced the outlet twice and can't find any interference there. 

Look for programs that may be triggered by the devices turning ON.  You may want to disconnect the loads to see if this eliminates the issue.

16 hours ago, CoolToys said:

Third question.  Short answer: A scene isn't consistent in its order of operation and doesn't give the illusion of being lived in.  Also a program lets me set the lights in the guest bedroom if no one is there but not turn out the lights if they are there.  Same program three less lines based on the state of "sOccupied_Guest"

Good answer.  I've used the vacation mode feature on a few controllers.  Being from the "dogpatch" section of the country, I don't have a real application for the feature.  I can understand it's value for others.

16 hours ago, CoolToys said:

 

Yes you are correct about other programs, and here is the odd one.  Each time the lights came back on a different program ran.  One is based on Sunset the others based on the ELK alarm status just as the C button problem that started this thread was. The eisy is on a large battery back up and didn't reboot so it isn't a catchup problem.  Learned that one already and the first Cyberpower UPS did all kinds of weird stuff to my system.

Not sure how repeatable this problem is...  If you manually run your program can you force the problem to occur?  If so, you can copy the program and try removing devices to see if the problem goes away.

 

16 hours ago, CoolToys said:

You are probably sending me down the right path. I now realize I made that C button a Panic/status button by making it a controller/responder to the elk.  That may have been "on" last night and as you noted with the off button it doesn't show in the log.  I have no way to know without going to my office and logging in (which does all kinds of other things) since I haven't figured out a way to make the led dark on all six buttons when they are off and on only when one of the buttons is "on".  In my bedroom I didn't have instant feedback of the status.  

I think there is a way to accomplish what you want.  It involves switching the KPL to 8-button mode and then joining the A+B and G+H buttons in a scene.  From the outside the KPL looks like your 5-button.  A+B buttons are Non-toggle ON (as they are on a normal 5 button) and the G+H buttons are Non-toggle Off.

It allows you to control the lighting on all of the buttons - when all buttons are off, the KPL can be completely dark.  If you're interested, we could start another thread on the configuration (may already be something on the forum).  Probably better to figure out your current issues 1st.

 

 

@IndyMike, Thank you, you did lead me down the right path.  

By setting the led to ON 6/OFF 0 I could see that the "C" button was in fact off.  Everything went normal.  Pressing the C button after the bedtime program ran triggered the alarm lights program as it should.  Then reset for the big one, pressing C did nothing before hitting off. After hitting off, it made the house go wonky. I turned off C, hit bedtime again and the system recovered. Hitting all off and opening a door, triggering the alarm, the C lit up and the lights started coming on as they should in the order I want.  Keep me in the dark, intruder in the light. 

Why the Master Keypad Off doesn't show in the Log I guess is the mystery.  The motion sensor in the Garage shows on, then the lights come on and then the sensor shows off.  I use a program to delay the lights turning off by 20 minutes. Either big door opening or motion turns on the lights and starts the delay timer, that's why so much shows up in the log for the garage lights turning on.

 

Not sure why different random alarm related programs trigger when C is on before off is pressed. Nor do I Understand the timing of those events.  Since I have a repeatable experiment to prove my programming ignorance I think I won't pursue that question.

I went the lazy way on the LED problem.  Using the Green permanent marker to make the LED on the "OFF" button dark enough to not keep me awake worked very well.  Since Insteon quit making color kits, I wish I had thought of this sooner. I bought a giant permanent marker kit at Costco.