oberkc

What problem are you trying to solve? The one where the motion sensor will turn on the lights bright, even when the mood scene is set? To solve this problem, you would have to first ensure you trigger the lights from the motion sensor via program rather than a scene with motion sensor as controller. One of the problems you may be running into is that battery devices, such as motion sensors, cannot be programmed without first putting them into linking mode. Your program may be correct, but you cannot make the changes to the motion sensor. You may want to consider pulling the motion controller out of your garage light scene and trigger the garage lights via program. This would allow you to create conditions for your motion sensor to trigger lights, such as lights already off, lights not at 61%, button D not on, etc.... I suspect you will have better luck with this approach.

And more differences.. CONTROL is triggered only by direct action on the device, itself. STATUS is triggered when device status changes for any reason, direct action or otherwise. CONTROL XXX (off, on, dim, bright, faston, etc...) is triggered only by receipt of XXX. IOW, CONTROL ON will not be triggered by receipt of an OFF command.

to access, there is LAN IP adress (192....), WAN address (173....), external port and internal port. Internal port points to LAN address, configured by your router. External port routes to internal port. WAN address is what one uses outside your own network. To access from outside, you may need to add a colon, followed by your external port number. With a web browser and on your own network, what happens when you try to access http://yourLANaddress:yourinternalport? Do you get to the ISY. If so, what happens when you open a web browser outside your network and access http://yourWANaddress:yourexternalport?

Yes, you correctly identified the cause and solution. These lights should turn off when both variables are 0. If you wanted to check state of something, one way would be to break this into two programs, where the first calls the second, the second is disabled (will not self trigger), and checks state before performing action.

I don't believe programs "runs constantly". If a program shuts of your lights, it is likely because one or mor e of the program conditions gets triggered by something. Perhaps you should post your program. Yes, there is a way to do what you want.

Program state reflects results of condition when last evaluated. If a program last ran three days ago, and executed the THEN path, the program status will be true and remain true until it runs again.

I would like to think it would be as simple as your original thought. I have not seen multiple IR codes registered from a single remote button press...for me it is just one press, one code.

Do you not have an ISY? If so, then you have something with X-10. Triggering an ISY program from an X-10 command from a transceiver would be an option to consider.

I see nothing in your front lights off program that would explain a program cause for your 'didn't shut off failure'. Are you sure there was power at the time? One thing I noticed is that the above program calls program 3 (if path), yet program 3 has no IF condition. You may want to change this to the THEN path. I suppose a bunch of queries could work, but it seems to me that it would be simpler to put an additional OFF time in your second program, as a backup, for times when storms and communication problem pop up: If Time is Sunset + 1 hour and 5 minutes or time is 2am <<<<backup! Then Set Scene 'Front Low Volt Lights' Off Else - No Actions - (To add one, press 'Action')

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?