larryllix

Your program will only run once at sunset + 2 hours. You have no Repeat line.It also does not address your first post request. Re-enable your first program and follow lilyoyo1's suggestions. ISY is a trigger event based processing and easier to use natively instead of creating time delay looping.

I agree, in some cases like pulldown menus where text disappears and you spend hours looking for it. . OTOH I wouldn't want to see device selections that include every variable, devices, network resource, email notification etc.. etc.. for every type of command line. I do like the changeable menus that are in your face to limit your selection to valid ones, as the ISY admin console, though. Better changeable selection boxes than magic functions on touch-screens where you just touch everything you see, to see what happen,s because the manufacturers are too lazy to write a 4,568 page manual that nobody can even understand. Like all top notch software and things in life...the better ones take some time to learn.

In addition, add a following line to run the program (if) in case it needs to respond to the conditions immediately, instead of waiting for a temperature change that could take hours.

Don't forget the phantom All On ghost, and other scenes do not send any status updates, so ISY will not record them. PITA. I had what appeared t be an ALL ON last night at midnight. Then I noticed all my NRbridge RPi software bulbs went full on also. Wit a mix of Insteon and WiFi bulbs it had to come out of ISY. Looks like NR events are not recorded either. I do have routines based on single variables that could have done it but it appears my ISY screwed up somehow writing the wrong value to the variable.

Oh ya' big tease! When I used X10 back in the 1980s, the MSes would send both On and Off and the Off was not blockable. I used both techniques then. The MS on would directly turn on the light (for speed), trigger a program, and then both the program, and the MS off signal, would turn the light off, similar to what can be done with Insteon MSes today. The X10 MSes could be set for 1,2,4,8,16,32 etc... minutes of resettable On time and would act as a backup Off signal to the program, to turn lights off. I see this technique as a good combination of us 'control freaks' vs. you 'Hub bubs' , that could be used for the best of both worlds using Insteon technology and ISY superior. Having said that I only use ISY programmed Offs to control my lights and all MS Off signals are disabled. If my ISY/PLM failed, I would be missing the Off cycles. It may be really annoying but with LED technology now, nobody advertises HA for saving energy on lights anymore. hmmmm….. I wonder if amazon sells sleeping masks???

Without studying the binary Insteon codes myself, it would still seem that the All On command is just another Insteon predefined scene formerly built into all Insteon devices (remnant of the X10 protocol it was created from) . Also, scenes, especially the All On, must be very easy to create by noise and data collisions, and using no data security or else an Insteon device misinterprets it and "cleans it up', repeating a clean signal to everybody.

If I am understanding these devices they would not all be in scenes, or in particular, one common scene, and no other devices in your home turned on?

I still don't believe in the ALL ON phenomenon as thought of by others. However, I did have similar random events for about a year which I finally identified as a scene I had setup myself, by the particular level pattern of the many lights affected. Mine ended up roughly related to a plug-in OnOff module that appeared to be sending that scene code instead of an ACK sequence. Simply power cycling the module fixed it and I haven't seen it again for several years now. AFAIC the ALL ON signal is just another scene being manufactured from noise. These Chamberlain GDO are bad news for Insteon. The last one I installed (with MyQ) crippled my Insteon system at about 40-50% operational. A pair of FilterLincs solved that problem and my system worked better than it did from day 1 with an AC motor Chamberlain GDO causing some minor Insteon problems. I always blamed my OutBack inverters for those problems but it was minor and I never sleuthed it down. A GDO, with MyQ problem makes me suspect the GDO causing havoc with the IOLinc thinking it is seeing a scene command, it is involved in. @James Peterson is the IOLinc in an Insteon scene? Scenes do not create log lines in ISY. No status update is sent. There is no arbitrator in Insteon for the multiple devices that would clash status updates simultaneously.

It will get easier as you go. First you just have to get familiar with how the admin console works and what the capabilities are. You are on your way. Glad it is working out for you. Have lots of fun with it!!

$iUH_Temp and $iUH_Luminance are Integer variables. See the 'i' after the '$'? That is his way of indicating they are Integer types. Go to the Integer variable tab and Add two new variables. Rename them to suit your needs, as he has done to "iUH_Luminance" etc. Now go to your program and after selecting Action, select Variable in the pulldown. Click on the variable name box and scroll down until you see your variable name. Select it. In the third box, select '='. In the fourth box, click on the small caret symbol and it will rotate through all the types of elements that variable can have copy to that variable. The last two boxes you select the device parameter you won't to copy the value of. When you get the line you like, click on Add to Then. When done editing always click Save at the bottom of the program tree.

You may notice that others prefix (at least) their status variables. Integer variables do NOT cause triggered events and confusing the usage of the two can cause you a lot of grief. Some use $s.Variable, and $i.Variable. I use $sVariable and $variable (no prefix for integer types) I also use $cCONSTANT for integer variable names to identify a variable value that is preset and never changes. eg. $sLogicVariable = $cTRUE $sGathRm.mode = $cDIM

Scenes are like presets on your car radio. You select a preset or another and the result has been predefined. It takes a whole lot less protocol communication when the speed and co-ordination of timing between devices is needed.

The ISY logs don't show everything. They show most of the updated statuses and a few other things. IIRC Insteon scenes don't send status updates back so tht may be a large chunk of the HA. How would we pronounce it? AIHA, AI/HA, HAAI, HA/AI, AHA!

I don't have a MSII but I see a few possible problems. First you are not querying the MSII. Insteon doesn't usually work like that. Is the battery level an analogue parameter? If so you didn't post a value. If not having two event based triggers ANDed should never run Then. Sent using Tapatalk

Expanding that somewhat... 'Control switched on' and, 'Control switched off' are two different devices, each with two states. Status is one device with two states. Sent using Tapatalk

To further Paul's explanation... ISY is an event/trigger based engine. It does not loop process as some object oriented engines do. With your time bracketed conditional/trigger/If section: If From Sunset to 10:25:00 PM (same day) Then wait 10 minutes (random) ...this will run at sunset (every day) Else ...this will run at 10:25 PM (every day) If Enable is unchecked the triggers will not initiate processing and it only becomes a permissive window. Calling it from another program it can act as a permissive filter only, without any self triggers.

That was a good technique if you had any code in the Else section. You do not show any. That worked for Control/Switched constructs. Using Status already preforms True or False and runs Then or Else. When you use Control/Switched the only time the If is being evaluated is when a device is being switched. No other control/switched lines will ever be true at the same time. This makes some strange looking/functioning logic. The multiple conditions puzzled me why it should make any difference but using status here is what I think happened. The KPL is switched to Low Your low program detects this as true and al the other ANDed conditions see NOT xxx as true Then runs - the program changes the fanlinc setting ISY wakes up the program again as the status has changed All the conditions are true again and runs the program again....setting the fanlinc again ISY wakes up the program again as the status has changed in all the lines All the conditions are True again and Then runs again...etting the fanlinc again. etc...etc.... etc..... I am surprised we haven't seen complaints about your ISY hanging or running very slowly here. I am surprised we haven't heard about the ALL ON phenomenon here, as you were likely blasting this fanlinc, and KPL LEDs, with high speed long blasts of signals. If you decide to try the variable route I would only use control/switched constructs. Glad this worked out for you!!

The KPL button LEDs can only be operated by scenes. I am not sure which devices are buttons and which are the fanlinc device in your programs. Each program only requires one trigger. The other lines do not perform any function. If 'Fans / Great Room Fan' Status is Low Then Set 'Fans / Great Room Fan Low' On Else -- I would use a state variable and a program and scene for each speed (x4). Then I would use another four programs to set the variable from the KPL. Later, if desired, any program can control your fan by injecting a speed number into that variable. Also a program could convert the operation to one, or two button control if desired. Even a SwitchLinc could then control your fan speeds with a program by rotating the speed number through 0-3. Did you know you can right click on a program and select copy to clipboard, then paste it in a post?

Why don't you post your program doing that here, and maybe somebody can find a hole in it? Right click and the program in the tree and select "copy to clipboard". Paste in a post.

See the list of devices on the left? That is your device tree, found under the "Main" tab in admin console.

Ok. I don't use Polyglot for any bulbs, only my own bridging software so I wouldn't have any feedback. That still doesn't address the brightness levels used by Insteon control. Sent using Tapatalk

Perhaps pseudo devices could be designed so that Alexa thinks it is a device, grouped in each room, and when to asked to "turn on the light" Alexa would be notifying ISY that that room's light be activated. I now have more lights that use WiFi, or other non-Insteon protocols, than Insteon lights, and they do not send any status to ISY. ISY is my main controller and I want to keep it that way to utilise it's logic and control. I also have Insteon lighting that I use with dimmed levels in the wee hours. 100 Watt equiv. bulb in bedside table lamps are not appreciated 100% on. [emoji4] I don't see a way around that without ISY.

OK. so if I am understanding that right. A vocal instructon is interpreted by Alexa, Alexa sorts out groupings and selects a particular light from the generic instruction Alexa turns on this light/device. Here is where it gets tricky. Is Alexa telling ISY to turn on that light? … or doing it under Alexa control, so ISY wouldn't know? ISY could sort out devices in a program to know what room but if ISY gets bypassed, it wouldn't know.

AS something I have never jumped into.... Can Alexa let ISY know which room has been activated, or is this just an Alexa app thing?

As per DennisC above, you should factory reset your switchLincs to erase any links outside of ISY and set them up using ISY. ISY is a good link/scene manager and will make it much easier for any future maintenance. Also, you will be able to control those scenes from ISY programs and peripherals, such as Alexa or Google Home speakers.