oskrypuch

+1 on control vice status. Believe this is the wiki reference, yes? ... Using Motion Sensors in Bathrooms * Orest

Done. * Orest

Well, that is more or less using a program as a variable, but yes it is a little more elegant. Like so ... Program DoSomething If Then do stuff do stuff Run Program 'DoSomething' (else) Else Thanks! * Orest

From the Program Summary page, programs can be listed as Enabled (on/off), Activity (idle/running 'xxx') and Status (true/false) In an IF statement you can test for the Status like so: If Program 'DoSomething' is True ... I don't see any way to directly test for the Activity of a program, IOW whether it is currently idle or running Then or Else, etc. You could handle it with a separate Program "variable", but that is a bit clumsy. That was what I was asking. * Orest

Thanks R.! * Orest

Is there a way to directly test in an IF statement if another program is active/idle, other than setting/resetting another program as a variable to show the state? * Orest

Just wondering if Canadian locations are supported in the Weatherbug setup? Brantford, Ontario N3T 1R6 * Orest

Check. * Orest

By module here, you are meaning something like an appliancelinc or lamplinc (no report back to ISY), vice a switchlinc or a keylinc pad (which will report a change)? * Orest

Well, bizarrely, this morning all is well. No error message on ISY startup. The only other thing I did was to restore a second time. But, I also held my breath and tapped my head -- that must have been it!! * Orest

"1. Factory reset your KPL and then try the query again. If it gives you the same error while still working, then I suspect a defective KPL" That was the result. The switch is new. So it may well be defective. This is going to be a complicated thing to try to explain to tech support to try to get return on. Any suggestions? * Orest

Cannot Communicate With K-Key - 1 - All ON (16 7B 91 1). Please check connections. However, the Keylinc switch shows its status correctly in ISY, and the buttons are responding correctly to scene changes. I've tried air gapping the KL, did not make a difference. Do I have a problem? What should I try next? * Orest

Thanks Lee, I somehow missed that in the docs. That is what kept me from figuring it out. * Orest

It appears that the Open group is the active one for indicating opening/closing. There is also a Closed group that pops up when you link the device, but this is sometimes ON, and sometimes undefined, not sure what it does. Anyone know? In addition there is a jumper on the circuit board, that is closed by default, any information on it? I am using the external switch input for these, couldn't reliably use the magnets on a metal garage door. Still having some trouble with inconsistency and signals that shouldn't have been sent with the 2421's. Moved an access point right into the garage, and have access points on both sides of the power supply. * Orest

Today, it has mysteriously returned. I didn't do anything differently, not sure what happened. * Orest

Unless I have gone mad, the buttons that used to be on the button bar to suppress automatic wired & wireless updates have disappeared. In addition the menu options (I think they were on the Link Mgnmt panel) have disappeared as well! Not having this feature will drive me nuts, as I have a complicated setup, making one slight change will tie the system up for minutes. This 2.8.10. What gives? * Orest

Wow, a treatise! Great post. * Orest

In line with such considerations, it would be useful to establish a second "wait" command, one that would NOT allow a re-evaluation of the IF clause, during the wait. It is useful to be able to do both, but sometimes you really want the other, and prefer not having to branch out to another separate program macro. So something like this: WAIT (the current wait command) HOLD_and_WAIT (this will wait, but will NOT allow reevaluation of the IF) * Orest

Well thanks. And thanks! * Orest

The one thing that is critical, if such a change is considered, is to ensure that the default instance directs the prior logic, otherwise of course you will break most every non-trivial program statement. But having the ability to selectively add trigger statements in some fashion to each program clause, will surely enrich the environment, perhaps make it more intuitive, and ease the ability to write easy to follow program statements. It should also reduce some of the newbie gotchas, eliminating unexpected (ill understood) program execution or non-execution, and the whole ELSE clause thing. * Orest

... which is a laudable goal as well. It is the same with variables, I have a number of programs set now labelled ... var home var civil day var sleeptime ... and set/reset them with Program Run IF/ELSE statements. That will work, but is a bit clumsy in terms of syntax and readability. DON'T GET ME WRONG, I am very happy ISY as it exists now. It is a very flexible interface, and can certainly get the job done, but that doesn't mean that it can't be improved a bit as well. In the end, it is a matter of how many developer hours there are in a day. Perhaps this can be packaged in a "Pro+" version, with a small upgrade charge, or maybe there just isn't enough general interest to spend time on it. * Orest

There have been occasional discussions here (in my extensive archival reading) about the reported initial confusion, as well as lamenting about the programming limitations, given that all items will trigger a program IF statement program to ®evaluate. I appreciate that this reflects the non-procedural nature of the environment, but even in this event driven milieu it would allow for more flexibility if one could have your cake and eat it as well. I would propose, and of course this is a "big" request, perhaps a version 3 item, that you create a toggle that by default would result in the current logic, but with it unticked in a given program statement, it would allow for specifying and narrowing the items that could trigger the program. It may also be that you could widen the catchment, by specifying triggers that are not actually included for evaluation in the program. Here is what it might look like ... Of course the Trigger condition could be allowed to be more complex, much as the evaluations in the IF statement current. THEN, if you could sprinkle in some varables ... Trigger ON ( (month = 6) and (away = true) and 'BTH Light is switched ON') Oh my! With all that in place, the "ELSE" clause becomes much more useful as well. Thoughts? * Orest

I have a 2420M PIR inside the house in the entrance foyer to turn the light on in the evening in that area for activity. The PIR is fully controlled by ISY (#5 pins bridged) and I have it set to occupancy mode, with a 30sec timer and ON only op. (v2.8.4+) Here is the routine for the lights .... If Control 'entrance / ENT - PIR-Sensor' is switched On And Program 'var civil day' is False Then Set 'entrance / ENT - Pots' Fast On Set 'front hallway / FH - Pots' 70% Wait 1 minute and 30 seconds Set 'entrance / ENT - Pots' Off Else - No Actions - (To add one, press 'Action') And the notification code ..... If Control 'entrance / ENT - PIR-Sensor' is switched On Then Wait 2 minutes Send Notification to 'xxxxxxxxxxxxxl' Else - No Actions - (To add one, press 'Action') The Set 'entrance / ENT - Pots' Off and the Send notification to 'xxx' will only occur once ... Each time there is further motion sensed, both of the above routines will cycle back and reevaluate (while in their respective wait loops). Finally with no motion for 2 min, the routines will finish, one will turn off the ENT Pots lights, the other routine will send the notification. Also, note that in general a WAIT statement as the last line in a group, and not followed by an action, will be ignored. * Orest

So far, working just fine, and wife is happy. (job one) These are brand new KL, so they would be latest firmware, FWIW. * Orest

That is some nice code examples, art! I like that shrewd move to step around the lack of a random number generator in the program. * Orest