upstatemike

My experience was just the opposite. I was never able to play the violin prior to 2.7.12 and now I can.

Just edited that post because I got it to work after several attempts. (The compare, not the ramp rate setting)

The dimmer had 9 extra links and the remotelinc had 16 extra links. I restored both and now they match ISY. Restarted admin console but still get "request failed" if I try to change the ramp rate. Going to leave it for now and take a fresh look next week.

Nope, no green 1010 icons. Device 00.1A.5A is a SwitchLinc Dimmer v.22 and has been in the scene for years. Nothing has changed in this scene. The only change made was to add new LampLincs to button 2 on a RemoteLinc. Button 1 on this same RemoteLinc is a controller for the problem scene. It was after changing that button 2 scene that the button 1 scene lost its level and ramp settings. Maybe I need to delete and reinstall the remoteLinc?

Not sure what you mean by the correct url? I use a fixed IP address so my url is always 192.168.0.7/admin The event viewer does not register anything when i attempt the ramp rate change and get the "request failed" error. On the same device I do get acvtivity when I try to move the level from 0% (where it is stuck) to 100% and get a "request failed" error... I can send you that log. Also note I do not have either Flex Your Power or Auto Open ADR enabled.

Unfortunately neither 2.7.11 nor 2.7.12 fixed this. I still get this error if I try to change the ramp rate from 9min to 2 sec: [-110022] couldn't open file [/CONF/FYP.CFG] [-110022] couldn't open file [/CONF/ADR.CFG] After this error displays once any further attempt just results in "request failed"

I get this sometimes and can usually clear it by clicking the batch icon twice. One switch is still stuck that way and I assume it is just a communications issue. Was planning to stick an access point close to it to see if that helps.

So your scene sends a group command and your backup sends individual direct commands?

Sorry if this is covered someplace but I couldn't find it. I am on 2.7.8 and I just added two new Dual -Band Lamp-lincs. Since this version des not support replace for these devices, I just added them to the scene they need to be in and configured them to match the old ones. The RemoteLinc controlling the scene using button 2 works fine but the scene on button 1 (which I did not edit) somehow got it's ramp rate changed to 9 minutes. If I try to change it back to 2 seconds I get an error that says "request failed" or "cannot open file xxxx - I can't remember the path and can't get it to repeat). Tried clearing Java cache, tried rebooting ISY. Any ideas what else I can try?

I can understand how an X-10 address can cause unexpected operation of a single module but how was it triggering a scene?

My link count is 754 so yours does not seem out of line.

OK, Thanks. I'll migrate to the next non-alpha rev that comes out.

The module I wanted to replace was a 24456D2 2-pin V.24 lamp module but when I right clicked on it and selected "replace module with", the new Dual-Band LampLinc that I had just added to my ISY did not appear in the dropdown. (It only offered SocketLincs and other 2-pin lamp modules). The new module is a B24572 lampLinc BiPhy v.3A and I went ahead and added it to the scenes manually instead of using replace. I suggest any lamp module should be able to select any other lamp module type (2-pin, 3-pin, or Dual Band) as well as the SocketLinc as a potential replacement.

Just got a Dual-Band Lamplinc to test out and went to replace an existing Lamplinc only to discover my new device is not listed in the replace dropdown. I'm using FW 2.7.8 Is this normal? Do I have to maunually delete the old Lamplinc and add the dual-band to all of the related scenes?

I don't think deleting and recreating a scene will guarantee a new memory register in the PLM. It will probably just put the new one into the hole just created by the deletion. I suggest leaving the existing scene in the PLM without any controllers to ensure the suspect memory location is not reused. This will force the new scene to be created in a new PLM memory register.

I wonder what would happen if you added 1 togglelinc back to the scene as a responder only (so the scene still exists in the same memory location of the PLM) and then created a new scene configured with the same controllers and responders as the original? If the new scene triggers it must be caused by a device in the scene. If just the one togglelinc triggers it would point to the PLM memory location. While X-10 can trigger individual modules I don'y see how it could be responsible for triggering a scene.

Just curious ... is there a ControLinc button included in the scene?

I just replaced 8 Switchlinc relays due to paddle problems and I see the new ones are all v35. What exactly is the issue with this rev and how can I test to see if mine have the problem? Am I going to have to swap these all out again?

I am running 2.7.8 and since upgrading have swapped a large number of devices due to paddle problems and also manually renamed and assigned folders to all 440 of my devices, scenes and programs. Am I going to lose all of this work?

Does the chatter eventually settle down? Sometimes repeated power glitches can cause the ISY to restart which would kick off the polling to check the status of your devices. With 80 of them it will take awhile, especially if it keeps restarting due to flaky power. Another thing to look for is a bad Access Point.

I'm not sure why you would expect that they would. If you don't use the ISY to set up your links then it has no way of knowing about them to display in the topology. The correct way to set up a 3-way switch, for example, is to create a scene and then add each switch to the scene as a controller. This creates the same links you were doing manually PLUS it updates the ISY database so that the topology and switch status displays correctly.

This reminds me of the lengthy Scene vs Group discussions of long ago.

I would think a good reason to link to an Access Point would be so it would be polled each night along with the other devices so you could be alerted if there was a communication problem (somebody unplugged it or it failed). This assumes an AP will respond to a status request which I don't know if it does.

What about connecting a 2410 to the Stargate and using ASCII to send and receive Insteon signals directly?

I think the TC/Stargate and the ISY are equally reliable pieces of hardware. It is just that the ISY does not have direct inputs and the TC/Stargate does not support Insteon. To use the ISY for monitoring inputs you can use your Existing TC to trigger X-10 messages to the ISY or use an I/O linc to send Insteon messages to the ISY or you can use an Elk alarm panel to send network messages to the ISY. Regardless of what you do the state of your input will be held in a table in the ISY and will only be as accurate if every single trigger message gets through. With the TC, if a state change is missed there will be several opportunities per second for it to be noticed and corrected through polling. It is a different hardware implementation for a different mission. In reality, you will probably never again see truly "all-in-one" automation hardware the likes of TC, Stargate, or Homevision. HAI has stretched their security platform to cover most of what a dedicated HA box can do but their programming command set is very limited which in turn limits their ability to do some things that can be done easily with a TC. The same could be said for the Elk M1. Your best bet is to focus on separate subsystems that can work together but also stand alone if needed. A typical example is: ISY - Lighting admin, dusk/dawn and timer control, low criticality inputs through RF motion sensors and I/O lincs. Elk M1 or TC or Homevision - critical hard wired sensors and inputs, keypads, thermostats, telephone interface, relay outputs Homeseer or other PC based system - touch screens, text to speech alerts and messages (weather forecasts etc.), security camera interface, etc. Sonos or Slimserver - Whole house audio These systems all coordinate with each other across your home network but will continue operate independently if the other systems are off line. I guess this is a long way to make the point that you can't expect to replace a TC with another single product. It will likely take a combination of things since there is no product that combines high reliability wired inputs with Insteon management and control.