larryllix

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.

Don't want to hijack your thread but on a similar note, the MS IIs are on sale at aartech.ca for a few more days, and I am wondering if there is any particular firmware versions I should be avoiding?

You may have some oscillating program looping rapidly. ISY is pretty quick mostly. Sometimes I/O can bog things down with full caches.

I agree tha Insteon created a good technology for just that reason but... They are missing some newer idea capabilities by not.. creating smart setup applications installing a second linking pushbutton finding a double tap technique using existing PB adding voice recognition for advanced features installing a magnetic sensing switch (most smart meters have one) etc.. etc.. So that they can support more advanced techniques like.....allowing a device to be involved in multiple controller scenes. I would trade Insteon for the world after seeing all the horn tooting about all the other wonderful, kick-***, new protocols that fill the forums with "How come this doesn't work?", two years after their grandstanding release subsides. ZigBee is the latest and greatest, but people actually living it, constantly tell the public how "it is gonna''". I think it may give Insteon a run for it's money maybe in 5-10 years. Zwave is RF only and I just don't ever see RF only working properly inside any metal box, including a receptacle box.I have a completely metal coated workshop outbuilding = total radio silence there. I remember a guy here updating his parents pool control from X10 to Insteon and wondering why it totally flopped. Consisted of about 5-6 Insteon modules inside a 12 x 18 metal enclosure with all the standing waves one could generate almost destroying all their RF transmitters. Note the 1 x 1.5 size ratio? At least now most Insteon modules allow their RF to be disabled and work on powerline only. In short, All protocols have their individual problems and lack of real userbase experience is what sells most of the new ones. I am sticking with Insteon. Yes, I think they are antiquated in places, and very behind in their paying the Chinese creators to design better things for them, but the best I have heard of, by experienced non-vending users, so far.

It seems that Insteon is still designed around the technique of devices creating their own links without any common controller. On that note, I don't know how a device would "tap into" an existing scene as a controller, using simple taps on a single pushbutton. Insteon has never seemed to recognise ISY (or their own Hub) as tools or even existing.

I had a lot of problems as well as parts of the Alexa app missing while running Android 4.x. Somebody finally identified the app info in the Play Store states Android 5.x and higher. I also had many problems with routine recognising non_US spellings but that was for vocal recognition and they always saved OK without any notification of future failures coming.

Sounds like a denial of service attack on the UDP protocol?