oberkc

For something this simple, you could also try using "control" rather than "status" for the two sensors. This would allow keeping in a single program.

There is no doubt in my mind that there is a way. Unfortunately, I am unsure that I grasp what problem you are trying to solve. Furthermore, sensors are either open or closed. There is no such status as "while closing", so we have to work within the framework available. So, to put in different words....You want a program (or programs) to start watching for the entry door to trigger an action (turn on lights), but watch for that trigger only when the roll-up door is open, and for a short period after the roll-up door closes? Is this correct? Furthermore, once triggered, you want the lights to turn off after 15 minutes, unless one of the doors subesquently closes. Correct? As extra credit, additionally limit this trigger to times between sunrise and sunset? At a conceptual level, I think my solution would probably include logic such as: if time is sunset to sunrise (next day) and roll-up is open then watch for triggers (likely achieve by enabling trigger program or program folder, or using a variable) else wait short period (to allow for a period after door closes, ie "while closing") stop watching for triggers (likely achieve by disabling trigger program or program folder, or a variable) run trigger program (else path) (to halt 15 minute period when the roll-up door closes) the logic for the trigger program (enabled or disabled by the program above): if status of entry door is open (status used to halt 15 minute wait period if door is closed) turn on lights wait 15 minutes turn off lights else nothing Hopefully, this will give you some ideas. One problem you will have to consider is what you want to happen at sunrise if you happen to be in one of your 15 minute wait periods. The logic, above, would halt the wait and leave on the lights.

Stusviews' and my approaches are slightly different. Mine, potentially, offers a bit more flexibility regarding how you treat the two time transitions. Stusviews' seems to be a simpler and more elegant approach if you are happy in the way it naturally handles the midnight hour and sunrise if the door happens to be open. If this were me, I would probably pick stusviews' approach.

Well, then, my response might change, depending on how you want the system to behave at the transition times (midnight and sunrise). What do you want to occur if the door happens to be open at midnight and sunrise? Immediately close? Stay open? Start the countdown? Stop the countdown? To get the thought process moving, consider a simple program such as: If Status garage door is open Then Wait 5 minutes Run garage-open-close program (if path) Else Nothing The next step would be how to disable this program during the day. This could be done with program folders or another program such as If Time is from midnight To sunrise Then Enable first program Else Disable first program Depending on how you answer the earlier questions, you may need to add a couple of program steps. Hopefully, this will give you some ideas on how to tackle his type of problem.

Yes, this is the right forum. Since you seem interested in a response specifically by xathros, I guess I will offer no further response. Yes, this is the right forum. Since you seem interested in a response specifically by xathros, I guess I will offer no further response.

Neither am I good at reading those. Neither am I sure that one can determine a failed device from the log. What is the load now...still LED?

This sure strikes me as a communication problem. Have you taken the routine steps to ensure you have communications across legs of your electrical system and that your plm is on a good circuit without lots of other gadgets, computer stuff, ups, Surge supressors....?

I have not experienced, nor heard of, a program in a false folder being run simply because it was being "overwhelmed". I would look for other explanations. Stusviews has one potential explanation. Is it possible that the flag variable somehow changed temporarily?

No blinking indicates no RF signal. Blinking red indicates RF signal, but on same phase. Blinking green indicates RF signal and on opposite phases. (This is all from memory...best to confirm in manuals.) Given what you describe, I would focus first on ensuring you have good communication between legs of your electrical system. I find access points the most flexible option since they can be moved easily. If you have other plug-in modules that can be repositioned, you could try that. Also make sure your PLM is not plugged into the same outlet or circuit having lots of other gadgets, computer equipment, ups, surge suppressors, etc.

http://forum.universal-devices.com/topic/10516-random-all-on-event/

Yes, address is printed on device.

The sliders you reference are, I believe, associated with direct control of a fanlinc. I believe there are also sliders in the admon console when logged on to the ISY. Both will work fine, but the keypad buttons will not stay in sync. For all to stay in sync, use the scenes to control your fan.

It may also be worth checking that you have latest version of software for ISY.

I don't believe the WF2IR can be a part of a scene. Scenes are pretty much the domain of insteon devices (though I think z-wave will respond to scenes when run from the admin panel). You could create a scene (perhaps even a single-device scene I suppose) then use the "status" of one of the scene devices to trigger a program which turns off the TV. Unfortunately, I don't recall that there are dummy scenes on mobilinc. There will have to be an actual insteon device in the scene. Or, you could just run the program directly as suggested by stusviews.

If this were me, and I were confident that I have the correct IP address. I would next start to double-check port forwarding and port addresses. It is possible that there is a conflict within the router, either with a port or LAN address. Sometimes, as devices come and go from the network (usually via wifi), addresses can change and it is pretty easy to have another device taking the one you originally used for the ISY. There are reservations, ranges of addresses reserved for UPNP purposes. In my mind, this whole router stuff is just has too many details that can get messed up. So, I would open up the router admin page and navigate to wherever it identifies the devices currently on the network, and check to see if something else has taken your ISY address temporarily (have you done a static IP or address reservation on your router). Also, some external and internal ports are commonly used by other devices. What internal and external ports are you using to get to the ISY? I recall things like port 80, 8080, 443, and several others that are good to avoid.

When you stated that you lost remote access, I assume that "remote" means when away from home network/wifi (also known as Local Area Network LAN). When away from the LAN, you are on the wide-area-network WAN. The IP addresses are different for the LAN and WAN. The address you got from whatismyip is the WAN address. It is this WAN address you should be using when accessing your ISY when you are away from the house. When I suggested you "confirm it is the same", I was hoping to confirm that the IP address from whatismyip is the address you are using when trying to access your ISY when you are away from your house. This will be different than your IP address when you ARE at your house. This same local address should show up in the ISY admin panel under help>>>about as the URL. The local address probably looks something like 192.168.x.xx, correct? Ports, I understand, are similar. There are local ports and there are external ports. Port fowarding, I understand, connects an external port to a local port. In addition to you local IP address, there is a local port as well. It probably shows up as a two or three numeral extension to your local IP address, after a colon. It probably looks something like 192.168.x.xx:pp. To access remotely, one must have the external port forwarded to the local port through a port-forwarding rule. Then, use the external (or WAN) IP address, with colon and external port number. My external address looks something like 1xx.1xx.2xx.7x:pppp where I have a four-digit port number pppp. My port pppp forwards the connection to the local port (mine is 33) through a port forwarding rule. How are you trying to access the ISY remotely? Through a web browser, or an app, or something else?

that is the way I see it, as well

Well, the fact that your camera continues to be accessible from remote locations suggests something other than the IP, it is still worth checking. There are several ways to check, including from your router and from a command prompt, but it is simple enough to go to: https://www.whatismyip.com/ and select the appropriate options. Once you have your current IP address, confirm that is still the same. If not, I am sure there are other possibilities that can go wrong.

Do you have a static IP address? Is it possible your WAN IP address has changed? Sometimes, internet service providers can assign new IP addresses to your location.

How many programs do you think might be running simultaneously? Your second program might be a better solution if this were truly a problem, but I doubt that you will notice any difference.I have never perceived this to be a problem.

I don't see a way to do this in a single program, but this assumes I have accurately recognized WHAT you are trying to do from your programs. If your current programs do what you want, the benefits of alternative methods will be mostly in the mind. I doubt that there will be a perceptible functional benefit. I am curious...what do you want those variables to become if either of those conditions are false?

I looked into this a while back. My recollection was that there was (at one point) a homelink "base station" which received the RF signal, then sent X-10 commands to responder modules. Another recollection was homelink kits in cars can be trained to transmit X-10 signals, if one has an X-10 RF remote. If true, then train the car to send an X-10 signal to an X-10 transciever, and trigger actions from that via ISY. To be fair, I never did confirm this first hand (at the time, did not have a car with this capability) but it sure seemed intriguing. Now that I have cars with this, I should look into these kinds of options again.

Rarely is there consensus, because there are usall many ways of solving a given problem. Everybody has personal preferences (mine are to minimize numbers of programs and use variables only as last resort.) Report back when you return and we can continue this discussion. There is a solution, so long that your requirements are fully understood.

I dont expect this to affect other devices on your network, unless you are trying to reservean address already taken by one of those devices.

It looks to me as if you have gotten good advice from others and several options to consider. The only thing I care to add is to encourage thinking, just as you have been, about the details of WHAT you are trying to accomplish, rather than HOW, rather than jump jumping straight in with coding. Continue to consider the boundary issues...what do you want to happen when you transition from home>>>vacation>>>home during those from/to times. I find, often, that fully defining what you want to happen will result in the logic and coding taking care of itself, or at least pointing to an approach. I definitely like the idea of folders for home and away. I also tend to like apostolaksl's approach, where one could do something like: if home then run away programs (else path) run home programs (if path) else run home programs (else path) run away program (if path)