DAlter01

@lilyoyo1 I here what you are saying. The dummies comment was a little self defeating humor and was not meaning that UDI should be trying to market their product to average Joe homeowner. I can handle most of the technical stuff but I hadn't read an overview of how the parts and software all fit together. And, in my view, even a very technical person that was looking at the UDI ecosystem from their website for the first time would have a tough time figuring out what parts and pieces were needed and how they related to build a functioning system and what the system could do. They would essentially have to buy it and use it to learn the "big picture". That, in my view, isn't how to peak the interest of the technically sufficient buyer pool they are likely targeting. I want a full rich automation system and will spend the time and money to make it work. I've had ISY systems for many years and have hundreds of functioning programs. Some of these are, in my view, fairly complex. I've reviewed the UDI webpage more than a few times and 've read hundreds of posts on Polisy, Polyglots, nodeserves, Rasberry Pi, etc. and yet I did not have clarity on the big picture of the next generation UDI ecosystem until today. After all of that time and effort, for this potential buyer to not understand the big picture prior to today makes me think there is something missing in the message. Or, I am just a little slower than most. The thing I thought was missing was the 30k foot overview to understand how the terms related to each other. And, as it turns out, that was the case for me. With just a few paragraphs from @dbussand a little more detail from @MrBilland @bpwwer, I believe I understand the big picture. You mention the time and effort to write up a summary of every little detail in an evolving environement, it being costly, etc. That is my point, that is what exists today, a lot of details and posts. In an attempt to learn the big picture I kept ending up back at the UDI wiki which is a mountain of details, which are hard to understand without understading the big picture. What is lacking, or I couldn't find, is a few paragraphs of overview that were beutifully composed today by the three names I mentioned above. That overview will be the same for many, many years. The details will, of course, change. But that overview will remain for years to come. In truth, many of the theories I developed through my prior research were mostly correct. Though, not entirely, and I had no confidence that my theories were accurate enough to go out and start buying new products. For instance, I had figured out before today that I can "run an ISY on the Polisy" and that it was different the running "ISY on Polisy". That is with many, many hours of reading on the forum and figuring out they are different. Will the person, even a technical person, reading the UDI site or the forums understand with confidence the difference between these two options? Or, will they just think there are linguistic differences in how different people write about how the ISY works with Polisy and there is only one choice? And, that same person will read in the forums about how there is still some work to be done on getting the ISY on Policy working fully and therefore think they should not run an ISY with a Policy since it isn't done being developed yet? Even writing the above paragraph will confuse a lot of people that don't realzie that "ISY on Policy" is different than "running an ISY on a Polisy". Anyway, my point was UDI might think about providing a clearer overview of their ecosystem. In the end, I got the overview I needed today but I'm guessing there are still a lot of people out there that are technically advanced enough to use the UDI ecosystem but they do not understand the overview of how it can work for them, and so they move on.

The clarity that ISY is just software running on an i994 hardware is very helpful. It provides me the ability to more clearly understand that the Polisy is a more powerful device (upgraded I994 and probably much more) that can run both the ISY program and the Polyglot program to then bring in more capabilties of the ISY program.

Very, helpful. I have a great understanding of it now.

Very helpful, thank you.

Thank you

Ok, considering the great experiences I've had with UDI, I can see that being true. I've had some poor experiences with Beta before so to preserve my time I've learned to avoid it. But, those experiences were not with UDI so maybe I'll relax my "rule" on not using Beta if it is a UDI Beta. For those that are running ISY on Polisy, it is as full featured and stable (or nearly as stable) as a standalone ISY box?

Wow, all in three paragraphs, very, very helpful. A few follow-ups and restatements to make sure I am clear: Is Polyglot a UDI created/controlled interface program or an open program on the ether similar to Linux? Currently a physical ISY (a node) can interface using a nodeserver with a Polisy (running Polyglot) and that interface is not Beta and, aside from occasional glitches, is fully functional for the ISY through the Polisy to the end user? Currently, a person can eliminate the physical ISY and run "ISY on Polisy" which is a program? that runs alongside or on Polyglot in the Polisy device to emulate the ISY? And, is the "ISY on Polisy" the code that is still in Beta and not yet as functional as a physical ISY?

Wes, I have to agree with most of what you say on this one. I'm experienced with the ISY but knowing exactly what a nodeserver is, Polygot, Polisy, ISY on Polisy, etc. is a little confusing and I haven't found a "big picture" 30k foot description I can understand of how all of this stuff interelates. I've been able to piece together what I think these terms mean and devices do from the UDI website and these forums, but I'm sure my understanding is not very accurate. There is further confusion created by frequent incremental statements I read about how device X can now work on device Y but is in Alpha/Beta. While some people might be interested, I don't want to attempt integration of equipment that isn't refined enough to be out of Beta and have an official release. And I haven't found any clear statement of what equipment/protocols are in Alpha/Beta, have an official release, and what they can do in the official release stage. I have read in these forums that some equipment has an official release, but a certain aspect, which seems integral, is still in Alpha/Beta.....so do I want to attempt integration of that? Not really since I really don't know what it can do in the official release firmware. So, while I have a very slick ISY system and have it interacting nicely with an RTI to integrate in some outside servcies such as SONOS, etc., my lack of having a clear picture of what this next generation of UDI equipment can and cannot do has kept me from taking the leap beyond the ISY. I'm not one that wants to tinker with a new evolution of equipment just to learn. I want to know it what it can do "reliably", before taking that step. I don't have that clarity now. Don't get me wrong, I think UDI does fantastic work and I believe their focus has evolved to more lucrative work of building equipment and protocols for integration of business/commercial applications. Bravo to them for that and I wish Michel and the company great success. I assume one off sales to non-professional integrators what require a lot of hand holding and explanation probably isn't their focus. But, if that assumption is wrong and they do want to penetrate the market for people like me and @Wes Westhaver, they should think about a section of their website titled "Polisy, Polygot, ISY and Nodeservers for Dummies" and that section should have a big picture-30k foot section and also an explanation of what each of the key terms mean, and what they can do with their official release firmware. And, maybe a description of what they can do in Beta but that Beta mention might muddy that water too much. Some on these forums say a lot of this can be learned from previous posts or can be learned from the forum. With hundreds of thousands of posts on the forum someone is supposed to learn the current state of the UDI ecosystem from forum posts????? I've read thousands i don't have the level of understanding I want/need and could probably get from 30 minutes of studying a well written description of the UDI ecosystem. So, in my view, forum posts isn't an effective way for this "dummy" to figure it out. But, maybe I am below average and this stuff is just obvious and easy to everyone else. Or maybe, regular folks like me should just stay on the ISY until the Polisy is more evolved. That is my current impression.

Yep, Michel at UDI will immediatly get you resolved if you open a ticket, or at least that is my experience.

Your count was interupted by Insteon traffic. You have a minimum of 1166 links which is way over the limit and is causing you problems. The 1166 may still be under your actual count since the other four of your counts were clearly interupted there is a fair chance the 1166 count was also interupted. You will not know your true count untill you get a repeatable number. You have something in your system being triggered during your counts, a motion sensor, door sensor, something is stopping your counts.

Good point, this topic is in a new user forum so the poster might be new and we should make clear that from a function perspective he can mimic his current operation by having buttons or dimmers trigger the scenes just like his current setup. He would just be using the button or dimmer to start a program that controls the scene. And, he doesn't need to do this for all his scenes but enough to get his link count to less than the PLM limit. Based on his readings, he is definently over the limit with his one count showing 1166 links which might still be low if it was interupted with Insteon traffic. When I was having similar problems and finally got a good repeated count I was at around 1,700 links. Another fine tune is that for my base occupancy scene (day scene), I use a 2 second ramp rate and a 1/2 second ramp rate for my smaller scenes that manipulate the base occupancy scene. This way, as the base occupancy scene is ramping up over 2 seconds, when then smaller scene changes the lighting level at a faster rate (for instance my smaller evening scene), the transition is seemless between the two. You don't get a flash of the higher lighting level that might exist on the base occupancy scene with the lighting level then dropping down to a lower level.

@Michaelv I've experienced the EXACT issues you face and have a few more devices than your 150 number. With my system I had exceeded the link capacity of my PLM. As suggested by others, I resolved it by modifying how I used scenes to eliminate a lot of links. Previously I had a day scene, an evening scene, an all on, a goodnight scene, a party scene, etc. I found that I could use the day scene (occupancy scene) as my basic scene and manipulate that scene to create my other scenes. So, for goodnight, I use a program to turn off my day scene, evening scene, and party scene to make sure I catch all the lights. This eliminated my entire goodnight scene which contained nearly every device. For evening scene, I turn on the day scene in a program and then have an abridged evening scene that just changes those few switches that I want different than my base day scene. I use the same for my party scene where a program first turns on the day (occupancy) scene and then I use a small party scene to change those few switches that I want different than my day scene. I applied this same strategy to some of my other scenes and have cut my link count by nearly 1/2. Now, all of the issues I faced, which were identical to your issues, have been resolved. For an all on scene, you can use the same base day scene and use a Fast On command to turn the lights on at 100% versus your predefined level you have your lights set for in your day scene.

Th Mr Bill, That puts my concern into perspective, thank you. For me it seems having a KP that might fail at 10-15 years isn't a concern that will keep me from writing the EEPROM 2x a day to acheive my goal. That is still plenty of lifespan. And, will I own the house for 10+ years? Plus I have a half dozen spare KP's to cover the various known/unknown device failure risks. So, in the end, I view this as a neglible risk solution. I like your idea of painting the clear under button. I've done something similar in another location where I used spray on tint to the those clear under buttons. The issue I had was the lowest light setting (except for off) was still too bright for my needs. After applying the spray tint a lot less light comes through which allows much finer control of the lighting level on the KP's as the button still allows some light to come through, just less.

I've got a KP that I want to turn the backlight off each night, then in the morning, turn it on again. During they day I like it having a backlight but at night I want to get rid of the room illumination it provides. I remember reading in some forum that constantly writing to the EEPROM of a device will eventually kill the device/signficantly shorten it's lifespan. Is that true? Is changing the backlight level writing to the EEPROM or is that just a false assumption of mine and not an issue? Are there other ways to achieve my objective of having a different backlight level in the day vs the night?

You can also spray the clear plastic "sub button" with spray tint. I've used VHT Nite-Shades from Amazon. Runs $10. Works great. For my purposes I use three light coats on the sub button and it greatly reduces the light output but still leaves the button with a glow in a dark room. I'm sure you could just use this on the buttons you want to be dimmer than the others.

Being only an ISY user, am I to understand that a Polisy can now replace/emulate the ISY as a next gen version of the ISY? I do need Z-wave on my ISY and I believe I read in a post above it does not yet support Z-wave through the ISY emulation? Sorry if these are rudimentary questions, I've mostly not paid attention to discussion on the Polisy as the ISY has been able to do everything I've attempted to accomplish and I also read Polisy was not able to incorporate the ISY functions and migrate programming so it didn't draw me in. Sounds like it is time to start looking at it as an ISY replacement/upgrade?

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?)?

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.