apostolakisl

Yes. You could do that rather than manually re-enable. It takes the chance that at the time of the automatic re-enable you might not be ready. If state variable that counts 5 control off from switch used to disable siren is 5 Then disable program siren wait 30 minutes enable program siren

Variables are just as trust worthy as any other programmatic thing in ISY. The only failsafe would be to do an init so if there is a powerfailure it still reminds you. If Time is 8am (or whatever time you want, or multipel times, or whatever) and $i.pusheddisablebutton is 1 then send notification and anything else you want that might remind you If whatever variable you used to count 5 pushes of the dimmer switch Then disable siren set $i.pusheddisablebutton to 1 init $i.pusheddisablebutton to 1 (with this line, even if ISY loses power, when it comes back on the variable will still be 1 and you'll still get notifications) When you manually reset the variable to 0 and manaully re-enable the siren program, also manually change the variable init to 0.

Enabled/Disabled is not a condition you can test in an "If" section. You could add a line to the program that you used to disable it that sets a variable that then causes another program to send you an email every day until you reset the varialbe (which is supposed to be the time you then also enable the program). If Time is 8am and $i.pusheddisablebutton is 1 then send notification If whatever variable you used to count 5 pushes of the dimmer switch Then disable siren set $i.pusheddisablebutton to 1

In a scene like this most all the devices would be responders. You would likely have very few controllers, if any. When you add or remove or restore a responder it only writes the device itself and the controller(s). It does not write to all 70 (or whatever) devices. It is true that the responders in a scene do not confirm receipt of message. If you have consistent failures in that scene, this is not cause to use a program, rather it is cause to fix your com. If your scenes fail, you probably will also have failures on individual device com as well. Also, I would think you would want to hit the "off" button and have everything turn off. Not turn off over the next minute or two. And all the while bottling up your com for other commands.

A program would be a poor choice to turn off 70 devices. That would be 70 individual commands that would have to go out. It would be slow and have much lower reliability. A scene off command is just one command that all the devices respond to. Plus, your program would be a PITA to make as you would have to go through and list each device.

The fact that your computer went to sleep has nothing to do with it. The computer is only a "window" into the ISY. The computer is just where ISY shows you what is going on and a means for you to deliver commands to ISY. It has nothing to do with ISY executing the commands. If your lights kept cycling on/off with the PLM unplugged, then the cycling was not coming from ISY or the PLM. It means you had another device out there that was sending alternating "scene on" "scene off" commands. That is why when you restored the devices it stopped. Also, that is why restoring your ISY did nothing. I wouldn't be surprised if you had simply power cycled your house if that would not have stopped it also since I bet the device simply needed a reboot.

Yes, blank "if" runs "then" at startup. I actually don't think you need to even check the "run at startup box". But it doesn't hurt. Also, you could buy a new thermostat for your freezer. They cost about the same as an appliance linc.

Well, as I mentioned ISY is never going to fail to issue the commands, that just doesn't happen. Then repeat every 1 hour 59 minutes 40 seconds turn on device x wati 10 seconds query device x wait 10 seconds run if of notify-on program wait 59 minutes 40 seconds turn off device x wait 10 seconds query device x wait 10 seconds run if of notify-off program notify-on (disabled) If status device x is not on Then notify me nofity-off (disabled) If status device x is not off Then notify me After a power failure, the freezer will turn on for 1 hour and continue along repeating. If you want it to somehow pick up exactly where it left off, that is close to impossible to do with ISY (at least it would require a bunch of programs and variables and stuff) and is unlikely to be relevant to your chicken in the end. yes

If your cycle start/stop time don't matter then (run at startup on) If blank Then Repeat every 2 hours turn on device x wait 1 hour turn off device x (this will repeat every 3 hours because the wait 1 hour doesn't count in the two hours)

The above lacks enough info to know what it is you mean. What is checking? ISY never does not run a program when the if criteria are met. And for this program the criteria are quite obvious. It would only not run if ISY were not on. Perhaps you mean that it needs to check if the device actually turned on (an Insteon com failure?)

Does it need to be on/off at specific times during the day? Run at startup: If tims is from a to b or time is from c to d or time is from e to f or etc Then turn on Else turn off

I find that google voice recognition is better than Alexa dot. While I have a couple of the full size Alexa units, the one I use mostly for random tasks is one of my dots. Reason being is that I use the audio output jack on it, which the full size one doesn't have (nor does the google home). Google has a lot nicer integration with IFTTT. You don't have to say "trigger" and there are more options for varying the exact words, as well as varialbe substitution (which if memory serves me you can't do with Alexa).

Looks like the driver is built into the fixture, so that rules out hiding the driver somewhere you can't hear it. Doing Teken's test sounds like a good place to start. Obviously, if that fails then you know you have a fixture problem, not a dimmer problem (or both). Also, don't buy a house with 30 feet ceilings helps.

Possibilities 1) LED power supply is defective (have you tried calling them?) 2) Swtich to 2477S (instead of 2477D dimmer) 3) Locate the led power supply remotely where you can't hear the hum

My bet is you already have a wall wart that works, assuming that like me you don't throw them out. 12v power supplies that put out 1 amp or more are pretty common. Even if you have one that is running something else, you could temporarily use it for you ISY. Of course any voltage within the spec range will work, but 12v wall warts are all over the place.

?

OK then. Yes, something like 1213 would not be obvious.

Sorry, my bad, had it swapped. 1015 would be 15th week of 2010. I answered by memory and should have actually looked at it. It is typically pretty obvious since you generally know roughly how old the unit is. You get into trouble when something was made in the 12-15 week of the year where year and week are no longer obvious. But if you look at multiple devices, certainly one of them will make it obvious.

I stand corrected, the program does flash the light, though not necessarily every time both flashes. 1) It works the same with status and control as would be expected under the "atomic" nature of ISY and the lack of any wait or repeat. 2) The program summary page indicates that the program ran in less than 1 second and indeed ends prior to the light flashing even the first time. This is consistent with the atomic nature of ISY "then clause" and no waits written into the program. ISY must hold the Insteon commands in a separate que. I don't know what the que limit would be. I also don't know if the failure of 2 flashes every time is because of out of order commands or failure of the rapid fire Insteon commands. Again, ISY does not gaurantee that commands in a then/else are executed in the order written in the absence of a wait. This is per LeeG from ages ago and then confirmed by me running some math equations where order of operations affected the answer. Usually it ended up top to bottom, but not always. 3) Making it into two programs does not serve any purpose, though it doesn't prevent it from working (I ran it as one program).

There was no reason to make this two programs. But, by "works", I don't know what you mean. The KPL light does what?

Yes, there is a 4 digit code on a white label. example: 1015 means tenth week of 2015 And you should consider getting a new PLM or look at the instructions on how to repair your PLM (on this forum). I bet it crashes again within a week or two.

At one point in time, the atom was thought to be the smallest piece of matter with no further possibility of division, and hence it was named from the Greek word for indivisible (atomos). The word "atom" conjures thoughts of protons, neutrons, and electrons. But in programming, we are looking at the root meaning, not the common meaning. Hence, an atomic clause is a clause that runs as an indivisible unit. Another great example is the word "plastic". Again from the Greek (plastikos), it means "moldable". The word now conjures thoughts of hydrocarbon derived hunks of stuff that surround us in so many products, but that is not its root meaning. A common misconception is that plastic surgery somehow involves hunks of plastic when in fact it is surgery that "molds" the shape of tissues. No pieces of "plastic" involved.

This program is incorrect. 1) The "then" clause of program 2 can't work. Logically speaking, you can not have mutually exclusive commands sent to the same device simultaneously. Even if you could send them, what result could you expect? It would be like you're a soldier and you have four commanding officers yelling at you opposite commands all at exactly the same time. What is one to do? If you separated the commands with "waits", this would allow the the then clause to run . . EXCEPT 2) Program 1 would kill a properly written program 2 (where each then item is separated with a "wait".) The status change in the device would re-trigger program 1 which would re-start program 2 then clause when the light goes from off to on. The purpose of two programs is so that program 2 can command program 1 to disable while it is running. So a program 2 that does not disable program 1 is no different than a single program that puts the "if" and "then" stuff into the same program. Assuming the purpose of the program was to flash a light it would need to be written as follows. Program 1 If status light x is on Then run then program 2 Program2 If blank Then disable program 1 set light x off wait y seconds set light x on wait y seconds set light x off wait y seconds set light x on enable program 1 In short, there is nothing wrong with ISY logic here, the original program is an attempt to execute an illogical programming sequence.

I don't know that whay you say is true. I do know that you can't write a "then" clause with mutually exclusive commands unless you separte them with a wait. A light can't be set to on and off simultanously (twice each no less). In all likelihood, you would see the same behavior each time a "race" program such as above is run. However, it wouldn't surprise me that if you ran multiple programs simultaneously that the processor might treat one of these "race" situations differently and give a different outcome. Regardless, the above program or any like it serves no purpose, so I'm not sure why it was ever written in the first place.

The issue is you have conflicting actions. All items in a "then" clause that are not separated by a wait or repeat theoretically happen simulatneously. So your program is causing some logic issues in ISY being that it is trying to exectue different actions on the same device simultaneously. In addition, a "then" clause should not be considered to run from top to bottom. Experimentally, I have deteremined that it typically does by doing some math functions where order of oprations affects the results, but like I said, not always.