
oskrypuch
Members-
Posts
756 -
Joined
-
Last visited
Everything posted by oskrypuch
-
In ISY I want to set up a scene where a keylinc button being ON, is linked to an appliancelinc being OFF, and of course vice versa. The keylinc is of course the controller. I will also manipulate the scene from ISY statements. The scene is set up easily enough, but how do I amend the behavior of the two devices in that ISY scene, so that they end up being "opposite" action? In other words, when I command the scene ON, the keylinc button should turn ON, and the appliancelinc will turn its relay OFF. Equivalently, when you turn the keylinc button ON manually, the appliancelinc should turn off. * Orest
-
The PLM bypasses the UPS, as otherwise I think it would be blocked from reception/transmission. My ISY has a separate power supply, only the ISY is plugged into the UPS. If the 2450 were plugged into the UPS, I wonder if its signal would reach the PLM, which is on the "other side" (the line side) of the UPS. * Orest
-
This will need some control logic to detect a power outage, and send a new ON to relatch the relay. I will be controlling a NC (not energized, no water) main water shut off valve. The purpose is to kill the water when away, and when a leak is detected by water sensors. I prefer to use a NC water valve as a fail safe. My ISY is on a UPS, so it will live through a power outage, and won't know. Does the 2450 present status when it boots up? Any ideas out there? If not, I may have to rig up a delayed latching relay to trigger something to send a signal "POWER was OFF, now it is ON". * Orest
-
Lee -- Thanks. That's a bummer. Do you know about the 2450 IOLinc? Don't have one of those to test. * Orest
-
It looks like the EZIO does not preserve its output relays states after a power failure. Once power is restored both come on as OFF, although the ISY is unaware of that, until it does a query I suppose. Is this expected behavior? What about the simpler 2450, does it preserve its output relay state across a power cycle? * Orest
-
And I'm holidays this week, will have to wait a week to experience variables! * Orest
-
NO and NC refers to the state with the magnet NOT engaged. And of course NC means electrons are flowing, the opposite to a plumbing valve. * Orest
-
Ah, OK, I think that all now makes sense. Going to my drawer of resistors .... * Orest
-
Thanks! * Orest
-
New install of this device, just using the "O" relays for the moment, will need one or two inputs in the near future. On adding it to ISY I get the following ... The problem ... Noticed that the activity light was flickering intermittently on the EZIO. Further, noticed that the EZIO - B node was flickering back and forth between ON and OFF, remaining ON more of the time. The other input nodes are all OFF. This can't be normal, is it? * Orest
-
Anyone have a good Thermostat Scheduling Program?
oskrypuch replied to mike123456789's topic in ISY994
I have developed kind of a complex set of programs to run two thermostats, in a two furnace, three zoned house. Will be adding the third shortly. I also control the floor heating, but just for away/not away purposes. I have four times of day, morning, day, night, late nite, varied a bit through the week to reflect my habits. Morning serves to warm the house up in cool seasons, night cools it down in the summer. Late nite steps it down a notch in temp as well. I have five seasons, summer hot, summer, spring/fall, winter, winter cold, sensed by the outside high temp and wind chill. Based on these variables, that are set independently by programs, I have a set of programs that drive the tstats for temps and mode. I also provide preference to one zone at some times of the day, allowing it to satisfy its calling before allowing the others to go full bore. Of course I also have an away setting, that I can time out, or just log in and reset. The result is quite nice. Before I had to fiddle with the tstats throughout the year, and things were never quite right day to day. I could post a sampling of the code if you are interested. * Orest -
Yup, you can slice & dice it any way you want, like "m" explains. The Venstar user manual, together with the Receiver user manual makes the options fairly clear Have fun! * Orest
-
Get a wireless temp sensor setup, simple and relatively cheap, cheaper than a second thermostat, which you really don't need. If you have the 1900, you can average the temp from the remote sensor with the thermostat temp sensor. The average temperature of the two will trigger the furnace, or not. If you have the 1800 or 1700 you would need to get a second wireless sensor, and average those two to cover the up & downstairs. The temp sensor in the thermostat would be disabled. Venstar Wireless Sensor Receiver Attaches to, and then snugs into the wall space behind the thermostat. Venstar Wireless Indoor/Outdoor Remote Temperature Sensor Attaches to any wall. No wire to pull, runs on batteries. * Orest
-
All fixed and now working as expected. Thanks! * Orest
-
Rand - Perfect. Thanks. * Orest
-
Finally ... Q. If I remove the 1700 from ISY, with the 1700 already in a multitude of program statements, do the respective statements disappear, get reassigned a random device, or are they marked as undefined in some way? * Orest
-
http://wiki.smarthome.com/index.php?tit ... at_Adapter ... * Tap the Set button on Thermostat Adapter once * Press & hold the Set button on Thermostat Adapter for 3 seconds The thermostat display will flash all the LCD characters twice I read this from the WIKI, I did not do the single Set button push referenced above in the linking procedure, just the hold for three seconds to link it. Q. Do you need to give the Set button a short initial press, before holding for 3sec etc. for linking to the ISY? * Orest
-
OK, pulled the dongle, it says v2.1 on it. On the ISY panel, the version is listed as v.00. Problem with the loading of the device? Did some searching of the forums ... Q. I am thinking that I need to remove that stat from ISY and do a factory reset on the 2441 v2 dongle for good measure, then re-add it. Yes, no? Q. When adding the stat back into ISY, I presume I should use the New INSTEON device dialog, and manually specify a 2441? * Orest
-
[deleted]
-
When I added a 1900 in ISY (MAS), I got a Main, Heat, Cool and Fan control line. Adding a 1700 (STY) I only get a Main. I can still control the 1700, temps and mode show correctly but the Heat/Cool State is blank on its Main page. Is that normal? I could just remove it and try relinking it to check this, but I have it added now to a lot of programs, so would prefer not to do that unnecessarily. * Orest
-
.11 updated to .14 All is well. * Orest
-
Thanks, and even better, so far so good. * Orest
-
I rigged up a pair of triggerlincs on the garage doors. These were programatically tied in to some keylincs and an X10 Ding Donger. Tested it out after the install, seemed to be working fine. Over the next couple of weeks I would periodically get phantom indications that the garage door was open, and curiously I saw the AUX input as showing a value occasionally even though the jumper is set to disable that input. I looked for possible AC noise, moved an access point into the garage, rebooted the triggerlincs, fiddled with the jumper, removed and readded them in the ISY, replaced them (I had two extras), installed NO microswitches to drive the triggerlincs thinking there might be something odd about the magnets and metal door -- this also allowed me to prove the trigger circuit continuity. Finally in desperation I even jiggled the cords, however I studiously avoided factory rebooting the ISY. Nothing seemed to cure this errant behavior. I was about to give up on the 2421s and get some hardwired EZIOs when I hit on the solution ... One night there was a wicked windstorm outside, and the garage door "open" indication went crazy, activating many times an hour. I had to get up and disable the program. In the morning it kind of dawned on me what was going on. The garage doors had been knocked about by the wind. The triggerlincs are screw mounted to the doors themselves. I took another look inside and it seemed that the batteries might have been a trifle loose inside. I stretched out the spring a bit, sprayed it with contact cleaner and then also put two strips of electrician's tape where the battery fits to snug it up. The case seemed to snap together more securely. The problem disappeared! It seems that the vibration from garage door opening/closing, or the wind, or poltergeists would work loose the battery just enough that the switch would reboot or something just short of that, and this had caused all the trouble I had had. If I had set it up with the triggerlincs/switches mounted on the wall, this would not have occurred. However, the physical layout of the door demanded the switch be on the door. * Orest
-
Well, somehow, that is very satisfying! * Orest
-
I want to create two non-overlapping time periods, but with no "uncovered" time inbetween. With inequalities that is easy ... range one if A .GT/E. 8 and A .LT. 9 range two if A .GT/E 9 and A .LT. 11 All values, including 8 and all values between 8 and 11, but NOT 11 are covered in the two ranges, and there are no values between range one & two. So, now the time interval programming ... program early If On Mon From 5:30:00AM To 8:00:00AM (same day) etc. program later If On Mon From 8:00:00AM To 9:00:00AM (same day) etc. Would that work, or would both programs execute at precisely 8AM? The scenario is a manual force of the IF clause in both programs. I may be answering my own question, but I understand that the execution of a time interval IF clause will trigger at the From time and it will run the THEN clause, and then again at the TO time, and run the ELSE clause. If that is the case with the the manual trigger of the two programs, then all should be OK. What I do not want to happen is to ever have the THEN clause from Program Early and Program Later to be executed at the same time, but I do want all times in the range covered with no uncovered time inbetween. * Orest