oberkc

I am with LeeG on this one...something is not quite right. I cannot help but suspect I am missing part of the puzzle here. How do you inend to actuate the doors when at home or arriving/leaving? Existing button? Insteon keypad or switch? Phone app? What purpose does the "garage door open/close" variable serve? Are these state or integer variables? Assuming that I correctly understand what you are trying to do, perhaps the better approach would be: a) ensure that the garage door status variable is an INTEGER variable. (Integer variables do not trigger program evaluation.) update your close program: if status $garagedoor = 1 then set garagedoor open-close on (the relay)

No, I dont believe so. At least, not without extraordinary effort.

A FASTON or FASTOFF is a quick, double press of the insteon switch. If the switch is a dimmer, a FASTON will always bring the local level to 100%, regardless of preset ON levels. If the switch is a relay, both ON and FASTON bring the switch to 100%. Given this, a program based on switch "status" will react no differently to ON or FASTON with a relay device, but could react differently for dimming devices if the ON levels are something other than 100% and your program is designed to recognize this. A program based on switch "control", however, can recognized the difference between ON and FASTON.

Mobilink can. I dont know about the others.

I can only think of the obvious things. Are you putting the remotelincs into linking mode? Are you choosing the option in the ISY admin panel to write the changes to the battery-powered devices? Have you checked the batteries? What other RF insteon devices do you have? Access points?

To LeeG's response, I wish to specifically state that status field represents results when the program was last triggered. This can also include being triggered by other programs, and can be affected when a program is disabled.

I find this an interesting request. On one hand, I have been quite happy with my success using the ISY. On the other hand, I know (nor care about) anything Java or external processes. Do you believe such knowledge is required to get an ISY-based insteon system to work? Certainly, I don't.

I am sure that the nest is a wonderful thermostat. No doubt. I assume the same can be said of the ecobeee. I also find the honeywell prestige to be pretty nice. For my purposes, I am VERY hesitant to invest in a thermostat that requires routing through a cloud service to be fully functional. I think this eliminates the honeywell and nest units.

I don't think you can do this with "scenes". In case it was unclear from LeeG response, this likely requires a program. The program could trigger from an insteon device of your choice and cause your spa ready and heater could come on in proper order, with a small wait period between.

Is "Main: Basement Control" or "Main: Trigger Drive-Opened" part of the scene "Basement 3Way"? If so, then your program execution causes a re-evaluation of your conditions, halting execution at earliest wait statement.

This is EXACTLY how "status" conditions work. They trigger on any change of status, execute TRUE (then path) if the change of status matches stated condtion, otherwise execute FALSE.

I think some of my older keypads are v2.D. I have never had any luck getting LED brightness of the older keypads changed via the ISY (regardless of software level).

There are Lots of internet-enabled thermostats out there, but I suspect that the fact that rschneid posted his question on a UDI/insteon/ISY-994 forum suggests interest in integration with the ISY-994. Recommendations for thermostats without such capability are, in my estimation, non-responsive.

if you simply want to turn hot water off at 1am and on at 430am, a simpler approach might be: if time is from 1am to 430am (same day) then turn hot water off else turn hot water on One benefit of this approach is that it is more tolerant of power failures during the period between 1 and 430.

For whatever reason, I found the morninglinc to be more marginal in communication than the rest of my devices. Perhaps your problems are completely unrelated to setup or firmware version. Have you tried temporarily moving the morninglinc closer to your PLM?

In addition to the access point suggestion by LeeG (which I second), there may be benefits to using a "program" rather than a "scene" to control brightness, but this has no effect on what you need to purchase. While you did not mention it, is integration with your Elk system important? If so, be aware that this requires an additional "purchase". There is an add-on software module required with the ISY-994.

The most common methods are: a) ensure you have communication between legs of your electrical system. This is typically assured by using two dual-band devices and verifying on opposite legs via the process described in the user manual identification and elimination of devices which interfere (either actively or passively) with insteon communication. There is no easy way to do this. First is to identify suspect problem-causers. Unplug suspects and see if communication improves (if so, filter that device). Initially, consider computer equipment, including UPS and surge suppressors, TVs and AV equipment. c) addition of insteon devices, to repeat signals to distant locations. d) reading of prior posts on this forum to learn the various methods and ideas.

Such as with a keypad button (which, I submit, is the most common of "clients"). Perhaps, someday, we can have a means to easily duplicate a configurable keypad function on a tablet, and use them in place of a keypadlinc. In my mind, we are not quite there yet.

It matters to me, where I use scenes to control status displays, and prefer "ON" to indicate open.

A progam is the best (may be only) way, in my mind. The logic, if not exact wording, is pretty simple If control motion sensor low battery is switched on then send email message else Of course, you have to initially configure the email message.

Cartman413 Your post, and the details you included, suggest you have a good sense of what is happening. The fact that the led is going on and off, and that you keypads are also responding, suggest that the sensor is working, and properly linked via scene. If this were me, I would be focusing on factors that would make communication with the PLM problemmatic. What other devices and gadgets do you have plugged into the same outlet and circuit as the PLM?

As usual, LeeG and Xathros were correct. The part that I missed was that the proposed second program would trigger at sunrise and ALWAYS evaluate as false, regardless of any light status. When this happens, the wait statement will, in effect, halt and no further action will take place (empty else statement). Yes, this is a pretty remote scenerio, but no need to adress it from a programmatic standpoint.

I stand corrected

Are you sure? If the lights were manually turned off during the night, the status would change at that time, triggering the wait program. If, at sunrise, if the lights were already off because of a manual intervention, there would be no status change, thus no trigger and no reevaluation. Am I missing something?

I have been staring at that first statement and I must admit that I am still confused. But...If you think you have it doing what you want, then I am happy.