lilyoyo1

2. The original and now the new ownership group. Certain leadership in regards to sales and so forth really should be replaced

If all you have is insteon and feel the way you do about expanding, then I don't see any point in upgrading

You did it wrong. https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Link_Management_Menu

Does your firmware and ui match? What was your exact process to add the device

Unfortunately it is. I beta test for a few companies and they've pushed back releases and have cancelled others outright due to availability of stuff. Alot of people fail to realize that almost anything electronic requires some type of chip to run in today's world. Whether a its a calculator, smart switch, refrigerator, or car...It's needed. We just consume so much and desire so much more. It's going to take time for them to catch back up

There's been shortages of stuff all year for many things.....not just insteon. It's noticable because you're looking for insteon. If you start looking for specific devices from other companies and chart those for the past year, you'll see many more shortages has happened and are currently happening. 2 quick ones that come to mind are harmony remotes and lifx light strips. There are zwave 700 series devices that were slated for release last year that still hasn't been released. If your focus is only on 1 thing, you can see everything that can and does go wrong with them. However, when you have a multitude of different dealings, it does open you to the bigger picture of what's happening.

The lack of available devices are due to chip shortages. It's the reason why auto mfg. are having issues, PS5 shortages, etc. Even Samsung has announced they'll be having issues with makimg another flagship phone this year due to the shortage. https://www.google.com/amp/s/bgr.com/2021/03/17/galaxy-note-21-release-date-might-be-canceled/amp/ Insteon has always been tight lipped to their own detriment in many others eyes. Whether they say something or not is their choice. However, the fact that they have 6 brand new products currently showing in the fcc database (easily researched) as well as me ruined by other people on here is still ignored. Regardless of UDI and insteon's business issues, them coming out with 6 new devices does throw a wrench in the argument that they are going somewhere. Insteon has its own issues that they bring on themselves. With that said; it truly amazes me that with so much information available to us, we still don't take a modicum of time to read and stay abreast of what's going on in the world- yet have so much to say about stuff based off assumptions

You may be right. I've never liked the toggle modes to see how they react to different variables to know for certain. At least he has something to go off of in order to get going. He can easily set up the scene properly and if that still doesn't work out the kpls back into non toggle mode to see what happens

I think it's a combination of both in regards to trying to use a single scene in addition to using the toggle modes vs non toggle. Toggle send a specific command to everything in that scene. Since controllers are responders too, a toggle on would tell all devices to turn on regardless of how configured. The isy allows him to use 1 scene since they are still their own controllers within that scene. I do the same with my upstairs lights. The 4 locations that turns on those lights together are all controllers in 1 scene. However, the behavior is different depending on which button i hit. With that said, the scene isn't setup to be mutually exclusive so it doesn't cause any other issues. Regardless, he's doing something wrong with his setup since we both know it's possible to accomplish what he's trying to do.

It wasn't posted in the wrong forum. The problem most likely is that you didn't tag (get the attention of those) who resonded to your original question, after you asked your follow up question. They probably didn't check back in to see if you said anything else. To answer your question, the only nuances that someone can say upfront would be to ensure that you have enough devices to built a strong and solid mesh network. Anything else would be specific to whatever programming you were writing.

It probably does play a large part in things and how they work. Insteon's weed designed to work without a controller so the right modes are built into the devices themselves. Because of this, they would override the information that is sent via a scene. Toggle on- on command sent Toggle off- off always sent

Your issue has nothing to do with insteon, zwave, no the isy. It is completely how you are setting things up. 2 different people have shown you with examples what to do only for you to still do it incorrectly (according to your examples). This is solely operator error. Not Insteon, zwave or isy shortfalls.

I can't speak on your version with 5.3 since I haven't used those since the dual band versions came out. One thing I noticed is that you're using a single scene with all buttons as controllers instead of individual scenes for each controller with the other buttons as responders in the corresponding scenes like I had in my earlier example Ie: A- Main Light (one scene) B- Lamps (Separate scene) C- Relax (Separate Scene)

My programs have nothing to do with the other buttons. For the most part, all of my systems are designed to work without a controller so it's paramount that a controller is not needed for most of the setup. If you set your scene up exactly as I have shown, the other buttons will turn off on their own. Most likely you have not configured your buttons in the controller to send the off command to your other buttons. I've configured hundreds of keypads over the years in this manner and all have the same behavior once programmed.

Did you try start linking and use the set button on the outlet

You can find the reasons for why your isy is blinking by reading the wiki https://wiki.universal-devices.com/index.php?title=Main_Page#Front_Panel_LEDs.2FLights. Make sure your isy is connected to your network

⚠️ warning: poster above is a spammer. Previous post was a copy and paste from a 4 year old post

You only need an off to turn off the button that you are controlling. If you look at how I set the scenes up, you'll see the other buttons are configured to turn off whenever the controller is turned on. How you turn off the controller depends on what you are trying to accomplish. That's why I included examples of how I use mine. To help you understand the differences ways.

Older devices aren't as capable as newer devices but it shouldn't matter overall. The writes to those will be much slower as i1 isn't nearly as quick as i2cs. The way I set my scenes up are as follows: A- Controller- Default B- Responder- off C- Responder- off D- Responder- off Other devices- desired state A- Responder- off B- Controller- Default C- Responder- off D- Responder- off Other devices- desired state The same applies for the rest of the buttons. Depending on what the scene is for is how I determine how I'm going to use programs. For example, my all off scenes turns everything off. Using a program to turn the scene off isn't a big deal. I'll just have a program turn the same scene off 2 seconds after it's triggered. While I could get away with 1 second, the extra second is there to ensure all other communication has stopped. However, if I have lights that turn on for whatever reason, I'll create a separate scene and add that button as a responder. This way, the lights I want on will stay on even though the kpl backlight gets turned off. An example of this is my media room. My all off button isn't directly linked to everything. Instead I created a program with everything as responders. During the day, hitting the all off will trigger my off program setting the scene off (includong the all off button. At night, triggering the scene will run a program turning the scene on. This in turn turns the lights to 50%, turns on the hallway lights, and turns everything else off. I have the button in a separate program which then turns the button off after 2 seconds. The room will turn itself off after a couple of minutes as will the hall lights.

Yes I have without any issues. Are you just updating the scene or the controllers in the scenes as well?

Clear your Java cache. You should still have update neighbors

It's worth reading as there are a few nuances that you could potentially avoid if you're aware of the pitfalls of those who blazed the path before you. Personally, I think you're being overly cautious but it's not a bad plan since you don't have much anyway. Since you're planning on a fresh zwave install, you shouldn't have anything to worry about. Factory reset the zwave board before re-installing your zwave devices and you'll be good to go. You may need to bring devices close to the ish to re-add them.

What exactly are you having issues with? What are you trying to accomplish and what is actually happening? Without details it's hard to help you get on the right path. Too many people have working systems within the parameters they're confined to so most likely it's human error vs the system itself.

Keep in mind, when you use mutually exclusive, that resides in the devices. If you haven't reset them (or remove the function via console), it could still be there which will effect how your buttons respond to new scenes and programs.

Insteon's business is not dependent on the isy no more than UDIs business is tied to insteon. Both would survive without each other. There are a large number of insteon/ISY users so it would be a hit but at the same time, many of those users already have their devices so they've already gotten their money. Back when smarthome sold the isy, it was outsold by the hub by a large number (I'm only counting smarthome sales). Many of the employees pushed the isy because they felt it was a better system (it's definitely the best) than the hub, indigo, homeseer, etc. What ended up happening is that users would start with the hub and then upgrade to more advanced systems later. They have a symbiotic relationship and it's my hope that both see that it can be mutually benefictial to both. At the end of the day, both companies will survive without the other....it's the end users who will pay the price for them not working together