jtara92101

Unfortunately, using a scene isn't going to help anything. There's actually NO WAY to switch to PROGRAM AUTO mode with a scene WITHOUT setting a heat and cool setpoint! It looks like there might be a fundamental disconnect between how the thermostat works (in PROGRAM AUTO) and the isy interface. PROGRAM AUTO and settings setpoints = DOES NOT COMPUTE!

The problem is that when I use an isy program to change the thermostat to AUTO PROGRAM mode, after previously having changed the setpoints while in AUTO, HEAT, or COOL modes, it does not switch to the programmed setpoints. The display shows that it is in AUTO PROGRAM, and shows the current time period (morning, day, evening, night). But the setpoints are those that were previously set by the program. In order to recall the setpoints, I have to manually cycle through the modes using the MODE button until it is in AUTO PROGRAM again. Then, it will recall the correct setpoints. The isy mode change is obviously NOT doing exactly the same thing as using the MODE button! I just checked to see if the thermostat exhibits this behavior when being controlled manually: it does not. If it put it in AUTO and bump the setpoint a few degrees, then hit the MODE button to change it to AUTO PROGRAM, it does get the correct set-point that was previously programmed into the current time period. I had read that on this forum. So, I put 2 second delays in-between each setting, but that didn't help. I will try the "scene" technique, though - thanks! Now, there is an obvious work-around: I would need to duplicate the schedule in an isy program, and change the setpoints to those for the current schedule. I guess that should not be done if it's say, less than 10 minutes to a schedule change (because the clocks won't be perfectly in sync. So, if less than 10 minutes, just let the pending time-period change handle the set-point change.) I could also use a similar program to "advance" to the next time period. That is, let's say it is evening, and I am going to bed early. I could have the "goodnight" program change the setpoints to the "night" settings. Eventually, the "night" program will come along and take over (with the same set-points). I think this bug has probably been missed because most people are managing the thermostat completely from the isy, and not using AUTO PROGRAM.

I'm having a problem using a Venstar T-1800 with "home" and "away" programs. I want to use the Venstar's built-in "Program Auto" mode when I am NOT away. Rather than setting a daily schedule to set-back the thermostat during the day (I work at home) I've set it up for "comfort". A bit warmer in the morning for waking/shower, etc. But set-back for non-occupancy is handled by the "away" program. The away part works fine. The program switches the thermostat to AUTO mode, then sets the cool setpoint to 90 and heat setpoint to 50. Home is where I have the problem. I've tried every possible order and delays, and the setpoint is "sticky" when setting the mode to Program Auto. First, I thought I ought to reset the default AUTO temperature. That is, I don't want to leave it at 50/90, in case I might want to manually switch to AUTO mode at the thermostat, I'd want a reasonable default value for setpoints. (So, restore AUTO to the previously-programmed setting.) So, I tried going to AUTO (in case it was changed manually), change the setpoints to 68/78, then switch to PROGRAM AUTO. But the setpoints remain 68/78, not the appropriate PROGRAM AUTO setpoints! If I DON'T reprogram the setpoints to 68/78, then it's even worse - they will remain 50/90, even though the thermostat DOES change to PROGRAM AUTO mode, and shows the correct time period. Manually hitting the MODE button on the thermostat so that it cycles back around to PROGRAM AUTO corrects the problem - it changes the setpoints to those for the current time period. I tried cycling the mode through OFF in the program (AUTO, change setpoints to 68/78 to reset the AUTO setpoints, OFF, PROGRAM AUTO) and that still doesn't fix it - the setpoints remain 68/78. The only way I can get it to go to PROGRAM AUTO with the correct setpoints from the thermostat's program is to manually use the MODE button.

Thanks - I was able to replace all of my V35 Switchlincs. It didn't help that the Wiki was down when I started this (it seems to be down often lately). Sure wish they would just document everything in the manual! I think as BrianH suggested, the problem might have been the remaining V.35 devices making it difficult to communicate. Probably a good idea to disable all them when you start the process. What happened on the first one is that the Administrator got "stuck" with the little 101010 tags pending and it never did reboot itself. But it was OK after a manual reboot. It seems it DID do the replacement, but somehow got out of sync with the Administrator application.

Thanks - I was able to replace all of my V35 Switchlincs. It didn't help that the Wiki was down when I started this (it seems to be down often lately). Sure wish they would just document everything in the manual! I think as BrianH suggested, the problem might have been the remaining V.35 devices making it difficult to communicate. Probably a good idea to disable all them when you start the process. What happened on the first one is that the Administrator got "stuck" with the little 101010 tags pending and it never did reboot itself. But it was OK after a manual reboot. It seems it DID do the replacement, but somehow got out of sync with the Administrator application.

I am replacing my V.35 Switchlincs, and am not having much luck. I was able to replace one by doing a lot of experimenting and fiddling around, but at this rate it is going to take 1-2 hours to replace each one. I suppose, though, it might be done by the time I get a call back from tech support, which is an exercise in futility. I had to follow some threads here, because as far as I can tell, this isn't in the manual at all, and the Wiki seems to be down. The replacement seems to have worked initially - I watched the messages, and it said the replacement was complete, but then I was not able to communicate with the device. That is, couldn't turn it on or off, query, etc. The messages didn't even show an attempt to communicate. After a reboot I finally was able to communicate with the device. Is it necessary to reboot after each device replacement? Can we PLEASE have a definitive, step-by-step procedure for replacing devices? If possible, for non-Pro as well as Pro. (I just upgraded to Pro hoping it would gain me something,, but doesn't seem to be helping the extremely drawn-out process.) This wasn't what I was planning on spending my ENTIRE day on today!

There's some info on this in AVSForum. I just did this as an experiment to give iRule a test spin, since I didn't have anything else I could actually control with iRule! (Much-touted ability to control AV devices over IP is limited to just a few models - mostly Denon, and I don't have an IR gateway yet.) You'll definitely need the forum posts to get it going. You need to make sure to include the user name and password in the gateway setup (admin:admin@1.2.3.4) even though this doesn't seem to be required when you just access the REST interface from your brower's URL bar. Definitely do-able though, but a painful, slow process and, IMO, really, really ugly hard-to-read button artwork. You can create your own artwork, but that will just draw-out the process further. Edit: well, I HAD this working last night. Now I just get "Failed to connect to gateways!" Didn't change anything.

2. If you have the space, I'd recommend not using the built-in dimmer on KeypadLincs in rooms with multiple independent loads. It complicates and restricts scene set-up and the ability to fade the entire scene up or down. But I have done this where I simply didn't have room for another switch. For example, in my bathrooms, I can only fit a 4-gang, because that is all the space there is between the studs at the switch location near the door. It's kinda annoying that Smarthome doesn't make reduced-cost KPLs and SWLs with just the switch(s) and no dimmer... So, I have a KPL whose dimmer controls a track light. Next position is a Switchlinc on/off to control the fan, then a SWL for the light over the sink, and a SWL for the shower light. I have shower and shave scenes assigned to A and B. The big "on" button activates a "dramatic" scene, so when guests hit the big on button they get hit with the wow factor - track up, everything else low. (Which includes a framing projector illuminating the square lav basin, and framing projectors illuminating two prints.) D on every KPL in the house indicates on the LED if there are lights on in other parts of the house. Pressing D turns off all of the "other lights". To balance the lights for a scene, I need to first set the track level to where I want it, and then adjust the other lights. This is because the level of the ON button controls BOTH the level of the track AND the over-all level of the scene. In tandem. I need to make sure that I've used appropriate wattages in the track fixtures so that I have some headroom to adjust the scene up or down. (I then read the values from the isy99 control panel, and set those values in the scene.) It's a lot easier of you just don't use the dimmer on the KPL. So, in my kitchen, bedroom, and office, each has a KPL where the load isn't used. Bedroom for example has a KPL, SWL for track, SWL for overhead, and a Lamplinc plugged into the wall for a floor lamp. Kitchen has 6 switches in two locations. I mean, a 6-gang would have been ridiculous! So, loadless KPL, perimeter, overhead, island in a 4-gang at the entrance. Countertop and in-cabinet lighting along with an outlet in a 3-gang on the other side of the room above the counter. Kitchen has a default scene on the big on button, plus cooking, eating, reading scenes (I sometimes read at the island.) If it's not too late, provide enough gangs for a loadless KPL in each room. The isy99 makes creating complex scenes much easier, but I have to say it is not a snap. It can be a painful, slow process. There's a "pro" upgrade that "batches" commands when you change a whole bunch of stuff at once, and, frankly I find the fact that that's an extra cost pretty annoying. It's a ploy to extract more money from installers, because as a practical matter, they HAVE to have that upgrade, because not having it is going to cost them mucho bucks in their time. Without the pro option (which I don't have) you spend a lot of time waiting for the Control Panel to program the switches after every little change that you make. There's no rational reason for the upgrade fee for this, other than to extract the extra bucks from the installers. It's really just the way the software ought to work in the first place! That said, the isy is an essential accessory, IMO, for any Insteon installation that goes beyond simple three-way switches and VERY simple room scenes. It is VERY painful to set-up using just the switches themselves. But you'd get some good exercise running around the house tap-taping buttons!

Is there any way using the REST interface to turn a device on to the device's preset level? DON turns it on full brightness. I know I can specify a level, but what about the preset level? (i.e. the level it comes on to when you tap the switch.) As a practical matter, I probably only need to activate scenes. And the obvious work-around would be to create a scene with only one device if that's what you need. But just curious and if it isn't possible, a suggestion for a future release.

Actually.... I was wrong. I got confused - they are in the other bathroom. The switch I am having trouble with is V27. But I do have 4 V35 SWLs in the system. Among the oddities is a new dual-band lamplinc that doesn't seem to bridge phases most of the time. It's sensitive to where I plug it in. In certain locations an old access point works just fine. Replace it with the lamplinc and no bridging. But seems to work in other locations. I OFTEN get "flashing" of the LED when I press a button that is linked to something. Should the V35s be RMAd? I actually have enough V36s to replace them all, because I just recently got 4 more SWLs, and hadn't installed them yet. I can hold-off installing the new locations until I get replacements.

V35. Need I say more? Got 4 of the buggers. Oh, and one unused one in a box. Including the one I've been having the trouble with. I'll call SmartHome in the morning... (Wandered into the "communication issues" area, and recognized symptoms...)

Seem to have fixed it - deleted scene and re-created it.

In this case, not benign, though. I was getting this message when trying to change either the ramp rate or on level of a couple of dimmers in a scene. Now, I just get the message "request failed". Checking the log, there is no traffic generated. Now I'm getting "cannot communicate with MB Shower". Various messages at different times seemingly related to the same thing - I try to change the on-level or ramp rate of the MB shower in a scene, and it doesn't work, with these various error messages, some of which don't make sense in this context. The slider stays where I put it, but if I move to another node and then back again, I can see that the change was not made. Now despite the fact that the ISY claims it "cannot communicate" with the MB Shower dimmer, it IS able to successfully restore the device. I just queried MB Shower, and then tried again to change the on level. Here's what I got in the log. Anything unusual or incorrect here? This time I got -200000 failed to write device link, 2 times. It's a different error message practically every time! The 7 INST-ACKs below are from the Query I did. The rest of it is from my attempt to change the on level. Tue 11/02/2010 09:52:19 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:52:33 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:52:37 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:52:46 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:52:55 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:53:09 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:53:23 PM : [iNST-ACK ] 02 62 0D.75.42 0F 19 00 06 LTSREQ (LIGHT) Tue 11/02/2010 09:53:42 PM : [ D 75 42 1] RR 26 Tue 11/02/2010 09:53:42 PM : [D 75 42 1 ] Using engine version i1 for 'MB Shower' Tue 11/02/2010 09:53:42 PM : [D 75 42 1 ] Link 0 : 0FF8 [A2000F9F52FF1F00] Writing [A2000F9F52FF1F00] Tue 11/02/2010 09:53:42 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:53:51 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:54:00 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:54:14 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:54:28 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:54:32 PM : [D 75 42 1 ] Link 0 : 0FF8 [A2000F9F52FF1F00] *Failed Writing [A2000F9F52FF1F00] Tue 11/02/2010 09:54:32 PM : [D 75 42 1 ] Using engine version i1 for 'MB Shower' Tue 11/02/2010 09:54:32 PM : [D 75 42 1 ] Link 0 : 0FF8 [A2000F9F52FF1F00] Writing [A2000F9F52FF1F00] Tue 11/02/2010 09:54:32 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:54:41 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:54:50 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:55:04 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:55:18 PM : [iNST-ACK ] 02 62 0D.75.42 0F 28 0F 06 SET-MSB(0F) Tue 11/02/2010 09:55:22 PM : [D 75 42 1 ] Link 0 : 0FF8 [A2000F9F52FF1F00] *Failed Writing [A2000F9F52FF1F00]

Thanks, Michael. I guess I just hadn't paid much attention to the local ramp rates, since I rarely use paddles, since I have a KPL in every room that sets a scene (or scenes) for the room. The only stand-alone dimmer I have right now is a brand new one (5.15), so there was no problem programming the ramp rate.

Thanks! So, the only way to do this from a program would be the work-around I mentioned earlier, or else have the program first turn off the mutually-exclusive scenes, then turn on the new one. Since that would cause the lights to blink, the first work-around is probably the best.

-11022 Couldn't open file /conf/fyp.cfg -11022 Couldn't open file /conf/adr.cfg Flash corruption? Restore ISY? I got this when trying to set-up a new scene. I got down to a particular control, and got this when trying to adjust the brightness and ramp rate. I can change other stuff. Also got "cannot communicate with device" but was able to restore the device without error! Just happens when trying to adjust anything in the new scene past what I'd already set-up. Maybe just delete the scene and start over with it?

I gather there is an "old way" and a "new way" to do mutually-exclusive buttons. Administrative Console strongly urges you do do it the "new way". That is, using scenes rather than the mutually-exclusive settings on the switch. In my kitchen, I have a 6-button KPL. A is cooking, B is eating, C is reading. D has another use and isn't mutually-exclusive. I have 4 scenes - default, cooking, eating reading. The main on/off button (not connected to a load) is controller for default, and A, B, and C are controllers for their corresponding scenes. I added the A, B, and C switches as responders to the main scene (linked to the on/off buttons). Then added the main button, B and C to the cooking scene, etc. Then, I changed the sliders for the mutually-exclusive buttons to 0 in the set of sliders for each switch. I also set the A, B, C buttons to non-toggle on. I don't want the confusion of being able to turn off a scene with the scene button in this case. The OFF button is always used to turn the kitchen lights off. You want to cook, you press cook. You don't press cook to turn the lights off! Anyway, this all works fine and as expected as long as you are using the KPL. However, this scheme isn't usable if you are setting a scene remotely (say, with an ISY program.) The problem is, there are no sliders for the button responders in the scene itself! The sliders are there when you select the controller for the scene, but not for the scene itself. They are there in the device list, but no slider! When I activate a scene, (say, Cooking) using Administrative Console, A, B and C ALL light up! What am I doing wrong? I can see a possible work-around by putting each button as a responder in a scene by itself, and turning scenes ON or OFF from the program to effect the LEDs. It appears that a button responder can never have a slider in a scene, but always does for a controller of the scene? Why isn't ISY capable of doing what a hardware controller can do?

Indeed, air-gapping the Switchlinc does make the ramp setting "stick". Thanks! As well, setting the ramp rate by setting the brightness level with the paddle and then double-tapping works as well. (But, of course, isn't accurate, and won't program over the full available range.) The dimmer is marked V3.3, and reports V2.7 in Administrative Console. (Guess these are a hardware and firmware version?) These aren't really ancient. Strange thing is, I swear this used to work. But maybe I just never noticed. I seldom use local controls (lots of Keypadlincs that control groups of dimmers). I guess the ramp rates would be made permanent the next time I have a power outage or flip the breaker, LOL. And when you are installing switches, the probability of flipping the breaker is increased. (I don't know about YOU, but...) I wonder, though, if Universal changed something about how it goes about setting the ramp rate? It's just so strange I never noticed this before! I mean, what's the first thing you want to do with a Switchlinc? Fiddle with the ramp rate, of course!

This is probably related to my ongoing issues related to having replaced my PLM with a dual-band model... I can't change the local ramp rate on any of my "old" Switchlincs. The ISY acts like it is changing it, and the log produces traffic when I change it. But the change doesn't take effect. The ramp rate doesn't change. Changes to local on-level do work correctly, though. As well, changes made to the ramp rate in scenes work correctly. Recently-installed devices work as they should. This includes both old (never installed) stock and newly-purchased devices. If I factory-reset a device, it resets the ramp rate back to .1 second. If I remove the device from the ISY, restore the ISY, and restore the device, the ramp rate gets programmed to whatever it was in the database. So, it IS able to change the ramp rate! But the only way I can change the ramp rate is by doing a "restore device". Example: I had all my devices set to 2 seconds, but I want them at 0.5. A few days ago, I was able to change all my devices to .5 seconds. But, apparently I forget to change one of them, or else the problem started when I tried to change that device... If I factory-reset that device, it goes to 0.1 second. If I remove it, restore the ISY, and restore device, it goes to 2 seconds. If I change it to, say, 30 seconds - it stays at 2 seconds! I don't know that I'm going to convince SmartHome to replace all of my old devices.

Now I do, but I didn't before I fixed it. You may have missed one post: I was able to fix the problem by adding the KPL and all of it's buttons to a scene as controller, adding something to control, verifying that all the buttons can control the load, then deleting the scene. After doing this, all of the buttons will then produce traffic. They didn't produce traffic until they were first added to a scene as controller. I think they may have somehow still been linked to the old PLM.

F.9f.52 V92/Connected 132

A bit off-topic, but I wish Smarthome would (a) catch-up, it's 2010 and ( be more explicit and technical about just what can and can't be dimmed with their dimmers. "Only rated for incandescent loads" is a non-starter. Incandescent lamps are very close to being BANNED, at least here in California! As for halogens, they ARE incandescent. However, they are often low-voltage, and there are multiple technologies used to deliver the lower voltage. There are dimmer compatibility issues for the various technologies. Now, there are some lamps that just can't be dimmed at all - for example most fluorescents. There is an older method of dimming them using a special ballast, but that requires dedicated controls. Newer ones can have circuitry built-in to allow them to be dimmed. Low-voltage dimmable lamps might use a transformer or an "electronic transformer". A transformer requires a "leading edge dimmer". That means that the "slice" taken out of the waveform to dim is taken out of the leading (rising) edge of the waveform, starting at the "zero-crossing" point. Some older dimmers took a RANDOM slice out of the waveform, and these aren't good with transformers. An "electronic transformer" might require a leading edge dimmer or a trailing edge dimmer. Some newer ones now work with leading-edge. Some are pickier and need trailing edge, and that's a pretty hard dimmer to find, though they are available. For example, all current W.A.C. track fixtures will work with a leading-edge dimmer. The Lightech electronic transformers I use for my under-counter Xenons (another type of incandescent lamp) require trailing-edge. The type of LAMP is irrelevant as far as the dimmer is concerned, if the lamp is low-voltage. The dimmer doesn't see the lamp load. It sees the "transformer" as the load. It's the type of transformer that matters, NOT the type of lamp! If they really are saying "incandescent load only", that means NO TRANSFORMERS, and that's impractical in 2010. The ideal dimmer would determine the type of load, and adapt to leading or trailing edge accordingly. As well, "sine wave dimmers" are becoming more practical, and this would be the real ideal! I *think* that the SmartHome dimmers are all leading-edge. But that's the kind of stuff they never actually tell us. We're too dumb to be able to use that information. At least that's the impression I get from Smarthome.

OK, I found a work-around to get the small buttons on the KPL linked to the PLM. (Right-click on the device list isn't working, so I can't "remove" a device from the ISY). 1. Create a new scene 2. Put some light in the scene as a responder (not sure if this is necessary) 3. Put the button which isn't sending messages to the ISY in the new scene as a controller 4. Push the button to verify that the light comes on. 5. Remove the light and the button from the scene, and remove the scene. This procedure has restored communication with the ISY with all of the previously-unresponsive buttons. I am getting a lot of "Process message failed" messages in the log.

Well, now I've got another KPL that doesn't work. The ISY doesn't follow the status of the D button on my kitchen KPL when it is pressed. This is also true for the C and D buttons on my balcony KPL, and the A, B, C, and D buttons on my master bedroom KPL. Office KPL works as you'd expect. I can see status updates on all 4 buttons. Smarthome previously RMA'd my PLM. They replaced it with the dual-band model, since they no longer had the original one in stock. Not sure if I unlinked things properly when I replaced it. Is it possible that there's no way to remove links to the old PLM? I factory-reset all of the troublesome KPLs and they still act the same way.

I know this sounds strange, but that doesn't work. There is no "remove" when you right click on it. In fact, there's nothing. Now, I DID get a "remove" option the first time I tried this. But I decided not to do it yet, as I wanted to write down my settings, remove the switch from scenes, etc. Now I don't get a right-click menu on ANY devices. I even closed and re-opened the admin console... As well, in the "My Lighting" display, there is nothing shown for "Current State" for the four small buttons on the "bad" KPL. (I do get a current state for the main button.) If I do a Query, though, then the Current State DOES show after that. I do have a bit more information, though. I do NOT see anything in the log when I press those keys. But I'm not sure that I should be, as I tested this on a "good" KPL, and you don't see anything in the log unless the switch is actually linked to something. So, for example, I have a KPL where A controls a pump and B controls a fountain on my balcony. C and D haven't been programmed to do anything. I see it in the log when I press A or B, but not C or D. I'm wondering is the ISY is being "too smart for it's own good". I just checked the current state column for the "good" KPL. It toggles for A and B, but not C and D. Yes, that is it! I added a little program with an "If Control Balcony C On". No traffic is seen, the current state doesn't change, the program doesn't run. Apparently, simply having a program reference a switch isn't enough to get it linked to the ISY?