lilyoyo1

I don't know. It could be based on timing when the isy sees the second press. Are you doing it quickly where it's seeing a double tap vs a single tap? I have my variable set up to count presses. In testing my variable updates with the second press. Even in the video, it shows you the counter moving while testing the variable so I'm not understanding why yours doesn't update My program is set to capture double taps and the variable. That way whether I want music immediately in both areas or change my mind later, it will operate without issue.

I'm glad xlurkr's suggestion works for you. Not sure why a variable didn't work as I use it for switching my music in the bathroom from single room to bath and bed without issue

As in life, there's no elegant fixes for behavioral fixes. Nothing is really going to fix his issue perfectly as there are other variables that will inevitably come into play. Going that the rabbit hole will cause more problems long term than it solves. Personally, I'd leave well enough alone and show guests how to use things properly rather than deal with trying to program my way out of it. variables can help with the swl (the way he describes the situation this sounds like it's the problem). Whether it's a double tap or a second press in general, the isy can capture that via the variable (including programming) and trigger the proper scene based on the second tap regardless of what the light level the switch is showing. 1 tap would move the counter to 1 and the scene would run as normal. Should a person tap it a second time, the counter would move to 2, his program for the second tap would then see it and run causing the lights to go back to their normal level. Once he turns off the switch, the counter would reset, restarting the whole process over again. There are other factors at play which could impact things, which would require additional programs to account for. This is why I said earlier that there are no elegant solutions.

It's true for all keypads in regards to turning on and off. A 6 button kpl would be the same as a dimmer since it's on and off are separate (didn't add that tidbit). An 8 button in default mode toggles on/off. Depending on the level, you can dim up from a low level or dim down from higher levels. Regardless, for what he wants to accomplish and why, any other method other than variables will most likely lead to more programming to make up for something else that goes wrong with those methods

Did you watch the video? It explains how it would help you?

If the isy doesn't show 100% based off the button press, then status will not work since it'll be wrong. Using variables is the only way to accomplish what you want

A variable is the best method. The link I sent earlier showed how to set that up. You could use status. If status of light is 100% Wait 2 seconds Then set to 60%. The wait is there to ensure the isy has time to process everything

Unless double tapped, a keypad should turn off on a second press (if it's in toggle mode). Only switches will turn 100% on when it is pressed a second time since on is always the default command built into the device. You cannot override default behavior with the isy. You can only have the isy adjust it once done. You could use the status of the light to adjust the light downward. The problem with that is it will always dim even for the times you may want the light 100%. If you're that concerned about a second tap, using variables is the best way to go. It can see the second press and adjust the light after the fact. Keep in mind, the same thing from above applies. Should there be a need for 100%, the lights will not go to it. If this is a guest only location, why bother automating it in that way? You'll cause more confusion and headache trying to program for vs keeping things as normal as possible for people who are not accustomed to that. Here's a video on variables https://youtu.be/d8sHbgWc0vQ

A timer isn't needed and is the wrong way to fix this. You could use variables to track a second press to accomplish what you want. Personally, i feel this is a training issue. When you get into automation, it's much different than what people are accustomed to. If people are turning things off/on improperly then you're better served teaching them the proper way of doing things so that is done right the first and every time. Yes programming can help alleviate mistakes but it can also have unforseen consequences which can cause other problems down the road. Keep your setup consistent so that memorizing things are kept to a minimum and you'll find things will work much much smoother.

I'm not following. Is the issue with the kpl or swl? A second press (not double tap) on a lol should result in an off command turning everything off. Hitting a swl on a second time will result in another on command turning everything on (if at a dim level). You can capture double tap, dim down and dim up because those are commands insteon sees and has. A second press is a second press. Still an individual tap. The isy cannot discern what your intentions are. Was it inadvertent, intentional, etc. It just knows the button was pressed resulting in the corresponding command to be sent.

Directly linked devices will always respond in that way since the command comes directly from the device. There's no way to override that with a program. You can remove the controller from the scene and then use Control to trigger the responders when it's pressed. That would do away with devices changing when double tapped

Nope. Not at this time. I used to when Nest had the "works with nest" program. Unfortunately that ended once google cut it off. It may come back in the future but at this time it's non existent

Post your programs.

What were your exact steps to set your parameters?

A device going offline can be Multiple things. 1) could be your mesh. While you may feel it's decent it may not be. 2) are you properly waking up your device and is your Isy set to keep devices awake? If not, it could be timing out before it finishes updating. 3) your device was setup in 1 location(or healed in a location) but you are trying to update in another. If so, you just changed your network so that could be it. 4) verify that you're using the proper parameters. Zwave does have ghost nodes. Those are typically nodes that have no bearing on the device such as a door sensor having a glass break sensor node (yet has no microphone or parameters for it). If you're getting the data you want but your program is not working properly, then most likely your program is the problem.

You can't have mobilinc connect and the Isy portal. You must decide which you want to use. Once you do that, you'll need to connect the other to cancel and switch over

I'm confused in this in regards to use case. If you're opening up the app to turn something on or off, you want to verify if it's on or off prior to doing said action? Just trying to understand the logic.

This is correct

If you can do all of that then they do work so now it's figuring out why is not working with the isy. Try your pigtail method on a different area

Not wrong at all. The best simple explanation. One caveat is with zwave. Many zwave devices do not use control. I'm those cases, status will have to be used as the trigger

That error message means there's a communication issue. You can try manually linking the 2 devices to see if they look that way. If they do, then you know there is nothing wrong with the device I'm not surprised customer support said they do not support the isy. UDI is a 3rd party system. When they had the support team in Irvine, many of them had isy's themselves which allowed them to learn how to use it. With them outsourcing customer support, they simply aren't on the same level. Besides basic support, they're worthless. Insteon took 100 steps back with that move.

Try factory resetting the switch

Are you getting errors? How did you try to link

Michel has already stated they will support what they currently support. They will not add support (reverse engineering the code) for newer devices (such as the new line) unless they are given the proper documentation for it.

This all depends on what you value most from insteon. In terms of scalability, usability, and experience, none of the diy systems come to being a viable alternative. If you don't care about uniformity, redundancy, and overall system performance, then zwave would be the best alternative for the isy. The reason I say these things is that wifi devices aren't completely scalable in a full automation setting for the reasons you listed and more. In addition, you have the work involved with flashing all of your devices, maintenance, as well as network impact (can be mitigated if you know what you're doing). For me, the amount of work that goes into using them is not worth the cost savings. In regards to zwave, you're still dependant on the Isy in order to work. Should the Isy fail for any reason, your system no longer works. At least with insteon, you can design it to work outside of the Isy so that your most important stuff still work. This can be somewhat mitigated in zwave IF you have the right devices (emphasis on IF). However the ability to have direct links with zwave devices is extremely limited in the amount of devices you can have control of as well as how it could potentially affect Isy programming. IF (there's that word again) you have the proper zwave devices, the ISY can allow you to recreate some of the things you can do with insteon. However, zwave is not nearly as dynamic in regards to making changes so it doesn't allow for as robust of programming that you'll find with insteon. Finally, (the biggest issue for me) is the popcorn effect. Zwave devices respond 1 at a time not in sync the way insteon does. That's something I could never live with. If that doesn't matter to you then zwave will be fine (though it's response is slower than insteons) If you can afford it, and didn't want to stick with insteon, I would recommend using Radio ra2. There's a nodeserver for it written by @simplextechso that you can use the isy to give it the additional logic control that radio ra2 is lacking.