apostolakisl

So, this looks somewhat complicated. However looking at the portal, for whatever reason it removes the network module. Which removes all of my network resources controlling my cai webcontrol board and like 200 ir remote codes that my global cache executes.

I wanted to look at the RPi solution, but my searches aren't finding the code you speak of. I certainly don't need an Echo with high end (sort of) sound quality as I have already spent a good bit of cash installing a very nice whole house audio system. So it looks like the dot plugged into my current sound system is the best option.

I'm looking at Echo but the info is somewhat scattered and evolving rapidly. 1) How is this linked to ISY? It would seem that the ISY portal is a necessary item? Is the portal the item that logs into Amazon and the portal serves as a relay to your ISY? Port-forwarding won't do the trick? 2) The portal is currently beta? I don't see it listed on UD's regular web page as an official module. 3) Echo is a one room device? Can it be wired up to have mic's and speakers all over the house or do you need an echo per room? 4) It appears that echo allows voice command activation of programs. I assume it can be used to directly control devices and scenes simply by stating the name? Anything else it does with ISY? 5) Do you have to add every program/scene/device to a list or registry somewhere (the portal?) or do you automatically get control of everything on ISY once linked? 6) And Echo Dot? Is it just an Echo without good sound quality? Thanks for the info.

A common technique If control device x is switched on and control device x is not switched off Then do x Else do y Triggers either pushing on or pushing off paddle Result pushing on runs then (both lines are true, indeed the on was pressed and the off was not pressed) pushing off runs else (both lines are false, though only one needs to be. The on was not pressed, the off was pressed, (not not-pressed)) I believe this stuff is in the wiki. Though it may not be organized as you expect. YOU MUST STUDY ALL PROGRAMS IN TWO WAYS - - TRIGGER AND RESULT 1) line by line as to what triggers 2) line by line as to what constitute the line being true vs false once triggered.

Trigger in a status program is ANY CHANGE. . . .period. The x in "if status x" is has no bearing on the fact that it triggered, it only affects whether the program is true or false (and thus a then or else runs). If status of device is on Then do x Else do y All changes in device trigger the program If it changed to on, then x happens, otherwise y happens. If control is switched on Then do x Else do y All presses of on paddle trigger program. Nothing else triggers this program and x is the only thing that happens, y would never happen as it is currently written.

Status programs trigger on a change in status, the truth or false outcome depends on what status states you included. Triggering just runs the program, whether it is true or false is a separate thing. It makes zero difference what you put in your two connected "or" statements, as long as they are the same. If status is 2% or status is not 2% will always be true just the same as any condition you put there.

The terms "and" and "or" are used to logically connect two conditions, just like in standard English grammar. So, an "and" or "or" without a condition on both sides of it is not doing anything. I wasn't aware that ISY would let you start off with an "and" or "or" statement, since I have never tried it seeing as there is no logic to it. But, assuming ISY does let you, there would be no point in doing it.

What you have written will respond to any ACTION taken AT the switch. Not necessarily any change at the switch. In other words, if the switch is changed because it is responding to a scene, your above program won't do anything. Your program only responds to someone physically pushing the switch. "Control" means that the switch was physically acted upon. You need to use STATUS to trigger a program on any change. If Status is on or status is not on Then do something The above "do something" will run every time the light changes status. "Status" programs always trigger on a change of status and the two lines of code combined with an "or" cover all possible states meaning that it will always be true and run the "then" clause. Keep in mind that an action taken on the switch that doesn't change the status won't do anything, for example, if the light is already on and someone pushes the on paddle.

1) does the connection light turn on your router/isy when the ethernet cable plugs in? 2) check the router connected stuff page and look for something with the mac address printed on the isy (I am assuming the isy has its mac address printed on it, never needed to check before).

You appear to have 3 programs where 1 would suffice. Also, you will soon learn that stufviews program does not fix your issue. There is no need to have a "schedule" program and a separate action program. I am also somewhat curious as to what your schedule program has in the if section that would trigger with manually control of the light causing it to revert back to the scheduled state. Furthermore, stusviews program would disable your schedule program by pressing the on paddle of your light. Unless you later press the "off" paddle, the schedule program will stay disabled forever and your lights will not do their next scheduled activity.

The program that oberkc wrote does exactly that with a single simple program. You must have something unnecessarily complex at present. Either that or you are looking for the program to do something more than you have noted here.

I am curious to see what kind of program you wrote that un-does a manual intervention. Programs only run with triggers. A trigger in a from x to y time are the times x and y. All other times the program sits idle no matter what. You must have included the status of the lights you are controlling within the program for it to trigger the program when you manually change the light. I am curious as to what it is you are doing, mostly because it probably means you have over-thought the problem.

I have 3 fans on my back porch all wired to the same "dumb" switch. I wanted to put them on a fanlinc and would prefer to use one fanlinc to run all 3 fans. I don't have any desire to control the fans separate, having them all go to the same speed at the same time is perfect. I see the fanlinc is rated to 1 amp for the fan, so obviously I need to check the amps and make sure that this is not an issue. Has anyone used a single fanlinc connected to multiple fans?

Turn the fanlinc on high, then pull the string on the fan until it goes to full speed.

It depends on how much you want. If you just need a short run, I would go to HD/Lowe's/similar and have a piece cut to length. If you need 500 feet or something, then I would look at places like Monoprice since I bet it would save a lot of money. I get my cat6 from them and have always been very happy with them. I have never bought thermostat wire from them.

The only way I can reproduce a situation where a program is listed as 1) True 2) Last finish time precedes last run time Is By altering the program while it was running and saving it. All other means of interrupting a running program and will update the finish time. I tested 1) using "stop" command while running 2) "disabling" program while running 3) causing the folder status to turn "false" while running My conclusion: Either ISY firmware has a bug that somehow your program is uniquely exploiting, or you are altering/saving the program while it is running. I suppose your console could also have lost sync with ISY, but that seems unlikely based on the status of other programs. CORRECTION: In an earlier post, I stated that saving a program doesn't trigger or change the status of a program. It does appear to change the status of a program if the status is indeed different than before the save, but it does not trigger the program.

No, that is not true. The program being true occurs when the last execution of the program ran the "then" clause. Saving a program is not a trigger and does not itself force an evaluation of the "if" clause nor does it change the status from prior to the save. Again, your program being true means the "then" ran. If it did not finish running, you either "stopped" the program or the folder it was in turned false while it was running. EDIT: I suppose you could also have disabled the program while it was running then re-enabled it to get rid of the red slash. EDIT 2: And I am very much on board with OberKC. What the heck difference does it make after you save the program from the admin console. That would only matter if you are constantly saving it from the admin console. Which would make no sense. You write a good program, save it, then you don't touch it anymore. EDIT3: Just look at the program summary page. It tells you the last start time, the last finish time, and the outcome (true or false). If the start time and finish time are the same number of seconds apart that your wait is, then the program did finish and did do the stuff after the wait. Your problem as to why your stuff after the wait isn't the way you expect it lies with some other situation that is changing them after that.

I think you are barking up the wrong tree here. Situation. Program last ran true, but it would appear that the then clause didn't finish. Causes 1) The program was "stopped" during the wait 2) The folder it is in was disabled during the wait There are no other ways I know of for a program to abort a running then and not be "false" Those 2 are easy to rule out. That leaves with the possibility that your items after the wait did execute, but some other program or action undid those changes. Check your program summary page and you can see last time program was triggered, whether it was true or false, and what time it finished. If the finish time is the correct amount of seconds after the trigger time, then it did work. Something else prevented the changes after the wait from happening or the did happen and got undone before you checked.

You can also press and hold the up paddle on the non-load switch and that will bring both switches up to full brightness as per your ramp rate speed.

That was a mistake. You probably didn't talk to them after they acknowledged the problem. I got every single one of my switches replaced under warranty which also got me the newer firmware and a few added features. Unfortunately this was prior to dual band. Since the installing the new switches, maybe 5 years ago, no problems at all (except PLM). I suppose you could try getting all those switches that you had to fix yourself replaced if you make a big enough stink. Really and truly, calling smarthome was very hit or miss. Sometimes I would get someone who was lovely and accommodating, other times I got a brick wall.

You can use global cache to do it. REST commands go to it and it outputs the IR codes.

You could always fix your old plm per the instructions on the forum.

I bet you have lots of fluorescent lights with noisy ballasts. That is probably your com issue. If all your lights are on one or two circuit breakers, consider putting a filter on that entire circuit. X10 has filters for that purpose which are very cheap and work just fine for Insteon. Of course, any circuit you filter will also filter out Insteon signals, so you can't have Insteon devices plugged in (although you could use dual band devices and rely on the rf comm). EDIT: and the other thing is that in a commercial complex you may have 3 phase power. You need to have comm bridges between the three phases, or use dual band devices.

I have also seen it on occasion. I really don't know what causes the rare and seemingly random incorrect execution of this type of program. I would speculate that it is related to the issues you mentioned. Perhaps a second instance of the "control off" makes its way around the network and hits the ISY after it has updated the status to off. It could also be that the ISY missed the last event on the device and has the device incorrectly labeled as off even though it is on.

Only if you have an Else clause. But I don't think you would ever have an Else clause for this program, at least not the way I use them. I have lots of these programs. I use them as in bedrooms and bathrooms with a then statement to turn the light on to 15%. This is really nice when you get up at night to go to the bathroom it is an easy way to turn the light on just a little when you want to keep your brain as nearly asleep as possible. Anyway, I can tell you that these programs had issues after some previous firmware updates where they would execute a Then statement when you turned the light off from an on state (the light would first turn off, then a split second later come back up to 15%). I posted that as a bug and it was corrected. So,the "order of operations" is apparently just barely the way it is and modifications to the firmware can tip it the other way if missed.