larryllix

Unfortunately, the repeat information in this linked wiki is stated incorrectly as are the syntaxes of both forms of Repeat in the ISY programming. The descriptions should read: "Repeat Every Time causes the Repeat block to repeat with a Wait time specified amount of time (hours, minutes, seconds) on each repeat loop." ie. The loop time in a "Repeat Every Time" will be the total of Time plus any Wait times used inside the Repeat loop statements. "Repeat For Times causes the Repeat block to execute the specified number of times." ie. "Repeat For 1 Times" does not repeat the lines inside the Repeat For any times but rather executes the inside code lines only once without any repeat.

I found this same syndrome quite common among electricians that worked outside in cold weather too much. They would come in for lunch. Crank the stat up to 85 and go back outside after lunch. Guess who breaks out in a sweat that afternoon before discovering the setting? LOL.

Yes I have both my wall switch dimmer and my mini remote operate many programs in parallel, so to speak. This way my wife and guests can understand the actions for scenes to operate the same style. Once they they understand the progression of brightness achieved via fast off , off, dim, brighten, on, fast on commands the mini remote works exactly the same as the wall switch dimmer. Just insert an "OR" in your "If" section of each program with both device's similar commands and have each program turn on the wanted scene for each of the actions. Mine controls a whole room full of lights to different scene brightness levels. If WallSwitch is switched FastON OR MiniRemote is switched FastON Then set FullBrightnessScene ON Else --

I had one of those cheap CFL bulbs drive me crazy for a while. This was not Insteon but my rf remote in the car. The range to open was hundreds of feet but the range to close was only about 15-20 feet.

A CAI WebControl board with case and power supply can send real time from Internet sources into ISY with a minimal program learning curve. Ay date or time value could be then tested from the variables sent into ISY. Later, cheap 1Wire temperature probes, or other sensors, could also be added for temp/humidity values in ISY. http://www.ebay.com/itm/Programmable-analog-temp-humidity-I-O-relay-control-HTTP-email-alert-WebControl-/261778027152?pt=LH_DefaultDomain_0&hash=item3cf32fb290 http://www.ebay.com/itm/WebControl-timer-temperature-humidity-I-O-controller-network-relay-ctrl-chassis-/270809014985?pt=LH_DefaultDomain_0&hash=item3f0d79a2c9 Also, X10 previously had alarm clock looking devices that could send X10 coded alarms to ISY based on an alarm clock style settable device. I am not sure if these are still available.

I don't believe the MobiLinc company can access your ISY. It would have to have your password and IP address to do that. Unless the app is "ratting" on you the MobiLinc company doesn't have that, only the app does. That is no different than any remote access app or even your OS that keeps passwords for user convenience.

http://forum.universal-devices.com/topic/13900-use-of-sysextip-variable-in-notifications/

If they block things like porn access via some third-party service or list it would make sense DynDNS would be too. DDNS servers are just proxies that could get around a simple site-blocking list so it may make sense for them to block DDNS servers for workplace and public access points. I would like to personally thank Grizzy for that email / IP discovery. I have been chasing UDI for access to our external IP address as a variable that we could have ISY send us our new IP address should it change. This is ingenious, I thank you, and I can't believe I didn't think of that simple technique, myself. I already send myself a home status update each morning, when we are away. I am cheaper (relative scale) than that, also, and don't have kind of money to burn on things like that. It's not a negative thing. Necessity is the motherhood of invention.

Inline comments, at the end of each program line, was requested for v5 that could definitely help this problem. We'll see. With the advancement of programming complexity coming on the ISY, this feature will become much more important, also.

I learned from the masters.

Hey! Xathros had to pound that into my brain for a few nights before I caught on. It isn't intuitive or syntactically correct but where else would UDI put it? I could feel your confusion and couldn't sleep.

I went through this same dilemma with controlling scene parameters and it took me a long time to get it through my head. It appears you are still selecting the scene to control instead of the controller (found in the scene pulldown list) When you select the scene in your programs scroll further (probably up) for the "controller device of the scene" in the list. Mine were all at the top of the list above where the pulldown menu displayed on the screen. The "controller device of the scene" is not, in fact, a scene at all, but still on the list. I see no mention of a device that looks like your Door sensor in your programs. In Scene 'Laundry Room / LaundryLamp-On' <---- This should be the "Door Sensor"

Well thought out, and self-documenting variable names, are important for their usage to keep things understandable. State variables can get obscure because when you change the value of one you can trigger programs based on them and there is no apparent and obvious program flow by reading the program tree. In a mostly subroutine flow system they can make program flow branches especially hidden.

I have a few programs that manipulate State variables and result in programs being triggered. As much as this simplifies programs the logic flow is very obscure. I use this with caution but it is the true spirit of event driven software.

Wild cards. We have to have wildcards. Geeesh! There must be a pulldown calendar built into Java already. All the hype for a product that was laying on it's death bed a few years ago ( "We will never produce a 64 bit version"), surely they must have some fancy tools in the API.

+1 ...and a clock?

Sure surprised me, again. Defies logic so I can't remember those things. Maybe the "cloud" isn't so bad if it matches our brains.

State variable usage may have confused my demonstration / investigation and yielded different results. This may be experimented with further. The integer variable usage was intentional to investigate the crossed times not triggering at all despite another condition logic attempting to force ISY back into line with it's usual logic. ISY must be previewing these crossed times and just locks out the program completely from executing whatsoever. Maybe by UDI design and maybe by evolution happenstance. Either way it seems like a necessary evil in the logic of triggers for "real-time made easy" for the masses. Oh those time triggers! Half the forum is based on that confusion. Need to remove the trigger from the "To" clause, or add Ap's checkbox

A little off-topic but... Did you use DNP 3 for these comms? If not what protocols?

My testing demonstrated cross times never triggers at all on either time node. I thought that I could force further evaluation by putting known true or false conditions in with it. As my example shows cross times will not trigger a program true or false. This appears to be by UDI design to stop sunset/sunrise triggers from doing nasty things. This surprised me but IIRC this was discussed about year back in another thread. Try it. I may have been insane at the time. Edit: I found the thread where this was discovered a year ago. Seems like an anniversary maybe? http://forum.universal-devices.com/topic/12251-sunrise-program-question/?hl=%2Bcrossed+%2Btimes&do=findComment&comment=100168

I also have Netgear router and this is the free DDNS service it connects you to. http://www.noip.com/free It is a cloud service that you use to connect through to your router using a fixed URL that doesn't change when your IP address does.

Thanks Brian This looks like a clone, or possibly the same bulb rebranded, of the TCP Connect. These have been in Home Depot for about a year now. http://www.homedepot.ca/webapp/wcs/stores/servlet/SearchView?catalogId=10051&storeId=10051&langId=-15&N=0&Ntt=TCP&Nty=1&D=TCP&Ntx=mode+matchallpartial&Dx=mode+matchallpartial&s=true

Shannong had it. Just add your lamp condition logic. If Time is proper AND Lamp is On Then Adjust scene Set scene On Else Adjust scene

If the device is hardwired into a circuit, the current rating must be rated for the circuit breaker rating. Your main overcurrent protection on your panel at say.. 200 or 400 amperes only feeds the busbars in the panel, which have to be rated to carry that current, and the current level of a reasonable fault (usually 10,000 amperes) until the overcurrent device trips the circuit out. You cannot hook a lower rated conductor or device directly to those busbars without a lower rated overcurrent device, first. There are exceptions for short conductors, portable devices, and special circumstances. He has a sub-panel connected to the 40 amp circuit which further protects the lower rated devices for their rated capacity.

The slang used is not very convincing without proper references. Wikipedia is not a valid reference, according to Jimbo Wales. If you used Wikipedia as a reference in an University report it would be rejected as nonsense. I particularly like where Wikipedia tells us that energy can be created from nothing, complete with nonsense references.