Jump to content
AT&T to end email-to-text ×

IndyMike

Members
  • Posts

    1608
  • Joined

  • Last visited

Everything posted by IndyMike

  1. As a quick test, I got out my old Remotelinc to use as a jammer. Ran a standard "scene test" on my basement lighting (100% success). Ran the same scene test while holding a on button on the Remotelinc (bright command). 4 out of 18 Pass (22%). What's interesting about this test: The remotelinc is not linked to the system. Nothing shows in the event viewer. Since every Insteon device is a repeater, it is still flooding RF and powerline. I effectively hung the PLM/ISY while I was holding the Bright button. The ISY didn't appear to progress until I released the button. Event viewer was hung in mid-test. Standard Scene Test: Scene Test Jammed Using Remotelinc (Bright)
  2. @Guy Lavoie, hard to know which operation corrected things (PLM restore or controller power cycle). What specific mini controller are you using? If the mini controller were flooding your system with communications (RF or Powerline?), it could effectively jam your motion sensors. The motions won't necessarily be aware of the communication resulting in a collision. On the other hand, the PLM/Admin console would wait for and open communication window and therefor might be able to send commands. If your PLM link table was "upset", you would be able to send commands to devices but not receive. Since you just recently added the mini controller, that's where I'd put my bet.
  3. @abrayshaw, you mentioned that you've been unsuccessful loading from Lan. Have you tried loading from the cloud?
  4. @abrayshaw, If you know the IP address for your ISY you can enter it directly by clicking the "Add" button. Use the format shown below. If you do not know the IP address, log into your router and locate it. At this point you should also "reserve" the IP address for the ISY (if you haven't already). You don't want the complications of having DHCP move this address around. Assuming you can find the address and "Add" it successfully, "Save" the configuration to a file on your computer. Choose a location that's easy to locate (desktop, etc). The next time you can't "refresh" the configuration, use the "Load" button to load the configuration file. I created my file in 2022 (it's been working awhile now). @Geddy's approach is the correct one. This is merely a workaround.
  5. A word of caution when using the "My Lighting" query. I'll qualify this by saying that my experience is with the ISY994. The PolISY and EISY may be different. For the ISY994, a "My Lighting" query hit everything. Some things that you may not wish to have queried: All Insteon devices, Including MS-II sensors (bug). You can disable MS-II sensors to get around this. Note that the query is also a problem for IOLinc devices with "trigger reversed" set. All X10 devices, including receive only devices (bug) Z-wave devices - from memory, this includes battery devices. I do not know how Zigbee/WiFi/matter devices are handled on the newer systems. On the ISY994, I created a "House Query" scene that had ONLY the devices that I wanted updated and used that for the 3AM program query. This is a maintenance item as you need to keep adding new devices to the scene.
  6. @sbooke, your event viewer shows communication from your motion sensor, but it's from group 13. Motion is from group 1. I can't see enough from the event viewer to tell if you got a group 1 communication like you had previously. Regardless, your program should run as you have it written: Make sure you have saved the program. Look at the program summary to see the "last run" for the program. It should be triggering within the time window. If it has triggered, try performing a "run then" on the program to see if your device responds correctly. If none of the above works, delete the time constraint and check to see if the motion trigger alone works.
  7. When you execute a scene from the ISY (admin console or program) it does not verify that scene members received the communication. It assumes that the scene was executed properly. If you have noise or signal absorption, scene member may not respond. The ISY will still show these devices as having responded. When you re-boot the system, the ISY queries devices and restores the correct status. Queries are performed using retries and are normally very reliable. The ISY will normally Query your system in the off-hours (3 AM?) to re-synch things. This is a system installed program that runs nightly. If you have persistent issues with a few devices you may have noise/absorption issues on the related electrical circuits. Inspect for chargers, PC's, etc. If you have problems with MANY devices, the issue may be near your PLM. Perform the same inspection. By opening the event viewer on level 3 and performing device queries from the admin console you can observe communication with your devices. Communication from the device to the PLM will be summarized in the "[Std-Direct Ack] Entry" and will show Max Hop and Hops Remaining. Hops Remaining of "3" is as good as it gets. Lower is less desirable. Device Query Communication in Event Viewer. Device address 1A.5D.C7 to PLM Address 53.BC.3A.
  8. @sbooke, your motion sense is working. Your event viewer is showing EXACTLY what I posted above. Your last program you posted is incorrect. You are using a time trigger, not a motion trigger. The THEN statement is also incorrect. However, your original program should work. As @Guy Lavoie indicated, this would perform better if you used a "control" vs "status" qualifier. Not sure how, but we seem to have come full circle. Event Viewer Showing MS-II Communication Original Program Motion Program
  9. That worked, and your PLM does have the link records for your device. If your MS II is communicating (you said you were able to trigger scenes with it), your PLM should see group 1 communication from this device. Your event viewer should show the following when triggered (updated with your device address). Make sure that the Event Viewer is set to level 3. If you cannot see the communication in the event viewer either you have communication issues with that device (noise, etc) or the device itself isn't programmed correctly. If you changed PLM's recently, it's possible that the Motion Sensor does not have the correct PLM address in it's link memory. To verify, place the Sensor in programming mode and perform a Link Table Read + compare. It's possible that the MS-II Options are not set correctly. Verify that "Conditioin, Report, and Sensitivity" are set correctly (see below) Event Viewer Showing MS-II on trigger [INST-SRX ] 02 50 4D.EF.5F 00.00.01 CF 11 01 LTONRR (01) [Std-Group ] 4D.EF.5F-->Group=1, Max Hops=3, Hops Left=3 [D2D EVENT ] Event [4D EF 5F 1] [DON] [1] uom=0 prec=-1 [ 4D EF 5F 1] DON 1 Your PLM link record for the Motion Sensor Motion Sensor Link Table Read + Compare MS-II Device Options
  10. Sorry, nothing in the table (82 bytes) <isy.diag> <title>PLM Links Table</title> <insteon.lincs/> </isy.diag>
  11. @sbooke, I'm guessing that something went sideways during your upgrade to the EISY. Your PLM sounds as if it's relatively new. The table below shows the entries in my PLM for my MS-II sensor @4A.6F.65. In order for the PLM to hear the motion sensor, the circled link MUST be present. If it is not, the PLM will ignore motion on/off communication from the sensor. We need to figure out whether your PLM contains this link for your Motion Sensor. If the link is present, you are having communication errors with the device. If the link is not present, you'll need to remove/re-add the device OR restore a backup. Please save your PLM contents to a .XML file (see 2nd graphic) and upload to the forum. Please also provide the Address of your Motion Sensor. I will sort your PLM contents and try to find the links associated with the sensor.
  12. The link limit has been around in various forms since the start of Insteon. The original 2412S PLM had more memory, but had issues utilizing higher addresses - presumed to be due to speed limitations. There is a fair amount of Smartlabs documentation stating that the 2413S PLM supports 2000 links. Per the following, both @Brian H and @ELA verified that actual hardware from 2017 only supported 1000 links (https://forum.universal-devices.com/topic/24278-anyone-have-a-recent-2413s-plm/). Like you, I have a link count in the middle 300's. That's with ~66 Insteon devices. At one time I had roughly 2x that number and I was pushing the limit. It's interesting to note that PLM memory utilization isn't all that efficient. When devices are deleted, the memory isn't necessarily reclaimed. As I mentioned in a previous thread, I recently "recovered" 150 link records by performing a "restore modem". Finally, the Link Table Read function can be rather intermittent for some giving wildly different counts. The actual reading is performed by a PLM function "Get Next All Link Record". Unfortunately, during certain communication events, the PLM can loose track of where it is in the read process. I can normally get good PLM table reads in the early morning, but others have real issues getting consistent results. As I'm writing this my family is moving around tripping the various motion sensors upstairs. My link table counts are - 178, 919, 263, and 473. None of these are correct.
  13. @sbooke, 48 links is VERY few and somewhat doubtful. I single Keypadlinc with a few scenes can consume 20 link records. If you can't see the motion sensor communication in the Event viewer, your program WILL NOT trigger. The PLM either does not have the correct link records (programmed incorrectly) or the link record is outside of the range the PLM can access. The last condition (link record outside the access range) is what @gregkinney encountered. As he indicated, deleting scenes can help reduce things below the 1024 1000 link limit. If you believe that you have nowhere near that # of devices/links (I also don't), please post back. If you have recently upgraded (Polisy to Eisy, etc) it's possible that something went South, and you don't have the correct links in the PLM. It is also possible that your PLM is having issues and is loosing it's links records. Let us know the vintage (date code/rev level).
  14. @sbooke, if your motion sensor CAN trigger a scene but CAN'T trigger a program: Your PLM can't hear the device Your PLM isn't programmed to listen to the device You have too many link records in the PLM Open the Event viewer to @Level3 and activate the motion sensor. You should see communication similar to the following (with your device address). If you do not see any activity, check your PLM link record count and review the following thread: https://forum.universal-devices.com/topic/45014-motion-sensor-only-works-in-scenes-not-programs/ Thu 04/03/2025 07:42:31 : [INST-SRX ] 02 50 4A.6F.65 00.00.01 CF 11 01 LTONRR (01) Thu 04/03/2025 07:42:31 : [Std-Group ] 4A.6F.65-->Group=1, Max Hops=3, Hops Left=3 Thu 04/03/2025 07:42:31 : [D2D EVENT ] Event [4A 6F 65 1] [DON] [1] uom=0 prec=-1 Thu 04/03/2025 07:42:31 : [ 4A 6F 65 1] DON 1
  15. @WFP, I tried your configuration (24 hour clock) with the following test program. It ran correctly at sunset (activated my scene and set the variable), a ran false outside the time constraint. My sunset is at 20:12 today, so I get slightly less than 2 hours of "true" time for the program. I do agree that the AM/PM are the only options even though the 24Hr clock is specified. I should qualify that I'm running a ISY994... I initially ran things and was having problems determining whether the program ran true - that's when I added the variable flag. The variable was set this AM so I know the program ran true last night. I'm thinking that you program is indeed running, but your scene isn't hearing the PLM. You could check your Log file, or leave the Event viewer open during the run time to verify. You can also try force running the then portion to verify the scene devices can hear the PLM.
  16. I don't have an EISY, but I'm guessing the feature relates to the following: https://www.insteon.com/simple/#Manually-change-switch-modes-dimmer-or-on/off-mode
  17. I don't have a good answer to your question on how to determine PLM link record #'s. Earlier posts suggested putting the PLM on a filterlinc to "reduce" insteon communication (https://forum.universal-devices.com/topic/6979-countingestimating-plm-links/#findComment-55359). I've actually had limited success with that - probably due to RF communication. As far as reducing the link count - have a look at your large scenes to see if you have redundancies. Unfortunately, if you can't get a good link count, you won't know how many links to delete. Thanks for the Aeotec info.
  18. Not quite. The ISY knows the address of the dimmer module - it sends that address to the PLM so it can communicate with the device. If you are over the link limit, the PLM will not be able to find the address of the dimmer. If you manually activate the dimmer, the PLM will ignore the communication (just as it is doing with the MS). The Z-wave motion will circumvent the problem for the time being. No telling how many devices/links you have that are beyond the magic #. Which Z-wave motion are you using? I'm always on the lookout for reliable motion sensors.
  19. Sounds like you stepped over the magic line again. I find it is best to run the PLM test in the early AM when the rest of the house is asleep. Two consecutive tests with the same # of links is considered a good test. You could also try performing a "restore modem". In doing this the ISY may be able to recover link records by consolidating memory from deleted devices and scenes. Perform a ISY backup first to be safe. I just performed this on my PLM and was able to recover 150 records (I do a lot of adding/deleting during testing).
  20. #4 - sounds like you ISY (EISY) is being interrupted during the PLM record read. You may want to try in "off" hours. I was asking you to "trigger the motion sensor" (create motion) to see if the PLM registered the communication. Since you did NOT see any communication in the event viewer, you are NOT receiving the signal from the motion sensor. Either your PLM is outside the RF/powerline range of the motion sensor (unlikely since your just re-added the sensor), ...or the PLM does not have the correct link records to receive the communication. Normally, that would imply that you have exceeded the PLM link record capability (~1000 links).
  21. That should work. If it doesn't your PLM isn't hearing the Motion Sensor or has lost the link for it. Open the Event viewer and trigger the motion sensor to see if the PLM is registering the communication. You should also see the program executing your "study cans on" command. Please post the results. Other options: Make sure your program folder isn't disabled. Power cycle the PLM and ISY. Check the number of links in your PLM (max 1000)
  22. I missed the fact that you located an incorrect INIT value... Beyond that, I'll admit that the scene adjust method produces elegant results. I personally don't care for the overhead involved. In terms of the write cycles involved, you probably will not wear out the EEprom before something else dies (power supply, etc). Most EEprom devices are rated at 100,000 cycles. At 2 writes (AM/PM) per memory location per day your device EEprom would last 137 years. Sorry - I should have used my Maths before my previous post. The raw amount of communication required is a concern. Communication errors could result in corrupted device link tables and scene errors. You can check this by performing a link table "compare" from the admin console. You can use a time qualified program to call a scene and produce similar results. Use the scene controllers as the program triggers. My example scene above would look like the following. Note that I inserted a second wait After the Trigger and before calling the Scene - This is because the trigger (BSMT Stair) is part of the Scene (BSMT ENTRY). Best practices call for the wait to prevent potential communication collisions at the PLM which can in turn trigger the dreaded "ALL ON" phenomena. The event viewer communication for the command is shown at the end. Test - [ID 0071][Parent 0003] If From 9:30:00PM To 7:05:00AM (next day) And 'Basement / BSMT Stair' is switched On Then Wait 2 seconds Set 'Basement / SC BSMT Entry' On Else Set 'Basement / SC BSMT Entry' On Scene On communication Mon 03/31/2025 11:56:07 AM : [INST-TX-I1 ] 02 62 00 00 43 CF 11 00 Mon 03/31/2025 11:56:07 AM : [INST-ACK ] 02 62 00.00.43 CF 11 00 06 LTONRR (00)
  23. Wow, that's a lot of updating for day/night on levels. I'll confess that I've never really used the "Adjust Scene" program feature. I prefer to generate specific scenes for different levels and call them through a program. I'll admit that what you are trying to do would result in an "elegant" changeover in device on levels. The price you pay is an extreme amount of communication and many writes to device and PLM EEprom memory. The high communication level opens the door for errors. Excessive EEprom writes can actually wear out the memory devices. You also need to be very careful that you are writing to ALL the scene controllers as well as the Admin Console scene (in case the scene is called by a program). At a minimum, you should insert some wait statements to allow the link table writes to complete. Based on what I'm seeing with PLM write timing, the wait should be around 5 seconds. Try opening the Event Viewer (level 3) and manually running your program. You'll be amazed how much communication results. I tried adjusting 1 scene with 1 controller - the program and Event viewer communication are shown below. You will have MANY times this amount of communication. Answering "Why did I have to Re-create my Scene" - Communication errors during link table writes - or - Worn out EEprom memory (PLM or Devices). Hopefully it's #1. Test - [ID 0071][Parent 0003] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then In 'Basement / SC BSMT Entry' Set 'Basement / BSMT Fam Rm Sconce' To '$IOnLevel %' in 2.0 seconds Wait 5 seconds $IOnLevel = 100 In 'Basement / BSMT Stair' Set 'Basement / BSMT Fam Rm Sconce' To '$IOnLevel %' in 0.5 seconds Else - No Actions - (To add one, press 'Action') The following is the Event Viewer Communication generated by the above program Mon 03/31/2025 10:28:40 AM : [ Time] 10:29:02 21(0) Mon 03/31/2025 10:28:40 AM : [26898]->[41 1E 9 1] link updated Mon 03/31/2025 10:28:40 AM : [41 1E 9 1 ] Link 4 : 0FD8 [A24353BC3AFF1B01] Saving [..........FF....] Mon 03/31/2025 10:28:40 AM : [41 1E 9 1 ] Link 4 : 0FD8 [A24353BC3AFF1B01] Saving [............1B..] Mon 03/31/2025 10:28:44 AM : [All ] Writing 2 bytes to devices Mon 03/31/2025 10:28:44 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Mon 03/31/2025 10:28:44 AM : [INST-ACK ] 02 62 41.1E.09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Mon 03/31/2025 10:28:44 AM : [INST-SRX ] 02 50 41.1E.09 53.BC.3A 2F 2F 00 (00) Mon 03/31/2025 10:28:44 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 03/31/2025 10:28:44 AM : [INST-ERX ] 02 51 41 1E 09 53 BC 3A 15 2F 00 00 01 0F FF 20 A2 00 39 01 76 FF 1F 01 31 Mon 03/31/2025 10:28:44 AM : [Ext-Direct ] 41.1E.09-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Mon 03/31/2025 10:28:44 AM : [41 1E 9 1 ] Link 4 : 0FD8 [A24353BC3AFF1B01] Writing [..........FF1B..] Mon 03/31/2025 10:28:44 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2F 00 00 02 0F DF 08 A2 43 53 BC 3A FF 1B 01 90 Mon 03/31/2025 10:28:44 AM : [INST-ACK ] 02 62 41.1E.09 1F 2F 00 00 02 0F DF 08 A2 43 53 BC 3A FF 1B 01 90 06 (00) Mon 03/31/2025 10:28:44 AM : [INST-SRX ] 02 50 41.1E.09 53.BC.3A 2F 2F 00 (00) Mon 03/31/2025 10:28:44 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 03/31/2025 10:28:44 AM : [All ] Writing 0 bytes to devices Mon 03/31/2025 10:28:45 AM : [1A 5D 6D 1]->[41 1E 9 1] link updated Mon 03/31/2025 10:28:45 AM : [41 1E 9 1 ] Link 1 : 0FF0 [A2011A5D6DFF1C01] Saving [..........FF....] Mon 03/31/2025 10:28:45 AM : [41 1E 9 1 ] Link 1 : 0FF0 [A2011A5D6DFF1C01] Saving [............1C..] Mon 03/31/2025 10:28:45 AM : [All ] Writing 2 bytes to devices Mon 03/31/2025 10:28:45 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Mon 03/31/2025 10:28:45 AM : [INST-ACK ] 02 62 41.1E.09 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Mon 03/31/2025 10:28:46 AM : [INST-SRX ] 02 50 41.1E.09 53.BC.3A 2F 2F 00 (00) Mon 03/31/2025 10:28:46 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 03/31/2025 10:28:46 AM : [INST-ERX ] 02 51 41 1E 09 53 BC 3A 15 2F 00 00 01 0F FF 20 A2 00 39 01 76 FF 1F 01 31 Mon 03/31/2025 10:28:46 AM : [Ext-Direct ] 41.1E.09-->ISY/PLM Group=0, Max Hops=1, Hops Left=1 Mon 03/31/2025 10:28:46 AM : [41 1E 9 1 ] Link 1 : 0FF0 [A2011A5D6DFF1C01] Writing [..........FF1C..] Mon 03/31/2025 10:28:46 AM : [INST-TX-I2CS] 02 62 41 1E 09 1F 2F 00 00 02 0F F7 08 A2 01 1A 5D 6D FF 1C 01 1E Mon 03/31/2025 10:28:46 AM : [INST-ACK ] 02 62 41.1E.09 1F 2F 00 00 02 0F F7 08 A2 01 1A 5D 6D FF 1C 01 1E 06 (00) Mon 03/31/2025 10:28:47 AM : [INST-SRX ] 02 50 41.1E.09 53.BC.3A 2F 2F 00 (00) Mon 03/31/2025 10:28:47 AM : [Std-Direct Ack] 41.1E.09-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Mon 03/31/2025 10:28:47 AM : [All ] Writing 0 bytes to devices
  24. I have been unable to locate any specifications on the RPC1508-64. I did find the following Enphase filtering document that recommends the use of a RP240-80-10-S for noise issues (https://enphase.com/sites/default/files/2021-06/Power_Line_Filter_Single-Phase_TechBrief.pdf). This device is available @Newark for $233 (https://www.newark.com/astrodyne-tdi/rp240-80-10-s/filter-1-phase-80a-250v-chassis/dp/85AJ1317). Specification lists insertion loss (filtering) @150Khz of 40/60 db for CM/DM signals (https://www.farnell.com/datasheets/3622987.pdf). ...not much of a specification. The Enphase document indicates that it's Microinverters communicate over the powerline @144Khz. The filter is used to clean (or isolate) power to allow the communication. I would not have purchased this filter expecting it to filter/isolate noise in the 130Khz Insteon communication range. While the current range is applicable, the filtering range is spec'd from 150K up to 30M. Too expensive to roll the dice hoping that a device spec'd for 150Khz and above can filter sufficiently in the 130Khz range. Based on the results that @NCSTATE78 is seeing, the filter has sufficient bandpass to cover the Insteon range as well - at lease for the RPC1508-64. Just another data point. NOT proposing that anyone try this. It COULD be something to mention to your installer.
  25. OK, 277 volts would correspond to a 480V 3-phase installation (277V is one leg of the 480V 3-phase). That is truly a commercial install. If you are trying to communicate with devices on all 3-phases you will need RF coupling devices on all 3-phases. That's a different topic, but mandatory for 3-phase (passive coupling will NOT work). The SKU you provided led to the following specification: https://www.ali-corp.com/Upload/File/f184035e-11c7-4c50-92ae-1d016b64d611/Linear Strip-1,.pdf Your lamps can be powered by by voltages ranging from 120V to 277V. Unfortunately, the specification indicates that they must be dimmed by a separate 0 - 10V signal. If this is the correct specification, you should NOT use a Insteon Dimmer with these lamps. The lamps were designed for a dedicated switch (or relay device) to supply power, and a separate 0 - 10V dimmer. Insteon does make a 0-10V dimmer, but it installs at the device and is controlled via RF (https://www.insteon.com/0-10v-ballast-dimmer). I have never used one of these. It is rated for 277V, but I am not certain that it is appropriate for a commercial installation. You would obviously need a separate RF controller for the dimming function.
×
×
  • Create New...