larryllix

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.

Have you used scene modifiers including battery operate Insteon devices? If so, ISY will constantly attempt to update those devices that cannot be updated without being in "linking mode". Since about v5.1.x this has been a bug in the concept and UDI hasn't fixed it. As a work-around you can disable battery device writes and attempt to empty the ISY cache for each device by putting them into linking mode and attempting to write updates to each device, one at a time. The other method is to factory reset your ISY. Unfortunately, until this bug is recognised and fixed, it will likely keep happening.

Only problem I have had with my NRs is if you change the values of the variable being substituted it may go out with the new value instead of the intended value. The values are substituted at send time, and not at invocation time. That becomes a problem for ISY as it's smallest time delay is 1 second and that makes rapid sending of NRs from a single NR very slow.

When I have events to report via NRs, I use variable substitution, using numbers for rooms or devices, I always include a small chart like this. Eg. Motion has been detected in room 23 <------ was variable substituted all from one NR. Rooms: RecRm=11, EveBR=12, AftBR=13, LLand=19 GathRm=21, MBR=23, Foyer=25, MudRm=29 Shop=31

Be aware of variable substitution also. I operate about 35 RGBW bulbs and strips from three NRs. I rarely use 1 x ON NR, frequently 1 x setLevels NR, and 1 x Off NR, for all devices. Each of the three NRs contain strings of text containing the commands.

Two of my three units were battery run and those two batteries both went dead in less than a year each. One went dead with the spare battery in that time so it consumed two batteries in less than a year. All three are on USB adapters now and that hassle is over now. My other 12 MS1s are still on 9v batteries and I get between 8 to 15 months out of most discount (alkaline Walmart, Panasonic, EverReady) batteries, depending on activities. Duracell 9v batteries lasted about 4-5 months and I finally gave up on them since they became junk.

Mine has been doing this for about a week or more. Looks like GH has some similar problems and a possible screw up in the handshake systems??

Can you say when this started? EDIT: Duh! You already reported the timeframe. I have linked this to another thread where Benoit (the author) has responded.