larryllix

Typically ...yes! Insteon devices will try up to three times if an ACK is not received back from the destination device. Less can reduce reliability. More can clog up protocol channels with excessive clutter that likely should be fixed. Scene signals do not support this technique as there is no ACK from destination devices, similar to the old X10 protocol. ISY guesses at results. Hops are a different beast, and often confused with retries. When a device attempts to communicate with another, every device that hears the package resends the package in synchronicity with the other devices. This is called a HOP. Typically they are set to 3 HOPS by the initiating device. Each device subtracts one from the count and sends it again. The communication between the initiating device and the target device is not counted as a HOP. This is why good Insteon comms are important. Think of this. 1 device talks to 8 devices and repeat it. Then another 25 devices repeat it again to the rest of the 100 devices. Now add in the three retries on top of that when it doesn't work. Now the fast Insteon protocol is bogged down with junk packets. Hope this helps.

I think that power consumption is way overstated but to support that you will need to radial feed every strip or use #8 wire. Good luck with your branch splices connecting #8 AWG to say #16-#18 tap-offs A combination of techniques may work better. Use four main runs of #14 (15A each) to feed each set of 3 steps. Soldered and shrink wrapped tap-offs may work better with those wire sizes. To use the system in the thread you found above, you would need a controller box every step. If you have the space, it would cost a lot more, about $12-$15 per controller/step. I have python3 software that could drive those in sequences easily, and I receive ISY NRs to control the sequences/colours etc. If you know python3 you should be able to adapt it to your needs. I currently run it on my polisy box but came from a RPi where I did animations for a wedding tent once. I used 12 x 5m strings in a ceiling spokewheel configuration. It was fun. The controllers and PSU all sat on a common central hub wooden platform attached to the main tent pole by the ceiling.

These Insteon stats only report in once a change of about 2-3F has occurred. I have two of them (2441ZTH wireless) . The older one is controllable, and the newer one confirms all ISYs commands but doesn't actually execute them. I was using it as a probe only but likely the worse probe I have ever seen. If you want a decent stat, get an ecobee and use a NS. If you want sensor probes, get some CAO Tags, and use a NS or the kumoapp code to inject your state variables.

After about a year of this nonsense from google, I started a new account and it started to work again. I had to abandon my original google account for the purpose of ISY Portal. It never worked again, despite months of deleting and re-installing. Now I have a bunch of google accounts, but I have since abandoned my GH units, anyway. I got tired of their security games. Google support only ever told me to contact the code writer, Benoit and all looked proper at that end.

What would you address them with? ISY isn't capable of doing animation. ISY's fastest timer is Wait 1 second. It could be done with an Ardiuno or RPi as in the link, I guess. Sending a signal to the LEDs would take a lot less controllers than one for each step strip. BTW: I run my 5m long RGBW strips with a 12v 3 ampere PSU (36W) full brightness, no problem. The 5v 60A power supply (300W) in the article is ridiculous overkill. Even the wiring shown in the project link wouldn't handle that current.

If my quick research is correct that controller is a Bluetooth protocol. I don;t think much will interface with that. You would need a BT access point within 12-15 feet of every strip, and software to interface with it. After 15 years of owning a BT AP I tossed it in the bin. BT is basically only for operating devices on your body. Check out some of the old threads in the forums here. There is a lot of photos for LEDenet, and MagicHome, and MiLight, RGBWW/CW controllers using WiFi. ISY and polisy support a lot of Ethernet devices.

The thing I don't understand is this guarded API, that they all try to do. If some company would publish their API for their set of WiFi devices the developers could rush to support them on every platform. They would likely become the industry standard and corner most of the market. As it is, these companies are basically guaranteeing their own obsolescence due to so much competition in the market. Trying to give the printer away and gouge the ink price doesn't seem to work in this field, because the app is usually free. It makes no sense. Insteon is another one trying to do this. In other forums that is the retort to suggestions, most times. Insteon is an island and nobody wants to be captured there. Open up and become the industry standard workhorse. When I purchase $3000-$5000 worth of Insteon gadgets at $60 a device, what is left to sell with a closed API? Your free software? Your hub for $99? What moronic marketing! For the massive remote control market crowd, the $10 WiFi device, cloud service, and $25 Alexa speaker will win out, every time.

Did you try to load the link table from a device and then clicking the compare to see what ISY thinks should be in there? This is very odd that solely On would not work.

If these devices are Insteon, right click on each device, and select Restore in the admin console, device tree. Give it about 30 seconds to write the link table in the device. You may have lost links to each device.

My last router (ASUS RT-AC68u, AC1900) started crashing out connections about 52 devices. On power up they just couldn't get an IP address assignment. Sometimes it was my ISY994. Sometimes it was my polisy that didn't get an IP address. ISY using 0.0.0.0 for an IP address doesn't work too well.

ecobee all the way. I have tried many and ecobee is the best for stability, accuracy, and stability, and looks. WiFi to cloud as they all are. Awesome drop in NS that handles it well. Nodelink also supports it. Sent using Tapatalk

Check all your spam folders in every email you have ever had. There may be a permission email you missed to authorise a new connection, or a connection they want more information from you before it will allow it. Access the google mail webpage access and check there.

I don't totally avoid Insteon scenes. I use them with MSes for speed of ON response. I use them for multiple lights in my gathering room to allow them to be fairly synchronised, along with my WiFi lighting bulbs and strips. I use scenes for all lights functions like flashing the whole house for alarm purposes. Most of these are non-critical applications and if they fail it isn;t such a big problem. In my 3:00 AM routine to turn off everything I use programs with individual lines of code, so that the status is reported back, and Insteon will retry up to three times if no ACK is received from each device. If your 3-way scene is not working you may need to improve your comms or reduce your interference somehow. If it always fails use the admin console to examine and compare links. The direct linked scene is the way I would do it also, in that case. From programs you could operate the light directly. ISY doesn't know anything about secens anyway as they have no status. My ISY bulbs and strips are all RGBWW units. I have 31 units now. To control them I use NRs to send command like URLs, receive them in my own NRbridge software, running inside polisy, that determines what brand of bulb they are and sends the appropriate URL lines out to each bulb. By prepping every bul that will be operated first and then sending out the final levels in rapid sequence I can make them appear almost simultaneous (no popcorn effect). In that case the effective "scenes" are hard coded into the NRbridge software. ISY and polyglot NSs haven't been able to do things fast enough yet.

I have never controlled a scene directly from Alexa ----> ISY Portal. I use very few scenes and mostly control programs and/or Insteon devices. The majority of my lights are WiFi protocol so it takes an ISY program to co-ordinate them with Insteon devices/scenes. In ISY Portal I define most of my devices as Switches so they only get On/Off commands. Scenes have no checkback confirmation from the device, so no Insteon retries. If I want dimmer lights I use "Alexa...turn on dim decks lights" and a program does the rest. The delay is insignificant from a vocal command anyway.

@skierdude Use an Alexa device control instead of an announcement

Click on the cyclic arrow,almost top right.

V5.2.0 installed over v5.1.0. Went like clockwork without a hitch. I have only Insteon and LAN based bulbs/devices, no Zwave., + polisy with ecobee NS.

Yeah, programming is critical. Without that 1 minute delay that program could hang your ISY so it may never catch up.

Here is the program I posted: If KPL.A is switched On AND $sLED1.timer <= 90 Then $sLED1.timer += 30 Else $sLED1.timer = 0 Here is what you posted: 'LANE1-30' is switched On And $sS.L1.TIMER >= 90 Then $sS.L1.TIMER += 30 Else $sS.L1.TIMER = 0 Do you see any difference other than the element names? Your other programs have been even worse. You need to proofread more closely.

Turning off the power to these types of devices does not usually work. The control unit will come back on with full On, the last known setting, or not at all. Then it will take 20-60 seconds to reconnect to your router and reset it's circuitry. Likely you will have to get a packet sniffer and hack the bits coming out of the app, unless somebody has already done it for you or they publish a local API for the interface. With an Ardiuno i/f you may have a pretty good chance of access methods. Those lights are pretty cool but any automated lights on staircases is a bad idea. If an off animation like that happened while somebody is walking down the stairs they would likely fall down the stairs. Even just plain old fashioned lights out can cause falls. People's brains react badly to simultaneous physical co-ordination and visual stimulation. Ask anybody that has experienced VR headset simulations.

Yup! UDI is awesome! That is one big reason so many of us are here!!!

You need to pay closer attention to all the lines in the programs. I am totally confused by what you have done. I suggest you copy verbatim until you get it running and then experiment for education purposes.

Just to complicate things here If status of SwitchLinc is On Then turn On light Else turn Off light Functions almost the same as If SwitchLinc is switched On AND SwitchLinc is NOT switched Off <------ when switched off becomes NOT True Then turn on light Else turn off light Except for one small point ..SwitchLinc is Switched ON/Off tells you when a finger is on the switch first depressing it. ..SwitchLinc status tells you level of the dimmer electronics no matter what changes the level. State variables present both a status level and a changes trigger. A SwitchLinc line in a program is only True when being called by the ISY event and always False any other time (the button is not likely pressed, anyway). Status can be true or false anytime. Hopefully my ramblings help somewhat.

That's when lighting power conservation was paramount and there wasn't much more we wanted to control.

@poetaaronFirst get rid of the Else code for each program. When the variable changes to any number less than 30, all program Elses sections will attempt to run simultaneously. Your Insteon system won't like that much traffic. Rather than finding it I will create the countdown timer from mental confusion. If $sLED1.timer > 0 Then Wait 1 minute $sLED1.timer -= 1 Else set lamp Off That's it. Self triggering and self- retriggerring, and simple. ISY is amazing! Oh! BTW! You can right click on your program name in the program tree and select copy to clipboard. Paste into your post.