larryllix

Use the "restore" command on each device in the admin console and then test again. You may be missing a link in some fan controllers.

I use a few state variables that trigger banks of programs, scenes, and NRs to control my coloured lighting and my white lighting. When I want Chistmas lighting I use this. Set $sRGBW.mode = $cMODE.XMAS Set $sWhite.mode = $cMODE.XMAS <---- some predefined permanent value in the constant variable (Integer type) ..and the banks of programs do it all. When you "borrow" a lamp for temporary usage/flashing alarms, etc, the status quo can be returned by replacing the variable with the saved/same value, and your ISY will restore everything again.

Welcome to Google security advances beta! I get this on some google or gmail service about once per month for the last five years. Another new summer student working on his latest security idea.

I use a combination of techniques. For alarming methods I use scenes containing every Insteon light and noise maker in one scene, so I can flash it on and off. For controlling levels of Insteon bulb circuits in my Gathering room I use programs and continuously vary the levels via programs to simulate sunset and late night lighting fade down. Of course a lot of that is combined with 15 or so WiFi RGBW bulbs and lighting strips too. If you operate a lot of Insteon devices from a program you need to insert Wait 1-2 seconds between more than 2-3 operations or you can overrun ISY's Insteon protocol cache. That gives a random bulb change look that isn't desirable. Ramping can help that somewhat. I do use scenes for my same Gathering room bulbs but they are grouped into scenes like "FullOn", "Bright", "Dim", "TV Watching", "Reading". Those are then combined with WiFi RGBW lighting to create the same brightness levels as well as festive coloured lighting. My decks and porch do the same. The MagicHome bulbs are under $10 each and I run a piece of software on a RPi that groups them into scene operations. That is controlled by three ISY NR's and variables inside ISY all based on percent levels.

Use programs to scale through useful brightness levels. I won't use scenes much. I find the really only useful levels to be about 100%, 40%, 20% , and 10-12%, depending on LED bulbs low end capabilities without flickering and extinguishing. It should oly take a few minutes to drag and drop 75 devices into each scene. You aren't going to do it more than once. ISY V5 has made setting levels to a variable and I use it do gradually dim many bulbs to simulate a sunset style lihting drop by multiplying the level of each bulb by a fixed percentage each iteration. I wouldn't try this with scenes as you may wear a few Insteon device EPROMs out, constantly rewriting them.

Can we use it for a musical instrument until fixed?

Because with that size of a business somebody has to answer email and sweep the floors. Rhetorical answer.

I hope it wasn't three short, three long, and then three short again.

I would think an air movement detector would be a better option. Trouble is the size of the circuitry/mechanism in that location. Possibly a vane flap with a CAO Tag sensor on it, could work. You would have to change the CR2032 battery every 8-12 months. The dust and grease may be a problem for any mechanism, though.

Are you using the Chrome browser locally? If so you may need to use HTTP://.... (no 's', & no port:443). You may not be able to use the Basic security technique on a Chrome URL line (browsers will not allow it now) so it may never work. Also, I am not sure a browser will actually do anything for you as it take admin console with java to access it properly. ISY may not substitute a full URL with https:/xxx.xxx.xxx.xxx:433 and you may have to type the whole URL, not just an IP address and port number. Is your browser external to your router to access the port forwarding side?

I wouldn't add too much wait time as the user will activate the switch and walk away, not realising the lights came back on. The user needs to know they came back on. I would presonally use about 1-2 seconds so the user can see what happened.

We still haven't seen any program attempt to help with. That is usually the basic starting point with people wanting help, using a starting model. Anybody else?

When you have a list of Insteon devices to operate, and one hiccoughs, the Insteon protocol will retry three times, each time waiting for a confirmation. Then ISY's cache wil overflow and it will have to drop something = missing operations. Like the rest said....insert some Wait 1-2 seconds every couple of lines and post your program. Right click on the admin tree name of program and "copy to clipboard". Paste into your post using the code feature = '<>'

Try this. Be the ISY program You will turn the light on when sunrise or sunset taps you on the shoulder. If somebody turns the light off, you are not watching it and do nothing because you do not know it. If you want to know if somebody turned off the light, you have to tell ISY to watch the light. Computer programs are stupid. You have to tell them everything, what to do and when.

Yes. Also...Your lines are only about times, not any devices. Device statuses or conditions would have to be in the "If" section to monitor signals from them.

You have nothing that detects the light turning off therefore the program will not turn the light back on. ISY does not continuously monitor anything. ISY only does things when it is told to do it by an initiating device. Your only initiating things are sunset and sunrise.

I really don't know about that one. Is your HDS involved in a scene that you are attempting to update from time to time? Many (me included) use scenes to direct link MSes to lamps and then attempt to change the brightness level and/or ramp speed of the lamp, in the scene. Since about 1-2 years ago ISY tries to update the MS device with the new scene parameters. The MS doesn't, and shouldn't have to, change settings at all. and didn't in earlier ISY v5.xx versions.

@Michel Kohanim The modulus function gives totally unpredictable results. In particular I am attempting $iVariable %= 0.05 It always clears the 2 decimals place value to 0.00 I have experimented with 0 decimal precision variables, using 5, 10, 100, and 1000. With 1000 I got a 700 resultant once which was correct. Lower divisors always resulted in 0 remainders. I also found one trial (but couldn't duplicate again) $variable %= 5 (23.47 %= 0.05 resulted in 2) giving a whole number resultant instead of the fractional 0.02 expected remainder Running ISY v5.3.2 (not the latest) Thanks! This will be messing up a few programs I use. I haven't checked them yet but most are just novelty usage 4 x 2 digit room number tracking in one integer variable. (n-1 x 100 + n)

The first version will refuse to load further if it does not find a PLM. Use it with any Insteon.

Used as an inline "If" construct, this can negate any variable Repeat While $variable > 0 $variable *= -1 Repeat 1 times

My KPL is a 6 LED unit and has no side light LEDs. I can se an LED under the off lens crack but cannot tell if it is on in a medium dim room. That may be a PITA in a bedroom since it may be staring right at you in a sleeping room. All the other LEDs can be turned off with scenes but I have never tried to turn of the "Off" button LED. I avoid KPLs dues to the past ALL ON problems, the alternating status errors, the extreme pricing, the ugly looks against other Decora switches, and the confusion generated to non-technical people trying to tap tiny buttons without proper labelling. I can do almost any function with a simple SwitchLinc and Alexa vocal control. As an example... I use one Switchlinc dimmer in my ensuite bathroom for main lighting (fully dimmble), On/OFF/ & 7 colour changes in strip lighting around the tub on the floor (double tap Off), of the same room. I also use presets for ultra dim mood lighting for bathing, using the same switch.

Yes, but KPL LEDs can only be turned on and off using scenes. Create a scene for each button and manipulate each scene. Dimming is only universal across the whole KPL and can be done by program.

The ramp rate of scenes do not have to be changed. You can include ramp rates to programs in the same line as the operation. That doesn't change any scene presets. Each Insteon device can hold about 256 different scenes as well as the locally operated switch scene from the push buttons and the ISY controlled operations. No scene required or EPROM re-writing or waiting needed.

Remember, when you change the EPROM inside a device you may be wearing out the EPROM. That has been a fear for years but it has never been proven either way. The proper way is to design a scene for every setup and let your programs pick a scene that has the features you preset in it. I avoid scene as much as possible. I prefer the control I get in ISY programming, making changes later on (you will every time you think of something else, otherwise you could have stuck with an Insteon Hub). I use scenes to operate all lights, when I want simultaneous timing for looks, KPL LEDs and MS/Lamp combinations for speed of On response only. I find them more obscure and a large source of confusion for users judging by the scores of basic questions about them in the forums. Most other protocol devices do not have "scenes".

No, No. Program lines are really cheap and easy to write and install. ISY language contains no matrix style operations, lists, dictionaries or arrays. As per @oberkcabove folders can organise programs by any subject you choose. I organise my device tree by rooms/location and organise my programs by functions. Folders can also be used with conditions to allow that folder group to be enabled but, although I use it sparingly, I do not recommend it for most functions. When the folder logic changes your programs can terminate unexpectedly without cleaning up, the folder conditions are very obscure, and programs in a disabled folder cannot be tested manually and the user will not be informed why. When you change the ramp rate or other aspects of a device's EPROM tables it takes a few seconds so multiple device's parameter changes are not recommended without time breaks to avoid jamming up your Insteon comm channel. (use Wait 1-2 seconds between each devices write). This is not as critical for simple ON/Off/Dim operations.