Goose66

I have a program that puts the house into "Vacation" mode, including random interios lighting, thermostat setbacks, etc. The best thing about it is I can turn off vacation mode from MobiLinc on the way home and the house is cool by the time we get in. I would like to add a setback for our gas water heater. I am also in the market for a new gas water heater. Anyone know of 1) a gas water heater that has an electronically controlled setback or 2) know of a way to add a setback function to a gas water heater?

Anyone doing reliable multi-zone HVAC with an ISY99i? I have looked at a multi-zone controller with 4 Venstar thermostats (very expensive) or several SimpleHomeNet I/O devices with programs on the ISY99i controlling (not very reliable). Is there something in between these, like a Insteon controllable multi-zone controller board that can work with cheaper, digital thermostats. Something like the X10/RS485 devices that RCS used to make (or still does, perhaps).

I guess I don't see how coding the setting of a variable to a specific value and then calling a program to perform the wait is any more "programmable" or flexible than simply coding the Wait statement with the desired value. In fact, it seems to add complexity and an additional program that is not otherwise needed. I guess if you wanted to set the variable with a REST call and then execute the program, but I don't think that is possible as of now, right?

Pardon my ignorance, but what is the advantage of this over simply: Wait 60 seconds Run Program 'DoItNow' (If) ?

I get this message for 2 or 3 minutes after each reboot in the "System Busy" dialog. What exactly does this mean? Does this mean don't unplug or link my Insteon devices, or does it mean I need to make sure there is NO INSTEON TRAFFIC whatsoever during this period?

That is exactly how I do it: https://mydomain.com:60000. Of course, the browser is going to complain about your certificate not being valid. Also, the ISY 99 has an "Enable Internet Access (all devices)" menu item in the Admin console. I have know idea what that does.

So in your router/firewall you have a port forwarding setup, e.g. forward TCP packets received on port 60000 to port 443 of 192.168.1.67 (your ISY IP address) on the internal LAN. The ISY is configured to respond to https requests on port 443 (the default). When accessing from the outside, you whould specify https://72.44.35.91:60000/admin (your DSL modem/cable router IP address plus the target port) to get to the ISY. Every port scanner in the world checks port 443. Don't open up port 443 on your firewall because it will just make you a target. Use something obscure, like 47813, and use the method above to set it up to access your ISY.

The external-facing Internet port can be anything you want it to be. It depends on what is setup for your pin hole and/or port forwarding in your router/firewall. The port set on the ISY is inconsequential, and can remain at the default 443 for HTTPS, as long as the port forwarding in the firewall is set to forward from the external-facing Internet port to the port configured in your ISY on your LAN. I suggest you use a non-sequential five digit number between 33000 and 64000 for the external-facing Internet port. This may make it high enough and random enough that it won't be scanned by port scanners looking for holes in your firewall.

I don't suspect such a feature will be added anytime soon. It has been discussed many times before, and never has been set as a priority by the developers. I (and others) have suggested dummy devices that could be added to the scene to simply reflect the last command issued to that scene (on or off). That has been poo-pooed as well. Perhaps something in a future incarnation of variables will allow a variable to be tied to a scene to reflect its state. But that's a long way off.

For what its worth . . . Each of your scenarios pre-supposes that scenes have a state, e.g. "is the scene active" or "the scene being on." Prescribing a state to scenes does not translate to it being logical that scenes have state. IMO, scenes are simply groups of devices, not devices in themselves. And this is precisely how they work in Insteon. For example, when I send an On command to a "scene" (really a group), each device in the scene is set to its preset on-level. Following your logic, the scene is On or Active. If I manually turn one device Off, then the scene is not On -- it is Off . . . or is it? In you logic there exists an inconsistency between a scene being Off and sending an Off to a scene, which could result in completely different states of the devices. So when is the scene Off -- when it is not On, or when all devices in the scene is Off? The term "scene" is an unfortunate artifact from X10, and it would have been clearer to stick with the Insteon "Group." You can conveniently turn the group on (to pre-set on levels) and turn the group off, but the state of the group is made up of the state of the devices in the group.

I will waste everyone's time by echoing the others' comments. The ISY does not track scene "state," and I don't know that it makes logical sense to do so. If I run around and manually set all devices in a scene to the specified levels, have I activated the scene? Not really, IMO. To keep a KPL button in sync with the scene in the ISY requires programming. Once more, you will want to build in a delay to prevent "bouncing" of the program as the state of the devices change. So, if you have a KPL set to toggle and assigned in a controller for an "All Lights" scene, then you will want a program similar to the following in the ISY: If Status 'Master Suite / Left Sconce' is not Off Or Status 'Master Suite / Right Sconce' is not Off Or Status 'Master Suite / Fan Light' is not Off Then Wait 2 seconds Set Scene 'Master Suite / Keypad-All Lights (Status)' On Else Wait 2 seconds Set Scene 'Master Suite / Keypad-All Lights (Status)' Off This, of course, could be programmed in the inverse, depending on your preference. I prefer "All Off" functionality to "All On." Therefore, if any lights in the "All Lights" scene are on, I want the KPL button toggled on so I can press it and turn all the lights in the room off. Only if every light is off is the KPL toggled off so that pressing it turns all lights on.

That one is a smack on the KISSer.

Er. . . yeah. The answer to your question was somewhere in there. Try this: If Status 'Heating and Cooling / Downstairs-Control' < 78° (Cool Setpoint) Then Wait 5 minutes Set 'Heating and Cooling / Downstairs-Control' 78° (Cool Setpoint) Else - No Actions - (To add one, press 'Action')

With a minute interval, I think both the drift (the inaccuracy) and the overhead would be minimal. You are talking about a 1.6% potential drift instead of a 100% potential drift. I do think variable driven WAIT and REPEAT is coming. With the current integer variable system, this would be trivial to implement (again, IMO) and is probably high on the list of next things for variables. I think float type variables and being able to read and manipulate values from the weather module (such as rainfall inches, wind speed, temperature, etc.) are probably farther away.

Yikes! I would be interested in hearing from Michel on that program. Two issues I see: 1) It is probably not accurate. One thing that event programmers for platforms like Windows know (and I mean that with all due respect) is you can't use a counter as a timer, because event trigger systems tend not to be reliable from a repetitive timing perspective. So, your program relies on the fact that the program will be triggered precisely at the moment that counter is incremented, with no delay. I imagine that will not be the case in the ISY. You may see as much as a one second delay (deferring to Michel, of course) before the program is triggered on the status change. So you may call the program with the variables setup for a 3 minute (180 second) wait, but wind up with a 6 minute wait instead. 2) This will be horribly inefficient from a processing point of view. While the program itself is simple, the high overhead comes from status change of variables and determining which programs need to be triggered, triggering the right programs, keeping up with the variable values and program status, etc. For a 3 minute wait, your setup will be doing this 180 times, which probably makes it 180 time less efficient than a simple "Wait 3 minute" statement, IME.

I don't think we are there yet with variables. Until you can read real-world values into the variables, e.g. 24-hr rainfall, rainfall rate, humidity, date, device dim level, etc., the current variable capability of the ISY is limited to simple counters.

It might help to know what you are trying to accomplish. I use my EZFlora like this (there are three of these programs for three different schedules): If On Sat, Mon, Wed Time is 5:30:00AM Then Set 'Irrigation / Front Yard 1' On Wait 30 minutes Set 'Irrigation / Front Yard 2' On Wait 20 minutes Set 'Irrigation / Front Yard 2' Off Else - No Actions - (To add one, press 'Action') I don't know what advantage there would be to having each zone execute in a seperate program. My way, all the zones and run times are right there in the schedule, and not spread out over seperate programs. So, to answer your questions, it would better help to understand the functionality you desire.

Alternatively, put the KPL button in the 'Ceiling Fan Scene' as a controller and the fan in the scene as a responder. Then write a program: IF 'KPL Button' is switched On AND 'KPL Button' is not switched Off THEN WAIT 1 hour Set Scene 'Ceiling Fan Scene' Off ELSE - No Statements- Since the KPL button is a controller, the LED will turn off when the scene is turned off. This also allows you to turn off the fan with the KPL button (thus cancelling the 1 hour wait program) without having to write a seperate program for off.

That would work as well. Either a variable or a dummy device that could be placed in a scene would be nice. I think you are right that adding a state variable in a scene may be a feature even easier to implement than a dummy device.

No need, you just trigger the program with the same controllers assigned to the scene. That defeats the purpose of the exercise, and doesn't account for all the times you invoke the scene from a program. To use a variable (or a status program, which is how I do it currently), you would have to write a program to set the variable for the controllers of the scene, as well as go through your existing programs and set the variable everywhere you set the scene. The point was (I think) to be able to determine the status of the scene without having to maintain something else in parallel to the scene. In other words, allow the scene to reflect its "state."

This has been brought up before, and the solution that seems to make the most sense to me is the idea of a dummy device. You would put the device in the scene, and when the scene was turned on, the dummy device would turn on, and when the scene was turned off, the dummy device would turn off. You could always check the "status" of the scene via the status of the dummy device (although, as discussed, the status of a scene doesn't really mean much). You could also set a program to trigger on a status change of the dummy device. IMO, adding a dummy device, i.e. a device with no Insteon address, to the ISY device lists would be simpler than changing the programming architecture to allow trigger of programs on scene "status" changes. I don't know what ever happened to the idea of dummy devices though -- I think it is a low priority or they said they didn't want them.

I don't know if you are like me, but I always have my iPhone in my pocket. Why not write a program that runs on an always-on PC in your network that periodically checks the DHCP server to see if your phones preferred IP address is active on the Wi-Fi, and, if so, send a REST command to the ISY to changes a status program to true if you are active, and false if you are not.

What about an oldfashioned mechanical alarm clock with wires soldered to the clapper and bell and connected to an I/O linc for configured to detect contact closure

There use to be an X10 alarm clock (not the mini-timer), although I can't find it now, that would send an X10 command in conjunction with the alarm. It also had buttons on it to manually control X10 devices. A search for one of these may give you what you want, although I think you would have to buy the X10 module for the ISY to get it to run a program on an X10 command.

Ah. That explains why no such device is available, I guess. Unfortuantely it brings up some code violations for me. I have numerous places where I have replaced a switch with Inseton dimmers that switches both a ceiling fixture and outlets (at least the top portion) in the room. Got to keep that in mind when I sell the house.