apostolakisl

This is mine. I have it beep to warn that it is going to shut off. Of course you need a newer switch that has the beep function. You could change the "is switched fast on" to "is not" if you wanted that particular function to prevent the timer. The "status not off" is if you shut the light off it will kill the timer so you don't get the beeping. If Control 'Alexis Room / Alexis BR-Overhead L' is switched On Or Control 'Alexis Room / Alexis BR-Overhead L' is switched Fast On Or Control 'Alexis Room / Alexis BR-Overhead L' is switched Fade Up Or Status 'Alexis Room / Alexis BR-Overhead L' is not Off Then Wait 29 minutes Repeat 60 times Wait 1 second Set 'Alexis Room / Alexis BR-Overhead L' 14 (Beep Duration) Repeat 1 times Set 'Alexis Room / Alexis BR-Overhead L' Off Else - No Actions - (To add one, press 'Action')

I have only had one episode of "orphan" links and this occurred when I moved some switches around to different locations and used the "replace with" command. Somehow ISY got some links mixed up and allowed some links to remain that were not part of any scene.

First do as LeeG said. Compare the device links tables to the ISY links tables. If the tables don't match, then do a restore device on them from ISY and see if that fixed it. If the tables do match, then ISY is "confused" and believes the link should be there even though it should not. There is no way to just remove that one link from ISY since it is not listed in any scene. To fix this, do the following: 1) Take notes on all scenes/settings/programs you have in ISY regarding the devices that are correct 2) Remove both devices from their folders (if they are in folders) on the main page of ISY admin console 3) Remove (delete) both devices from ISY, 4) Factory reset both device 5) Add them back to ISY as if they were new to your system, name them, and put them back in the correct folders 6) Re-add them to any scenes/programs and put your settings back into them

I think that this is an ideal way to deal with crossed from/to times. It is an illogical condition and ignoring it as a trigger is likely to prevent the most un-intended consequences. If there are other triggers then you are forced to make a decision, and "false" is of course the only acceptable one.

The fact that a from time and to time that are backwards causes both times to be non-trigger events demonstrates that ISY is capable of ignoring triggers in certain situations. It would be great if one of those situations was by putting a disable/enable checkbox next to any clause that can be a trigger.

I believe that a program like that where the "to" time ends up being after the "from" time simply doesn't run at all (doesn't trigger). So neither a "then" or "else" will execute. Edit: Oops. I meant to say "from" time is after "to" time. But the fact that it doesn't trigger is correct. Unless you have some other condition, the program doesn't trigger. And if you have another condition, the time clause will be "false"

Frankly, with everyone going to the cloud, you can differentiate yourself by stressing the fact that your system data is private. But I do agree that we are at a tipping point where HA is quickly going from a niche, hobbyist product, to a widely implemented system of the masses. I think the time is right for you to secure some big time financing so that you can scale up and make the adjustments needed to be a leader, else you find yourself in the dust. It is a great product, but having a great product is only half of it.

But that really doesn't require a cloud service. You could just easily have all those calculations happen locally and use a network connection to query a weather service in your area. There really is no need to send your personal habits to an offsite server. In fact, with some fancy programming, ISY might be able to do that stuff using the venstar ISY actually is ideal since it knows where and when you are in your home based on light usage and/or if you have Elk connected. And if you have a multi-zoned system it would be very smart following your light switch usage throughout the day it would be able to zone the house according to your usage. I suppose an ISY module could be to install an algorithm like Nest has to automatically figure out a heat/cool cycle that works best for you without you having to write the programs.

The Ube light switches seem like the next acquisition here. It's already Android based. That would really get them into your living routine.

I'm sure its all part of the grand government plan to tell us what temperature our houses will be whether we like it or not. Of course certain people will get waivers, like members of congress.

Google already knows where you are if you have an Android phone. Depending on signal strength, they could even figure out what room of your house your in. I still don't get what is worth $3.2B in cash about Nest. It must be that Nest has some patents that are really juicy for a slew of other things. $3.2B would buy you 16 million thermostats at $200. Now figure that the profit on a thermostat is probably less than half of that, you need to sell 32 million of them. Maybe it could be done to a worldwide audience, but that seems like a tall order. There must be something else there. EDIT: Just read that Nest is shipping 40 or 50k thermostats per month. They expect that they could do as many as 1 million per year if things go well. That is pretty far away from selling 32 million at $100 profit each.

To know how your program would function, we would need to see this program (motion detected). Odds are, what oberkc has posted is probably going to do the trick, but you may have special considerations. His program will keep resetting the timer every time one of the motion detectors sends an "on" command, which is usually how people like motion lighting to work.

I see this problem too. The only thing that will run the else is the program "motion detected" becoming true. And perhaps that is what you want, but I sort of doubt it. You may need to include: and control 'mx-sensor' is not switched off A "control" command is only a trigger when it receives the exact command listed. In your case, that is an "on" command. You need to add "not switched off" so that an "off" command becomes a trigger and since there is a "not" that runs the else clause.

We are talking UBI not UBE here. Ubi is an android based, voice controlled, wall powered digital assistant:http://www.kickstarter.com/projects/607691307/ubi-the-ubiquitous-computer-voice-activated-and-al-0 UBE is a light switch: For what its worth, I believe UBI is planning on supporting UBE. -Xathros Oh Sh**. Sorry.

The prototype UBI light switch which they were showing off at SXSW about a year ago literally was a hacked Android phone. Here is a video I took Which means, that if it has a usb port or if you can open it up, you should be able to find a usb connection and if you are an Android nerd you can probably get into the OS and write you own app to get the switch to use REST to send its status to ISY and to respond to network module commands. Of course that is well beyond anything I am capable of.

My understanding is that you can only have zigbee or z-wave, not both.

What Harmony do you have? I do believe some of the new ones have network accessibility. Anyway, you need the ISY network module to send any network commands to anything. I know for a fact that you can send network commands from ISY to GC units as I have one of the wf2ir models. I have a harmony 890, but it has no network accessibility.

global cache, ps3, harmony, and fios don't link to ISY. You can send commands to a global cache using the network module, and harmony can send IR commands to ISY (if you have the ISY IR model).

You have to put the actual value into each network resource, at least until variables is supported. For example, if the variable can have 5 values, you would need 5 network resources, one for each value. Then you would need 5 programs to call each of those 5 resources depending on what the actual value was. If $x = 1 Then resource '1' If $x = 2 Then Resource '2' And so on, where resource 1 does your UDP posting of the value 1 to your other device, 2 for 2, and so on.

Do you have the network module? Unless you have a way to parse a text or email and plug that into your other application, I am not sure it can be done without using the network module. But someone else may know something I don't.

I haven't thought about "partial ONs" yet as I have no wall dimmers or switches but I have been aware of some of these "non black and white" states devices can have and trying to avoid the gotchas later with careful conditions code. Yeah? Who am I kidding? I change some code every day. I meant "every hour". Trying to reorganise my X10 addresses to accommodate TM751 RF modules around the house. X10 address movement is a grind with the ISY though. You make an address plan and then some MS won't reach that RF module. Plan G next. Thanks. It sounds like you will get your monies worth out of ISY. Just realize, that no matter what the trigger is, if a condition in the "if" section that is a trigger happens, the "then" or "else" stops all waits/repeats and starts over from scratch. It can happen other ways as well. IF control light x is switched on Then do something wait do something If the light is on, and you click "on" that program will restart. An "on" command is a trigger regardless of the current state of the device. So it was true, and it still is true, but it starts over. In contrast to this: IF status light x is on Then do something wait do something This program will not re-trigger since "status" is only a trigger if it changes. This program sits idle no matter how many times you click on the on paddle if it was already on.

An example of what Lee said. If status light x is not off Then do something wait x minutes do something This program will re-start the timer every time the light changes condition even if it never turns off. Like from 50% to 100%. Both are true, but the then clause would terminate and start over from scratch.

Is there a problem just running programs with no conditions defined from the (if) entrance? I have been running programs (if) as subroutines, without conditions, and all seems fine. Is this asking for trouble down the road? There is nothing wrong with programs that have a blank "if" clause. The main reason people do this is to avoid a re-trigger. In other words If status of light x is on Then call then program b Program b If -- blank Then Do something wait do something In the above example, if you had a then clause with a "wait" and the light status changed, the wait would terminate. Doing it this way the wait will finish.

I have had the same problem. I need to disable a bunch of programs for whatever reason (maybe running a scene test) and then when re-enabling you get a little messed up on what is supposed to have been left disabled. I suppose a feature that might be nice is to have a memory preset for enabled/disabled so you don't have that problem.

I would agree that the cai is a good way to get those temps posted. I am not using it to do boiler temps, but am using it for air temps. Xathros will need to tell you how he is getting the water temps, it may be simplest to just strap an air temp device tightly to the pipe, wrap it with insulation, and call that close enough. To get direct temp of water you would need to do some plumbing. I don't believe that you need the network module. The latest cai firmware has a feature in it that posts directly to ISY using the REST. It has been a year or so since I set all that up, so my memory is a bit rusty, but I am pretty sure. You will have to learn a little bit of PLC code to program that cai to send the temps. You will need the network module if you want ISY to send info back to the CAI.