larryllix

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?

On the MS I 7 rapid taps on the linking button would send the dark signal On/Off without any sensing delay. I don't know if they kept that feature. Most didn't know about it. This always helped me test all the features before placing them back on their higher mounting perches.

I agree with that logic but if you have DNS problems then you should try another DNS service to isolate where the problem is. Maybe your ISP is switching things around. Another thought. It may have been a hot summer and I have had problems with two routers now, (AC1900, Netgear and ASUS units) always in the heat of the summer. A/C controls the temperature but they both gave me trouble in the hottest part of the summer. Now they are both mounted vertically. The cases are both terrible ventilation if I lay them horizontal with their 2 core, 1GHz CPUs, and gave me massive problems.

Yeah. That article seems to confuse DNS with DHCP. They are different things. Your DHCP in your router is giving your ISY an IP address when you power it up. That seems OK or you would be able to access it or anything else. The DHCP in your ISP gives your router it's IP address and that seems to be working OK because you can browse the Internet. The problem codes you are seeing 15,0010 etc.. are defined as DNS errors for various protocols, especially email. This means your are asking those IP addresses (@ Time Warner) to translate your email servers name ("mail.universal.devices.com") into an IP address and it doesn't like something (port or security style?) that or is sending something back that ISY doesn't understand. As an experiment, here is what I would try. In your router turn off the "Obtain DNS Automatically" to manual. This asks your ISP for an address of their recommended DNS server = 209.18.47.62 / 63. Thee DNS servers may not even know who "mail.universal.devices.com" is. Now manually enter these addresses in these boxes. 8.8.8.8 and 9.9.9.9 or 1.1.1.1 or 8.8.4.4. You may have to save and /or reboot your router. Try things again. If this does not work, restore the "Obtain DNS Automatically" again and you may have to power cycle your router to get the router re-grab the IP addresses again.

On that same pulldown menu there is also a 'copy to clipboard' for pasting programs here. Careful with the dimmed values. They may not be exact at next program run Sent using Tapatalk

DHCP is your router issuing IP addresses for your LAN, from MAC addresses. DNS is a server, somewhere, issuing Internet IP addresses from a text URL description. Check the addresses inside your router. It may be your ISP, but usually google at 8.8.8.8 or 4.4.4.4. I have switched to 1.1.1.1 and 9.9.9.9 in an attempt to get away from some of the google spying on my life.