larryllix

I started with BSR Canada, devices in the early 1990s. I have some Stanley Canada devices, also. Later, BSR was purchased by a company named X10 and also sold under the Radio Shack Plug'n Power brand. Just looking in my junk box I still have a sealed Universal Interface Module, never opened. Insteon is just new for me at about three years now.

Looks perfect! Controls only true when it calls the CPU to execute the logic evaluation. This means when the sunset trigger gets attention for evaluation the control is always False. Whenever you want to use the time frame logic only as a filter you need another program or use Control for the trigger element. With variable values as triggers, a second trigger disabled program is necessary for the time frame not to trigger Then at the start node and Else at the termination node.

Did you happen to install a KPL about the same time?

Welcome to the forums! Revival for an old thread!

Wow! The CAO Tags are like that too. I can't make them drop signal at either end of my street about 1000' each way. One in the glove compartment triggers about 2km away from home. Scary! The higher frequencies are usually line of site as they don't bend or reflect off things well. What is the ZWave frequency?

I kind of figured the OP may be referring to the ISY programmer/user's point of view but he did post. ..."architecture of the internal system." and the reason I posted "maybe". While UDI has never really released the hidden secrets of the ISY execution engine I see a few ways of doing what they have done. 1) On a time clock basis you scan every line of code and see if any factors have changed. Not likely and maybe the way the antique v4 and earlier versions worked. 2) Every time any event occurs you scan every logic line to see if anything is affected and run accordingly. Maybe? 3) Each time any event occurs, ISY scans a specific and particular link table for that event/device. From there you branch out to evaluate those and only those logic lines or programs involved. Much more economical for CPU cycles and I believe this is the major change to the ISY v5.x event logic engine. Reading this UDI is probably doing some hidden snickering behind the scenes (not Insteon scenes). So while the ISY user / program writer, only sees the ISY magic, behind the scenes the "little ISY engine that could", is polling and scanning at high speed constantly, so the user doesn't have to. This is why I laugh when people suggest linear languages would be so much easier and simpler. I know they haven't written an event based trigger OS yet and most likely will bog down somewhere around the two to three year mark, doing it "My Way". There is always somebody that wrote the code, and doesn't believe in the magic, so that we can.

1) Maybe. The ISY engine evaluates any logic statement containing the element if the element changes value. 2) Yes. Programs voluntarily give up CPU control at Wait, and Repeat statements. 3) NO. It's a multi tasking system that continues with or without ACK / NAK 4) See all above

In another life with X10, or wired security light MSes whifts of snow coming aroud the soffits would set off my lights regularly.IIRC some of those, from the old days, where dual element sensing made to eliminate most of these probelms but they couldnt handle it. Car lights and lightning were handled well but the snow dust in the air swirling around always seemed to be a problem from my experiences. Location is key.

I tried it in one small room but I thought it was slowing down the response. It did seem to make a difference for response speed and I never put the jumper back on. In a small room the reach range shouldn't make any difference. As an aside: I had one report motion while I wasn't home again. Then my webcam didn't connect to verify anything. Suspecting problem I forgot about it until I got home to find a 9v battery testing at 4.5 vdc. No LowBatt signal...and I record them (lowBatts) in ISY in a variable that hold three unit's records at a time.

Mine is up OK also. Perhaps your ISY connection has changed addresses or something ISY related has changed?

It may give some problems with direct scene links between devices but a simple program can alleviate and logic reversals needed. Is it important to not have a 1 second delay between garage door starting to open and the KPL LED coming on/Off?

No hardware or wiring changes are needed. Just take out the Reverse Trigger option and reverse your code logic. THis is easy. First change you device node to read the correct status like "Garage door open" or "garage door closed" ...whichever is correct when On. Then change your If section logic to the reverse logic like... Garage Door Open = On instead of Garage Door Open = Off or Garage_door closed = On instead of Garage door closed = Off...etc. There is a reason that ISY is programmable.

Since you found a changed setting, without a reasonable explanation, I would factory reset the stat and start again. This may cure other problems also.

Is there an Insteon clinic? Did I miss something? Sent from a tiny keyboard. Response may be brief.

Sure. Blame it all on us! Sent from a tiny keyboard. Response may be brief.

Was that link the in ended one? I only get a short discussion on x XML. Sent from a tiny keyboard. Response may be brief.

Thanks. See posts previous for clarification. Sent from a tiny keyboard. Response may be brief.

With no ZWave devices I do not find any bugs in the v5.0.8 firmware. I do find bugs in the admin console ui though. Programs have always run as expected since forever 2015 v3 Sent from a tiny keyboard. Response may be brief.

Yeah, I think you are right. The looping comment is right after the ISY comments so I probably misunderstood it's association. Thanks. Sent from a tiny keyboard. Response may be brief. I can't read the scrambled script on my android Tapatalk, right now, but will definitely be looking at this when I get back to a decent browser.

Maybe you don't know about event triggered programming style. No looping is required. Just put a simple variable =150 in the if section and Then will run every and any time the value changes to 150. Of course you need to use a STATE variable to make it trigger programs auto magically. Sent from a tiny keyboard. Response may be brief.

See Stu's comment above. If you are using the latest V2 Skill then On runs Then and Off runs Else. It doesn't matter what is in the If section then as ut will never be run. I don't use scenes as they are only for Insteon (I have no Zwave) but I have many other types of lighting LED strips and smart bulbs. I only use programs and single devices to control from my Alexa vocals.

The Portal exists in the cloud = UDI server. You connect to it (Portal) and it has an intimate releationship with your ISY and no router security holes created.

Echo doesn't know the diferrence between types of devices, only that they are all just names with vocal definitions.

CAO TAGs Sent from a tiny keyboard. Response may be brief.

Another thing I noticed is the restricted text area. The outside only seems to generate patterns and the Centre displayed about seven characters of text. Way too small for larger messages. Sent from a tiny keyboard. Response may be brief.