DAlter01

Maybe a call from Michel to Rob to feel out the situation??? With so much investment money floating around right now it would not likely be hard to raise a few $M for a proven quality operator like UDI to do a little vertical integration.

And, I belive Smartlabs solf for $7.3M a few years back. Now that the tech is about 5 years older with absolutly nothing invested in it and sales likely down substantially, maybe it could be picked up for $3 or 4M??

I'm in. The tech has value, in my mind, if marketed and executed better. It's good to see everyone so enthused on a topic. On the security issue, I'm by far no expert, but this is mostly a lighting/switching logic and execution system. While it can do more, that's what it does for most. I believe it just needs a new front end filter/firewall device or sub system that limits the access to named/authorized IP's. And, once done, the system would be largely secure with maybe the ability for some actor to hack your lights. But, with no money in that, will they?? For a consumer product, I believe having that device is enough of an illusion of security that would be necesssary. And i believe 99.9% of current and future potential users would be satisfied with it. Again, what do I know....

Thank you. I've been noodling around what you said last night and said again more fully in the above post and think that, yes, there will be a way to make this work. I can save a lot by moving my 3 and 4 way switches to being outside the ISY, they just don't have to be in there. And, I'll probably create a master "occupied" scene that will be my baseline lighting scene. Then, based on time of day or theme, I will manipulate that scene based on percentages globally and then adjust parts/rooms within a program by naming hte devices individually or with a small scene where the global adjustment isn't appropriate. And, yes, use that same "occupied" scene for my "all on" scene and on my "sleep" scene. Your "All-off" by room might also work for my situation, or a modified version of it. I take it you don't see a signficant lag when you are running a program that affects most of your devices when you have it parsed up into bite sized scenes? I know when I threw nearly every device in a program as an "all-on", the ISY bogged down. But, if that can be cut down to 10-12 bite sized scenes, I suspect the lag I experienced will be greatly improved or maybe even barely perceptable. The KPL's are a different story. I know I don't need all of them. I just didn't want to patch all the holes in the wall and replace the multi-gang boxes from 3 to 2, 4 to 3, etc. That is a lot of work. In hindsight, that would have been the right path. I'm thinking that over again and will end up removing some of them and patching. Others I'll likely replace with dimmers. It is going to be a pricey re-engineer. But, the good news is I'll have a healthy supply of replacement keypads should I experience failure down the road. Or, you might see a few KPL's on ebay with custom button names....

Thanks, I not using Polisy, my mind is already stretched about as far as I dare. But, maybe after I get further along I might venture into that next chapter.

Yeah, I suppose that is an option, hadn't thought of doing that. It will pick up some links. I think I lose the ability to have my system backed up and easily replace devices at failure, but it may be a necessary solution. I do have some KP's where I use a button to control a scene. I assume only that one button on the KP as the controller for the scene is involved and creating one additional link, correct? I suppose I could use a program, leave the KP button out of the scene as a controller, and have the ISY trigger the scene when it sees a change in state of that button. For scenes that have multiple KP button's controlling it, I could pick up a number of saved links by having an ISY program look at multiple controller buttons. Though, to have the button lights/status stay in sync, I'd have to have them in the scene as a responder so not sure I'm picking up any saved links with that strategy.

I'll give that a try. Its a fairly new install just being programmed now so not likely to help but only takes a few clicks to try so worth the excercise now and periodically along the way. I intend to do this technique but as I understand (or misunderstand it), that will be a global change to the scene and therefore not ideal when you want some parts of the scene brighter and others more dim. I was thinking I might segment these big scenes into those devices I want to brighten and those I want to dim and end up with a few more scenes but fewer devices in the scenes to allow more finite control. I don't get fine control of individual devices but this should get me in the area I want to be.

I have not done the nodeserver inventory but have done some calcs on my quantities. I have 284 devices if I count a 6 button keypad as 6 devices and an 8 button as 8 devices. I assume this means 284 links before a single scene is created. In this count I have a bunch of 8 button keypads that serve as sonos keypads and the house had a bunch of lutron keypads and I reused those old locations with 6 button keypads. I probably should have eliminated some of both of the 8 and 6 button locations and paid to have the sheetrock work done rather than install all that switchgear that was essentiall hole fillers. That decision was made before I realized I would have a link issue. Plus, I have a bunch of rooms/hallways that have 3 and 4 way switches and those need scenes to link the dimmers. As such, I probably have close to 400 links before creating any HA lighting scenes. I haven't counted the links created by scene membership for HA lighting scenes but my preferred path was to use scenes for my different lighting levels (day scene, evening scene, guest scene, All-on, etc.) I'd have over 1,000 links to create these HA lighting scenes if I wasn't limited by the PLM. So, I think I need to find a way to condense all of that down into scene groups that I can reuse between different HA lighting scenes. Its going to make the programming MUCH more challenging.

Excellent, thank you liyoyo1. Makes sense, forgot about Z-wave being a radio only device on a different frequency and on a different board. The Z-wave actually reduces my links vs using a similar Insteon device.

My Z-wave devices report a lot of unnecessary information to the ISY such as humidity, light levels, UV, etc when all I want to know is if the motion sensor has detected motion or hasn't. I suspect that all of this "excess" information is using up an additional link for each type of excess information supplied. Since I am over the 992 link limit of the PLM I am trying to figure out how to drop unnecessary links. Does anyone know if each type of excess information is, in fact, an additional link? And, if so, if there is a way to eliminate this information from using a link in the PLM (how to eliminate it?)?

Thanks, looking through the list of node programs/drivers, I can see that there is no end to control options. I'm still solving lighting complications but I can see a lot of paths to explore in my future.

larryllix, that is a lot of variables and a lot of programs. I see you are speaking the truth when you say you don't like scenes. On the ISY Inventory by simplextech, it doesn't appear to do a link count. Since that is done in the ISY maybe that is sufficient for now until I figure out my next chapter and need to start doing more integration with the Polisy. For integration, I have my Sonos running on an RTI using insteon 8 button keypads as the controllers. I'll admit someone else set that up for me since I lacked the mental bandwith and time to learn that at the time it was needed. Does the Polisy interface with Sonos? I'm guessing it does.

Thanks Mr Bill.

Ok, so it seems I've ventured into something unfamiliar. I see that simpleXTech has developed some code to inventory the ISY. But, I'm too much a rookie to know how to use that. Do I need to purchase a new piece of hardware for that? Do I need to subscribe to a software service that interfaces with my ISY to use this (and other) software? I've heard of node servers but am naive about the it except to know that the ISY is one, but not how it interacts with the larger universe of options that exist.

Yes, I have the Pro ISY, though I don't think I'm running up against a constraint there. On the PLM, I have the newer PLM 2413S (February 2021 purchase). But, it seems it has a functional limit of 992 even though Smarthome says it is more. Or, at least that is what I'm being told and have read on this forum. I'm not familiar with the ISY Inventory NS. I'll check into that.

Its going to be a massive change for my programmming. Currently I have a number of global scenes. I have an "All-On" scene for turning on all lights (security, cleaning, workman, etc.), a "day scene" that turns on many lights at moderate levels, an "evening scene high" that turns on many of the same lights at a level more approriate for evening time than the day scene lights, and an "evening scene low" that has many lights but is a lower level of lighting than "evening scene high". This is used for later in the evening, TV watching, etc. Then there is a "guest scene" that has many lights at a level appropriate for when we are entertaining guests. And, lastly, there is a "sleep scene" which turns off everything in the house including outside lights. Add in a number of Z wave motions that seem to report a bunch of additional unneeded information such as humidity, light levels, etc (I suspect that frivolous information is coming through as a link), and then I have 8 Sonos zones all controlled by Insteon 8 button controllers running through an RTI. Then, there are a total of 10 of the six button keypads many of which are not "needed" but replaced the antiquated keypads for the non-functional Lutron keypads I removed from the house. So, I have a LOT of links. To get rid of some I'll probably need to give up some of the goodies I like to have. I've tried running one of the big global scenes as a program in the ISY just telling it to manipulate 80+ dimmers/devices. However, it bogs down and takes a long time to sequentially run through all of those devices. So, that doesn't seem to be an option. An idea I'm kicking around is to have my base "day scene" be a global scene for turning lights on/off and then having smaller scenes for "evening high", "evening low", and guest that just manipulate the devices that are different from the "day scene". This should save a couple hundred links but that I don't think that will be enough. Another idea is to leave the companion devices uninvolved in my scenes. I loathe the idea of doing that but would cut down on my link count substantially. The idea being where I have 2, 3 or 4 switches controlling the same lights I include all of the non-load dimmers in the scene so that all of the switches are on if the load switch is on. To not have those companions on when the load switch is on makes it feel like an amatuer programmed the system, which, I guess is true.....

As expected, Michel at UDI pointed me to my problem. My PLM links table is full. It reports 990 links and I'm only about 60% done setting up my scenes and programs. It seems I need to develop some different strategies. My initial thought is to take a few of my large scenes and put all of the on/off/level settings into programs. I suspect others have come up against this problem before. Any thoughts out there on best practices on moving (mimicing) scenes with the use of programs or other ways to reduce link counts?

I just checked a few other KPL's that are working correctly. As you suggest, they return the same Record mismatch with the only difference being the E2 to EA change. Those keypads work fine. So, it appears the error I am experiencing is not related to the E2/EA difference. Hmmmm

So, the mystery deepens a bit. I just deleted the KPL from the ISY. I did a factory reset on the KPL and then added it back in. I then used the tool to check the links and it showed the links matched between the KPL and the ISY. At that point I assume things will work and conclude my prior issues persisted because I had used the "Replace" function on the ISY when I replaced the KPL to solve the problem. I then inserted the KPL buttons back into the programs and then attempted a test. The KPL would not initiate the programs on button press. Still, all the other KPL's work fine and initiate the programs. I used the diagnostic tool again to check the links on this affected KPL and I got a records mismatch as shown on the attached. I see that the only difference is the EA to E2 difference, which as you suggest may not be relevant, but maybe it is pointing me in a direction. I've started a support ticket with Michel.

larryllix, thank you. I failed to include in my previous post that I had done the Restore function previously, to no effect. But, after getting your post I did it again as I had not done it with the replacement KPL I had installed. That didn't resolve the issue but I noted that it took well under a minute to go through the Restore process so it would seem that comms were fine. I did find the data tool you mentioned and this has helped start to uncover the mystery. I got the report shown below which shows a records mismatch on the device links table.

Both are 5.3.0. My other 6 KP's are working fine.

I have a new situation to me. One of my 6 button keypads on a new install is not reporting its status to the ISY. If I query the keypad from the ISY it will update the status on the ISY but it will NOT report back to the ISY that a button has been pressed and there has been a change of state. I have done a factory reset of the keypad, no help. I have swapped out the keypad to a spare (new) keypad I had, no help. I used the "replace device" feature in the ISY when I did the swap. Is it possible the ISY has an internal glitch with the programming for that one keypad and by doing using the replace device feature I copied the glitch to the new keypad? If so, I suppose the solution is to remove the keypad from the ISY, add it back in as a new device, and then recreate the programming associated with that keypad's buttons. But, before doing that, I thought I'd ask the braint trust on the UDI forum to see if the issue has been dealt with before and how to resolve it.

As wisely suggested by larryllix, here are the programs that seem to work to make the MSII a viable sensor with the use of the ISY as the timeout timer for the sensor. Please read my prior posts to see what these programs seem to successfully accomplish. As part of this, It is important to set your MSII's internal timer to a short timeout interval. I currently have mine set and 30 seconds and it works well for my purposes. I previously had it set for 4 minutes and that did NOT work. It did not work because if motion occured at least once every 4 minutes the ISY timer never reset because the MSII's internal timer never timed out. With a 30 second MSII internal timeout inteveral, there only needs to be 30 seconds of inactivity (no motion) for the below programs to work. In your situation, you may need to decrease that even further to the 10 second minimum offered by the MSII, or maybe you can increase it to something longer. It took me 4 programs to create this logic and as suggested by HAbit, variables can be used instead of the values I have inserted for start times, the timeout interval, etc. to provide more flexibility and easier changes. Program 1 (this program uses the MSII to set a state variable that indicates there is motion (occupancy). It is set to do that only during specific times of the day) Casita Motion Variable Set - [ID 0030][Parent 0019] If 'CASITA / Mot - Casita On - Inst' Status is On And From 7:00:00AM For 14 hours Then $Casita_State_Occupancy_Variable = 1 Else - No Actions - (To add one, press 'Action') Program 2 (this program uses the change in the state of the above triggered state variable to turn the lights on) Casita Lights On - [ID 0018][Parent 0019] If $Casita_State_Occupancy_Variable is 1 Then Set 'CASITA / Casita Kitchen Downlights' On Set 'CASITA / Casita Living Rm Downlights' On Else - No Actions - (To add one, press 'Action') Program 3 (This program looks for a change in state of the MSII's status to reset (restart) a program this is the timer part of this group of programs. Each time there is a change in state of the MSII's status, the program it calls (the timer) restarts. Casita Lights Off Trigger - [ID 0056][Parent 0019] If 'CASITA / Mot - Casita On - Inst' Status is Off Or 'CASITA / Mot - Casita On - Inst' Status is On Then Run Program 'Casita Lights Off Execution' (Then Path) Else - No Actions - (To add one, press 'Action') Program 4 (this program is the timer. There are no conditions to run (no if statement). The only part of this program that is used is the "then" statement. Every time there is a change in state of the MSII this timer program restarts by Program 3 so it keeps resetting to a 90 minute countdown if there is a change of state of the MSII. Once the 90 minutes of the timer in this paragraph has passed, the lights turn off and the state variable in program 1 is reset to an unoccupied condition which will then allow the lights to be turned on again the next time there is motion detected by the MSII. This set of programs is specficially designed to allow an occupant to turn off the lights that have been turned on by this set of programs. Once turned off by the occupant the lights will stay off until the space is unoccuped for 90 minutes as evidenced by there being no change of state of the MSII for 90 minutes.) Casita Lights Off Execution - [ID 0054][Parent 0019] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Wait 1 hour and 30 minutes $Casita_State_Occupancy_Variable = 0 Set 'Z-Automation Scenes / Casita Lights Off' Off Else - No Actions - (To add one, press 'Action') I've been using this logic in my casita for a few weeks and it is working as I've described without error. I have used a modified version of this logic in my house to achieve a similar result and it has worked there also for the last 10 days without error. I believe it is a successful logic sequence uninterupted by unknown/unintended features of the MSII and ISY. YOUR RESULTS MAY VARY!!

HABit, thanks for the props. The solution is 98% your idea so I need to give credit where it is due. The only part I added to it was to intentionally use a variable to delink occupancy from the On command after the initial On command. This is so an occupant could turn off the lights and the lights would stay off until the MSII showed no activity for a period of time. This no activity period is to determine the occupant had left and so the process starts over again. That feature might have been part of your original code. If so, I didn't remember that part of it. This is my second house with an ISY and its been a process to clean up all of the programming short comings I had at the first one. As one learns more about the ISY and the creative ideas others have come up with it impresses me how powerful the system can be. I've got a few more issues to work out but this part of it was a major accomplishment. I've used the same coding concept for the MSII's and a few Z-wave motions in my house that are running in parrallel. I am attempting to document most of the code with the "reason" for the method selecting and inserting a lot of comments in the ISY. This may help a future owner but it will also help me when I want to make a change in a few years so I don't have to figure out why I did what I did and re-learn from the mistakes I made in my first attempts to program it. Good idea on using variables for start/stop/trigger times. I see those can be helpful to keep all of these defined values in a seperate section of program to make them easy to locate if/when a change needs to be made. Being buried within a program makes them hard to track down and change at a later date. Thanks again for your help.

If read in context with my prior post it will make sense. I tied it to the explanations/narrative in my prior posts. Sorry you don't like it that way. The program you mentioned "Run Program 'Casita Lights Off Execution' (Then Path) " is what I describe as paragraph 5. Good luck