apostolakisl

Link counts get screwed up with any comm on the system. Have to do them while you are out of the house and programs disabled.

@shunsader I have had this happen before. ISY actually had wrong links in its table, so resetting and restoring did not fix the issue. Had to delete the device from ISY, factory reset, then reinstall it on ISY. Hopefully you don't have the device linked up to extensively. I have had this happen a couple of times. In one instance I had a light in my daughter's bedroom that somehow started controlling our breakfast room lights. Seeing as my daughter turning her bedroom light on was in no way an event that you would have any idea about in the breakfast room, we were very much wondering what was causing.

I have never had a PG2 node that was used in a scene. Always just programs. I assumed that when you deleted a PG2 node server that it would kill any scene associations, so you have confirmed that. Really need to figure a way to migrate to PG3 without having to do any reconfiguring.

Yes, if you use the same slot, the nodes will drop back in to programs and stuff as they were in PG2. You must delete the node in PG2 first, then create the node in PG3 using the same slot. If you restore from a PG2 backup into PG3, then it will bring over your node settings. I believe the best way to do this is. 1) Make a backup of PG2. 2) Delete from PG2 all of the nodes that are either free or you paid for in PG3 3) Restore the PG2 backup into PG3 (there is a button for that). PG3 will install from the backup nodes that are eligible based on payment or lack of need to pay. So any nodes that are free in PG3 that you have in your PG2 install, must be moved over using this technique. Otherwise, you will end up having the same free nodes both on PG2 and PG3 and then it is screwy.

No special receiver. Any dual band device is going to do that. The video shows version 1.05, which I had multiples of and all behaved exactly like the video. I don't know why newer versions would behave any differently, but I can't say having never owned any other version. Certainly the sending of an "on" when getting wet and an "off" when dried would never change.

Here is a video of adding a leak sensor and then confirming its function. If you do these things and don't get this result, then you may just have a bad leak sensor. I would start by deleting it from ISY, factory reset device, then add back to ISY as shown and test as shown. If ISY finds and writes to the device without leaving the 1011 message, then you do not have a communication issue. I can not really comment to much on the nature of the various batteries discussed. Mine worked fine with a regular alkaline aa battery from energizer.

I do something very similar with Elk outputs. Turn unused outputs on/off as "flags" or "binary variable" or "true/false state" "Boolean" logic or whatever you want to call them. I can't say I have ever done a blank program in ISY, but I do have a number with blank then/else clauses. For example, I have a program called "dark outside" that runs true at sunset and false at sunrise. You could have a blank "if" as well and use other programs to trigger a "run then"/"run else" to set the state, but I would just put whatever logic the other program was using directly into the "if" section. But perhaps you might have a system of organization where you wanted to keep the logic separate from the flag. EDIT: Also do it with unused outputs on my CAI webctontrol boards.

If I were to wager a guess, I would say enabling/disabling a program uses less resources than running a program, even a simple one. There is nothing to test, no logic to process, you're just setting a flag that says "ignore program". I'm pretty sure you could fill all of ISY's memory up with disabled programs and it wouldn't slow anything down, but I can't say for certain. Personally, I don't really see that either program format is better or worse than the other from a readability standpoint. The enable/disable style doesn't require any knowledge of ISY triggering rules which to an ISY newbie might make it easier. One minor flaw in the disable style is that if power goes off while one is disabled (after the lights have been turned on) and then restored after 11pm, the next day it will run the previous day's program again. Which if it just happened on the exact day in the spring or fall that you crossed that threshold time, your light would turn on at a very slightly wrong time. Unlikely to happen and even more importantly, wouldn't matter if it did in this application.

I remember that as well. Later I wrote probably the single most variable intensive set of programs ever to track time and date. ISY for a very long time had no way do something as simple as say "every May 18th". You had to go in and enter May 18 2022, May 18 2023, May 18 2024, etc. Or every other day, or on even days, or whatever.

Yes and no. I have no idea how resource intensive various tasks are for ISY, but the first solution only runs a single program each day. All other options run 2 programs each day.

You are speaking of things that have nothing to do with setting a state variable as either 1 or 0. You also haven't posted programs. Post the programs and I will show you how you don't need the 0/1 variable and in fact how they will be easier to follow.

No, you don't see it. It is a one to one relationship. Program true = Variable 1 Program false = Variable 0 Whatever the program is, the variable is the same. There is no need for the variable . . . EDIT: Go ahead and write a set of programs that you think need a Boolean state variable, and I will re-do it without the variable and the programs will have fewer lines of code, no variable, and will be easier to track back.

None of what you say has anything to do with the logic of your program. You are using time conditions to set a state variable. 100% of the time, the variable will match the true/false state of the program. Except on a power outage in which case your variable could be wrong whereas the program will be correct. The state-variable will be in the exact same state as the true/false status of the program. End of story. It is fully redundant. It is also a triggering event, the same as the state variable. It is a one-to-one copy. It would be no different than having 2 or 3 or 10 variables that are just copies of the fist one. I don't know how else to say this. All this stuff about what if the lights change or whatever is not setting the variable. That has nothing to do with it.

?? Seriously, that is your defense of your logic?

I was thinking, would there ever be a logical reason to use a Boolean state-variable. At first, I thought, what if you had multiple programs setting that state variable. But generally speaking, still no, because you could just list those programs true/false status in your "if" and connect them with an "or" or "and" statement. There might be some issues with triggering events since your target program would trigger when any of the listed programs changed states whereas the state-variable would only trigger your target program upon it changing, which under certain logical situations would not change when one of the programs that set it changes. But I can't come up with any actual use cases for this sort of logic.

Hands down, this is the best way to do it. It would only be better if it ran on polyglot. I run it on a 24/7 pc and it works perfectly, but it could be run on rpi, if you can find one as they seem to be in short supply. I use it to track temperature and humidity from Inteon thermostats as well as outside temp/humidity at my church. I use that data to figure out algorithms for running the hvac system. It saves the data as a csv file which open in excel or whatever spread sheet you want. You can set it up to follow whichever variables you want.

Being right or wrong isn't something you elect. Successfully defending your answer and refuting mine would make it right.

Variable is not best. There is NEVER a need for a Boolean logic state-variable. NEVER I tell you! 1) A state variable used in a Boolean context will simply mirror the state of the program that sets it. It is redundant at best. 2) It unnecessarily adds to the list of variables that you need to scroll though every time you write a program that uses variables, plus if you forget what it does, you will have to search your programs to find its use. The ISY AC and its dependence on drop downs and mouse clicks makes long lists of variables a PITA. 3) Using a variable will require extra steps to account for power failure. When ISY reboots, the program will init to the correct state all on its own. The variable will not and would require extra steps to ensure it is in the correct state. 4) Program state change is a trigger, same as a state variable. Should you instead prefer a non-trigger situation, then an integer variable would be a consideration, though you would likely be better off using enable/disable program logic. Again, there is never a need for a Boolean state variable.

It isn't about the bytes, it is about useless clutter. The variable is truly useless, it servers no purpose at all. You could add a useless variable or two to every single program using that logic. I recommend putting ISY on a UPS. This doesn't solve all problems, but I think it is better than having ISY reboot on a power outage. Using a variable will not help you here. Initing the variable just means the variable will be wrong if power goes out while the program is in one state and then power comes back on during the time it should be in the other state. You would want to use a "run at startup" on the program to have things be correct at startup, no need to init the variable. But as I said, I would skip the variable as it is useless clutter. The variable status precisely matches the true/false status of the program, it is totally redundant.

No. In the scenario you posted, program 2 would run at both on times. In the scenario I created, program 2 only runs once, the first time program 1 goes from false to true. Program status is a trigger like a status variable. It must change to be a trigger. So when it runs true the second time, it does not change state and thus does not trigger program 2. But with a "run program 2" in the "then" it will run program 2 twice. No different than if it were just one program.

Using a variable as above is ever so slightly more load on ISY than not using the variable, though meaningless so. There is no difference in Insteon traffic.

This works fine. But you have a completely useless variable. The following is the same function and basic construction without the variable. If From 6:00:00PM To 11:00:00PM (same day) Or From Sunset - 30 minutes To 11:00:00PM (same day) Then blank Else blank Program KitchenEvening If program above is true Then Set 'Kitchen RGBW + puck' On Else Set 'Kitchen RGBW + puck' Off Remember what I said, if you have a variable that only has two states, you usually don't need a variable.

Thank you, I see now. Might change instruction to say

I would recommend using the "notes" to write out in plain English how the programs work regardless of how you do it. Of course I like my method better, save yourself a variable. Anytime you need a Boolean variable (2 states), you can always use a program's status to store the two states. True or false, enabled or disabled.

Using @larryllixsuggestion won't help with this issue. To force it to run just once, the first time the conditions are met, you would need two programs. Program 1 If time is from 6 to 11pm Then turn scene on disable program 2 Else enable program 2 turn secne off Program 2 If time is from sunset to 11pm Then turn scene on disable program 1 Elase enable program 1 turn scene off