Jump to content

marvel

Members
  • Posts

    67
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

marvel's Achievements

New

New (2/6)

1

Reputation

  1. I believe I've resolved the problem with everyone's help, thank you. I started this evening's troubleshooting by power cycling the ISY, hoping for a quick fix. It didn't come back, so I power cycled both the ISY and the PLM. The PLM came back quickly but the ISY didn't, just a power LED and nothing else. I tried the reset button and no activity on the other LEDs. I also noted the power LED was noticeably dimmer than usual... so I swapped out the power supply. That brought the ISY back to life but my programs still only half-worked. Java cache was cleared, UI confirmed updated, firmware & UI matches. I pulled event log data for MrBill and wrote this: MrBill: Here's the event data you requested. The first log at 09:11:38pm is a manual triggering of the Exterior Lights scene (14 devices) on and back off from the ISY console. This works flawlessly every time I run it. The second log at 09:15:08 is a manual triggering of the Then path of the "Night on" program I opened this post with. The program still only sort-of works; the "Exterior Lights" and "Front Deck Rope Lights" scenes do not trigger, but other commands do. Before I hit Reply I did some more investigating and found the Front Deck Rope Lights module seems to have fallen off the network. ISY can't talk to it at all. I haven't gone outside to investigate it yet, but I removed it from the programs in question and now they work fine. Usually when a module is offline everything else works great and in fact the scenes don't seem to mind at all, but for some reason the programs did mind. Anyway, I've triggered the night scene back and forth more times than I can count tonight, 14 responding devices controlling a cascade of over 100 bulbs. The neighbors probably think I've gone mad, but everything seems to be working well again (save for those rope lights, which I'll figure out tomorrow). Thanks again. ISY-Events-Log.v5.0.16C__Thu 2022.05.05 09.11.38 PM.txt ISY-Events-Log.v5.0.16C__Thu 2022.05.05 09.15.08 PM.txt
  2. Thanks for the response. Nothing has changed in the home beyond the ISY upgrade. PLM hasn't been moved in years, no new things plugged in anywhere in the home. The scenes always work when triggered manually from the ISY admin console. I have several dozen dual band devices throughout the home and have never experienced noise issues preventing Insteon communications. This is definitely a software issue. I can press the Night button on my Master Bed keypad and this program sees that and updates the $Night variable, but the Exterior Lights and Front deck rope lights scenes don't run.
  3. Some things are working, some aren't. For example, take the following program, which worked reliably for years prior to the upgrade: If Time is Sunset Or 'Interior / Upstairs / Master / Bed / MstrBed KP:F night' is switched On Then $Night = 1 Set 'Interior / Upstairs / Master / Night' On Set 'Exterior / Exterior lights' On Set 'Exterior / Front deck rope lights' On Run Program 'KP Backlights' (Else Path) Else - No Actions - This runs at Sunset or if I manually run the Then path. It sets $Night to 1 like it's supposed to and it runs the KP Backlights program, but those scenes don't run at all. The scenes work by themselves. I can trigger them with the admin console and everything is fine, but the program doesn't execute them. Any ideas? I have an older Z-Wave module, or I would have upgraded to a newer release.
  4. I highly recommend @Scottmichaelj. I just purchased two Elk systems from him and am very happy with the whole experience. Great prices, great communication, super nice guy. If you're interested in Elk and need some help, reach out to him, he made the whole process super easy for me.
  5. We've had some burglaries in the neighborhood and the police aren't doing a damn thing to investigate. They showed no interest in my surveillance videos of the suspects and their vehicle breaking in to two properties next door to mine. It's time for me to get a security system. My question is whether to buy something commercial or DIY my own with Insteon & my ISY994i. The features I'm looking for are: (1) Arm/disarm via password on a keypad; (2) If triggered, activate loud sirens, turn on all lights and text me. The latter is a simple matter with the hardware I've got, but I could use some help on finding a suitable keypad that can trigger arm/disarm functions on my ISY. Alternately, if there is a good commercial security system out there that can trigger Insteon scenes, that could work too. Thank you in advance for any advice you can provide!
  6. Folks, I'm having a major problem with my Insteon installation. A few weeks ago, an "All On" event triggered every device in the home while I was laying in bed. This is particularly disturbing because virtually everything in my home is Insteon enabled, including my three garage door openers. Which opened and stayed that way. Last night, it happened again, so I updated my ISY to the latest version today just to rule out any bugs (I was several versions behind). Well, it just happened again, but only partially - most of the lights were in a funky state, odd dim levels, etc. This time I actually had the ISY console up and running and for some reason it did not seem to recognize any of the states. One of my appliance modules, for example, turned on but the ISY still said it was off. So I don't really know if this is an ISY issue or an Insteon issue. Unfortunately I am not at all versed in troubleshooting Insteon at this level. However, I can learn, so I'm here looking for your help. If you can give me any tips on how to approach this or point me in the direction of resources or documentation, I would be eternally grateful. I do NOT have any "All On" sequences in any of my programs and never have. This does seem to be time related. It happened right around 10pm the last two nights. I don't recall the time on the first night, but I had just climbed into bed so it's likely that was also around 10. I do have a program that runs at 10pm, it just checks the status of a few variables and then optionally executes a scene to dim my exterior lights. It's worked very well for several years. I'm going back to bed as soon as I post this, but I'll check your replies tomorrow. Thank you in advance!! (Quite frankly this is bad enough I consider myself lucky to be a bachelor, my ex wife would have lost her damn mind at the house unlocking itself in the middle of the night and demanded I tear all this equipment out. Good thing she's gone. )
  7. Everything is working now. Huge thank you to Steve for all of your help. The issue as I understand it was as follows: I have a large home with two separate electrical meters feeding a pair of panels. My primary lighting & circuits are fed from one panel, while the second handles higher powered stuff - HVAC, water heating & pumping, oven, dryer, etc. This second panel also feeds a pair of garage subpanels for large shop loads (welder, air compressor, 50 amp RV hookup, etc). Nearly all of my Insteon devices are on the first panel. My PLM is in my office, which is electrically noisy with computers, printers, etc. Also, it turns out the office electrical comes from one of the garage subpanels. Best as I can tell, the previous owners needed some more power in here and that was the easiest place for the electrician to grab it. As a result, getting powerline only Insteon signals from the office to the rest of the house is problematic at best, as they need to hop through the garage subpanel, to the secondary high voltage panel, then transfer over the utility's infrastructure to get to the primary panel feeding my lighting circuits. Why was this never a problem before? I created a rock solid Insteon network by only purchasing dual band devices when possible, so 95% of my devices are dual band. However, the dual band devices apparently have some sort of security mechanism and don't like to talk over RF and/or repeat signals from non-linked devices. (I may be fuzzy on the technical details, Steve, feel free to chime in and correct me here). When I attempted to restore all of my devices, the dual band communication wasn't involved due to the security issue and so communications fell flat on their face. At Steve's suggestion, I connected the PLM to an extension cord from a kitchen outlet which is on the main panel with the rest of my lighting. After doing so, the restore went flawlessly and full dual-band communication was re-established. I was then able to move the PLM back into the office and everything is working great now. Even though it's working, I already have plans to relocate the ISY and PLM out of the office and onto a different circuit. Just need to get up into the attic and run a network cable to the new location.
  8. Well, I struck out. I was able to restore a few devices, but most wouldn't restore no matter how many others were turned off. All of my previously programmed scenes that don't require the ISY to do anything are still working. Sometimes they're slow, but they're working. I decided to try a full ISY restore from my most recent backup. After coming back up, the "System Busy" progress bar ran for a long time, from 0-100% over and over again, and slowly tossed out "Cannot communicate with (device)" errors for about half a dozen devices that are powered up and otherwise working & responding to existing scenes. I attempted to turn on & off some of the devices that didn't have red exclamation points. Some worked, but took several seconds to receive the command. Others didn't respond at all and the ISY timed out and said "Cannot communicate with (device)." The entire network is intermittent. Sometimes commands work, sometimes they don't. Long operations, such as Restore Modem or Restore Devices, completely fail and mark all devices with red exclamations. Things I don't understand: When selecting "Restore Device" on a problem device, I'm asked if I want to proceed and after hitting Yes, nothing happens. The dialog box just goes away and that's it. When selecting "Write Updates to Device" on the same one, I get a "System Busy" dialog and it appears to be writing to the device, but before getting to 100% the box just closes and the device remains with a red exclamation. I'm frustrated. Not sure how to proceed. Going to file a request with ISY support.
  9. Correct. It would get the first link, then as best as I can tell communications on the network would fail. I was experiencing the same thing attempting to restore devices - they would start to restore, but would fail. I think one of my devices was misbehaving and flooding the network with traffic. I followed up on my hunch to pull the air gaps on all devices (that I could easily get to). I've been bringing them back online and restoring them in the ISY one by one and things appear to be working now. The device that only showed the one link previously, I brought it up first and was able to restore and query it and it showed all 8 links this time. Insteon has been great. Far better than X10 ever was. However, the quality control on the hardware needs to be improved... for that reason alone I think it will remain primarily a hobbyist's toy. As often as I have to debug things, I couldn't imagine having to hire a pro to do this. I'm a tech geek so I don't mind it so much, but I think Joe Average Homeowner would quickly become frustrated.
  10. Thank you for the replies. I checked the PLM links table and it's full of addresses. I checked the links table for the nearest device and it has the PLM address on it, but nothing else. That's wrong, though - the device responds to other switches that were previously configured - so I suspect it's just unable to get the data over to the PLM when queried. Similar issue when trying to write updates or restore the device, it runs for awhile, seems to be working, then fails. I wonder if I don't have an errant device on my network that's spewing messages and making communications difficult? My previously configured scenes do take awhile to execute, whereas they used to be instant. Any way to find out short of pulling the air gap on everything and reintroducing them one at a time? I have a fairly large network & almost everything is dual band.
  11. Hi folks, My 2413S modem died exactly two weeks past the two year warranty. I bought a new one and followed the modem restore procedures. Turned off ISY, plugged new modem in, waited a bit, then booted ISY. Chose File, Restore Modem. It seemed to work, but none of my programs or scenes would run and device status wasn't being reported back to the ISY. I tried a second time, same result. So then I did a File, Restore Devices. This ran for a solid hour but only made things worse. Now all of my devices have a red exclamation point next to them. I've tried to manually restore the single switch closest to the modem with no luck, both using "Write updates to device" and "Restore device." Neither function works. The ISY says it's writing to the device and takes a good minute or two, but when the progress bar gets to 100%, it says it can't communicate with the device. Help would be most appreciated. edit: There seems to be some amount of limited communication going on. I'm able to turn devices on and off from the ISY. It takes several seconds for the device to respond, but it does eventually respond and also throws me a "Cannot communicate with (device name), please check connection" error. Then it goes back to having a red exclamation point in the device tree. edit 2: I'm running a 994i Pro with Z-Wave module installed. At firmware v4.1.2.
  12. Cool! Thanks for the confirmation.
  13. The scene attributes aren't copying over from the ISY scene. Steps to reproduce: 1. Setup a scene using one KPL button as a controller and other buttons on the same KPL as responders. 2. Click on the scene and adjust the On Level of the responder buttons. The scene will work as intended when triggered from the ISY. 3. Click on the controller button in the scene and click "Copy Scene Attributes From (scene name)." 4. The attributes on the responder buttons (on the same KPL as the controller button) do not copy over. Let me know if you're able to reproduce this. Note: If the responder buttons are on a different KPL from the controller button, the attributes copy just fine. It's only an issue if you have a controller and responders on the same KPL. I setup a couple of 14 device scenes last night triggering responders on multiple KPLs and this drove me crazy until I figured out what was happening. I couldn't figure out why the scenes worked fine in the ISY but when triggered by the KPLs, everything was wrong, and the controller buttons on each KPL were doing different things even though they should have been triggering the same scene. I tried restoring devices and all sorts of shenanigans before I found the problem.
  14. It will not stop because you used an "If Control" action. Instead, change to an "If Status." "If Control 'Master Bathroom / Master Shower Light' is switched On" means, "If I switch this light on, run this program." There is no way to cancel this program. It executes as soon as you turn the light on and runs to completion. When you use an "If Status" instead, your If statement will read "If Status 'Master Bathroom / Master Shower Light' is On." Now you're testing the state of the light, as opposed to the action of switching it on. When you then turn the light off, the If..On state will no longer be valid and program execution will terminate. Turning it back on will restart the program (and, thus, the wait).
  15. By "timer" I assume you're talking about a "wait." Waits control program execution only and have nothing to do with devices. You're just telling the program to sit there for a specified time before continuing on to the next statement. That wait will only be canceled if the "if" statement that led to the wait's execution becomes false. There is no process that takes the next action beyond the "wait" into consideration. Determining what will happen in your scenario is dependent on the "if" statements. Assuming both "if" statements remain true for the duration of both waits, then both waits will function simultaneously and command execution for each program will continue normally after that program's wait expires. To cancel a wait (and, thus, further execution of the program in question), you will need to do something to make the "if" statement for that program become false. Yes. I don't know the answer to that question. Hope this helps!
×
×
  • Create New...