larryllix

I tried this but with so many gadgets using the same device it ties up Insteon traffic. I had nothing but trouble doing this and worked out a different solution. Flashing about every 5 seconds was the limit to not tie up the rest of my Insteon actions. The MS action, directly linked scene with the light (same KPL) could take up to 45 seconds to respond at times, while the flashing was happenning. Even just operating the LEDs without a Wait comes with a severe warning you may cause All-On comm clashes. Not sure why this is predicted to be such a problem but I don't understand the multi-mode technology jump problems going on with v5 either.

Yes. Powerline has reports of working 500' away for many. Sent from my SGH-I257M using Tapatalk

Sometimes dissimilar metals can bond to each other. A smear of silcone grease on the prongs works wonders for some receptacles that are too tight, can do it. Nasty situation.

I have a shop outbuilding located about 20 feet off my garage far end. Then the garage is about 28 feet across until the closest Insteon dual band device is pluggedin beside my dual Outback Inverter system. The outbuilding is coated in metal foil insulation and it has a metal roof. Even the joints in the insulation are covered in oil tape. Unless you locate an FM radio un front of a window the whole dial goes blank and receives nothing. Despite the RF blocking inside this outbuilding the Insteon device comm's work perfectly. I have the occasional miss inside my house but never to my shop.

That would work. We always have to watch which order we set variables to actually do things in so with power failure the importaant one doesn;t get done while the less important one doesn't. In this case the Init $s.siren variable is the most important, not the program enabling.

Welcome to the dark side! Seach your feelings. You know v5.0.10 to be true.

That slways brings us back to one logical error...a power failure during a wait period. Once the option to run at startup 'if', 'then', or 'else' is implemented, it might actually work most of the time. Sent from my SGH-I257M using Tapatalk

Guessing you mean PST?

I believe that is usually a WiFi connection problem when you get that message back. Upgrades may have been in progress.

I have found variables to be very reliable and simple to use. Most of my multiple scene rooms are controlled by variables. A Switchlinc stuffs values into a variable depending on the sequence and a bank of programs in a folder react like magic. They never fail and can be operated from anywhere in any program without understanding what the lighting is currently doing, Scenes used, programs used, or Network resources. As an example when my garage door is open, I flash a corner lamp red, about 1 pulse per 5 seconds. When the garage door closes, what was the lamp doing? It's easy as I don't need to care. Just refresh the variable value the variable contains and the whole room restores to whatever it was doing, Even if Off. If I change the initiator switch to a KPL or something else. I just use the same values and the bank of programs I haven't seen for years does all the work.

Because I can't think of a way to handle what you have done.... The only thing I can think of is to use a variable with a second siren program to disable the actual noise. Then you could monitor the variable and flash a light or other lower annoyance while the siren is disabled. The variable could be controlled with the 5x switch action. Clever idea! I use a KPL with four keystroke combinations for several things like that.

I was incorrectly thinking he was referring to the LED on the IOLinc.My bad there. Still not a problem. Consider the LED a closed door indicator and look for it to be OFF, or reverse the Scene operation using a program if necessary.

Now the LED indicates the door is closed. Is that a problem?

Let's not fill the forum threads with constant criticism when some opinion won't change anybody's life. I think it's the NY state being too close to Canada that causes this.

Even if Stu made the term up, English is a flowing language with constant changes. Who are we to argue with a new term?

WTF? C.A.I. maybe, but OTOH, OMG! AFAIC is the CIA also AI?

Are you turning On a scene with devices set to Off, or are you turning Off a scene with devices set to On?

For me, ISY can simulate low levels of AI. It is artificial and it has some intelligence, in the form of decision making, based on sensing parameters. Alexa does display some AI via the cloud databases, but not via HA.. Alexa in combination with ISY, has no AI and as lilyoyo1 posted, is just a glorified remote.

The switch never needs to be replaced. Just change the trigger logic to the opposite polarity. This isn't a security system with secure detection lines. If the trigger reverse option is removed, the daily query will not cause an erroneous status. I can use either contact polarity in a program and no difference will ever be detected.

I would be afraid of having a scene containing 70+ devices. Every time one device hiccoughs you would have to do a restore write to every device involved. The chances of a bad comm during this process should go up exponentially based on the quantity of devices! I use one scene with the majority of my devices to flash the entire house. The normal All Devices Off is done by a program where I can see the list and control sequence. I don;t recommend scene operations that large. From what I have been told there is no checkback for failures and this make scenes not as reliable. I inject 1-2 second delays between most devices as I know Insteon will bottleneck after a certain quantity of devices or errors. I have experience with a device that has been disabled and yet ISY still tries to operate it. When this happens the next three or four seconds worth of operations all fail by never getting sent or not comm'ing. This took me a few months to find. I also find when a whole house Off sequence is happenning I can detect some lights in a sequence and have time to react to it so I am not left in the dark. I have one program that ensures everything is off when the house is vacant. This algorithm can fail occasionally because of lack of detected movement.

Benoit is promising a technology jump for Alexa with Portal v3. IIRC from his comments he is going to jump one of the cloud services possibly enhancing the Amazon process. Then we'll see who is faster (for now). Googlites eat your hearts out! Google has been spamming my cell phone lately so I am not real happy with them. I keep experimenting with deletions for the last few weeks attempting to find out where the annoy-ware is coming from.

Why don't you give me a list of all possibilities that can be done, and I can go from there? Maybe you should start another thread so we don't side track this one any further.

It's a bug in the wiki instructions. This should have been corrected a long time ago and never posted in the first place. Remove the checkmark and re-write your programs to make the logic correct.

My Echoes and Dots vary aa lot in timing. It is not uncommon for Alexa to just sit and think for 20 seconds before activating ISY connected devices. If my TV amplifier is on (large speakers) I have to yell at it within a few feet or mute the TV sound. My Dot off to the side of one speaker (6-7'), and the Echo across the room (12-15'') are almost completely deaf. I find any bassy sounds especially affect the Echo with it's muted bassy sound output. When yelling at a local Dot I have found another Dot in another room will often answer faster.

I consider using a program state bad form and avoid it if at all possible. It is way to obscure and even some variable usage on a trigger driven ISY engine can be hard enough to sleuth. You'll get caught taking days or even weeks of your time and learn the hard way. Or if in formal code school, get expelled for it. Sent from my SGH-I257M using Tapatalk