LeeG

Unless you plan not to install any new Insteon device it really does not matter. If the new device does not have reliable comm then look at what is necessary, what needs to be replaced/upgraded, to get reliable comm with the new device. The more very old devices are replaced the less this is potential problem. Also, the new device might have good comm to start with.

The very old devices are not extended message aware. They cannot repeat extended messages because they have no idea what they are. Devices such as the RF SignaLinc (with the black external antenna) do not phase couple extended messages. Smarthome had a program that was aimed at replacing the old RF SignaLincs with Access Points but there are still users who have SignaLincs for phase coupling and they are happy until a new I2CS device has to be installed as a replacement for a failed device. I guess there could be devices which repeat extended messages but did not yet have the device specific firmware updated to support extended configuration. It is the internal PLM firmware that has the extended message awareness and PLMs did evolve ahead of specific device firmware but it would be all but impossible for a user to detect this situation.

matapan Depends on how old 'old' is. I have devices going back to the beginning of Insteon. These very old devices that do not understand extended messages and do not repeat them. Of course they do not block them but an important part of Insteon reliability is that each device is a repeater. Not so for the very old device where extended messages are concerned. How much of an impact depends on where the new I2CS devices are installed in the network. A few months back I replaced a failing KeypadLinc with a new KPL that is I2CS. Happened to be installed at the very end of a circuit with several very old Insteon devices along the circuit that do not repeat extended messages. The I2CS device requires extended messages for link database management. I could not create the link database in the new KPL because the Insteon powerline signal level was too degraded by the time it got to the new KPL. One solution would have been to replace the very old ICON devices but they have been discontinued. Another solution was to replace the ICONs with SwitchLincs but the current White SwitchLincs do not match any other White switch or cover plate I have. As a temporary solution I installed a Dual Band device at the KeypadLinc location to allow RF to get the extended messages to the KPL. This is an extreme case for sure. Not likely many folks will have such an inventory of very old Insteon devices and it depends on where the new device is installed. However, they were/are very reliable devices from that vintage of Insteon devices. The PLM itself has little to do with this. There was a user a few weeks ago with a very old PLM, firmware in the 6x range, which worked with the new devices. I have a PLM with v.72 firmware that works with the new devices. Having said that, the evolution of PLM firmware has been in its basic functioning, not adding new features. I think it best to have a PLM with one of the latest firmware installed.

LeeFleishman My 2441TH reports temp changes. These are two that were just generated as I held the tstat between my hands to raise the ambient temp. It is reporting in Celsius at the moment which is why the values seem low. The 0x2D is decimal 45 x .5 = 22.5 degrees. The 0x2E is decimal 46 x .5 = 23 degrees Wed 02/20/2013 11:37:03 AM : [iNST-SRX ] 02 50 1D.6C.D6 19.70.06 01 6E 2D (2D) Wed 02/20/2013 11:37:03 AM : [std-Direct ] 1D.6C.D6-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 02/20/2013 11:37:39 AM : [iNST-SRX ] 02 50 1D.6C.D6 19.70.06 01 6E 2E (2E) Wed 02/20/2013 11:37:39 AM : [std-Direct ] 1D.6C.D6-->ISY/PLM Group=0, Max Hops=1, Hops Left=0

The SD card size is not the issue. It is used to store the configuration and image data. The ISY has memory that supports its operation. It is this memory that is larger on the 994 in addition to supporting one of two Radios, ZigBee or ZWave.

The ISY User Guide indicates a blinking Err LED indicates a possible problem with the ISY file system and/or SD card. The User Guide suggests powering down the ISY, and reseat the SD card. The SD card may have to be replaced.

kingwr Have you seen this offer viewtopic.php?f=44&t=10771

The other thing to look for the next time it fails is compare the Green LED intensity between the I/O Linc that shows On in the ISY and the one that shows Off. The Green LED is not a binary condition. The Green LED can be On but not fully bright and the I/O Linc Sensor will be Off. We discovered this when working with other I/O Linc kits that supply a voltage to the Sensor rather than a c-form switch to GND. If the magnetic switch is not providing a good connection to GND or there is a marginal wire connection at the I/O Linc connector to magnetic switch the Green LED can be On but not fully On with the Sensor reporting Off. Might try moving the wires at the I/O Linc connections and the magnetic switch to see if the Sensor On is intermittent.

Thanks. It does not sound like a comm problem if the Query says its Off and the Green LED is On as it should be with the door closed and the newer garage kit with the single NC magnetic switch. Unless the ISY is marking the Sensor with the wrong result from the Query (which is not happening at 4.0.1) it sounds like the I/O Linc is sending the wrong status. Not the kind of symptom I attribute to a comm issue unless the Query does not return a value. The Query request is actually two Insteon commands, one to get the Sensor state and one to get the Relay state. Both Sensor and Relay states are queried regardless of which node the Query is issued against.

swnewman Can you run Tools | Diagnostics | Event Viewer at LEVEL 3 when the Green LED is On and a Query marks the Sensor Off. Thanks

No ISY has a ZWave radio unless participating in the Alpha test. It can be added later just as the ZigBee radio can be added later. Only one radio can be installed, either ZWave or ZigBee

See this post for an upgrade option. I think you keep the 99i, it cannot be sold with this upgrade. Ask this question when communicating per the following post instructions. viewtopic.php?f=44&t=10771 There is a recent topic that covers moving to a new ISY. It is pretty simple. Get your current 99i to the latest 3.3.10 Official release. Take an ISY backup. Turn Off the 99i and 994i and PLM. Switch the PLM to the new ISY and restore power to 994i and PLM. Restore the backup from the 99i onto the 994i. There is some configuration stuff that may not be carried forward but all the Programs, Scenes, Devices, etc are restored from the backup of the 99i. I'll see if I can find that topic and post a link to it. This link has more steps than you need. See post from Michel. There may be another topic as well. I'll add that if I find it. viewtopic.php?f=26&t=10235&hilit=upgrade+994i

aaronb One of the nice things about the ISY is it is field upgradable. IR, Pro and the two Radio options can be added later. I think it is better to start with the Pro to avoid running into any of the limits of the non-Pro version. Not much more expensive considering the investment in Insteon. The IR and either Radio option (ZigBee or ZWave) can be added later.

Roman Glad you found the problem. Trigger Reverse is often the cause of problems. Although it is easier than changing out the magnetic switch, Trigger Reverse does not affect the Query result. When the Query is done at 3 AM the Sensor node changes state because Query returns the true state of the I/O Linc Sensor rather than the command reversed state that Trigger Reverse generates.

Roman “I hope that by adding the option from just sensor ON, OFF or respond, that the % amount can be added thereby I belive will fix my issue if I can then state vs if ON beep to if 100% then beep.†Unfortunately this should have no affect on your problem. ON means the same thing as 100%. Whether it shows as ON or shows a 100% the I/O Linc can only be OFF (0%) or ON (100%). Is the I/O Linc using Trigger Reverse option?

Sure. Provide sales@ with the UUID of the 99i noting that you have the optional X10/A10 module. It will then be installable on the 994.

I/O Linc Relay slider now sets Responder On Level to 0% or 100% - 4.0.1 change, works great However, regardless of whether On Level at 100% or 0% the I/O Linc Relay Status is reversed. The Relay action is physically reversed with 0% On Level. Scene Off button turns Relay On and Scene On button turns Relay Off as expected. The Relay Current State Status correctly tracks the physical state of the Relay. This is change at 4.0.1 and is working correctly. The problem now is when the Responder On Level is set to 100%, Scene On turns the Relay On as it should, however the Relay Current State Status is still reversed as though the Responder On Level was set to 0% On Level. Scene On turns Relay On correctly, Relay Status shows Off. Scene Off turns Relay Off correctly, Relay Status shows On.

Start with what you have available. Set off the smoke alarm and let’s see what the Smoke Bridge generates for messages. Very likely the other detection nodes will do the same thing. No sense going to the trouble of testing the others until Smoke is working.

Must set to LEVEL 3 before creating the activity. There will not be that much activity if any when testing for each condition. Edit the event trace with WordPad. Copy/Paste the records to the a forum post.

Insteon Scenes have no ability to run a Program directly. A Program can invoke a Scene but a Scene cannot invoke a Program. A Program can certainly be defined to trigger on the device Conditions the Scene is controlling so a Program can be invoked indirectly, but not directly. Not within Insteon architecture.

It is not possible to turn a Secondary button On/Off directly with a Program. The posted example does not show using a Scene to turn 'Kitchen KPL - Combo1' On/Off. The Secondary button must be added to a Scene as a Responder and turn the Scene On/Off. There is no placeholder in an Insteon Direct command to identify which Secondary button. In fact if 'Kitchen KPL - Combo1' is a Secondary button I don't know how the posted statements were generated.

The thermostat must not be reporting the change since from its perspective they are only display changes. That is only speculation. I did a Query when I changed the thermostats to C because the actual ambient temp the t-tstat was measuring had not changed and I did not want to wait for the temp to move. When I did the Query the values in the Admin Console were in C

Without seeing the Program that manages $State_Combo1 State Variable, the posted Program should work. 'Kitchen KPL - Combo1' must be the load control button on the KeypadLinc. Using Programs | Summary tab will show if/when the Program was last triggered and whether the If was True or False. With that information in hand either the Program is not being triggered or the Variable values are not as expected making the If False.

Is State_Combo1 an Integer Variable or a State Variable?

Here is a link to the Smarthome forum topic on calibration http://www.smarthome.com/forum/topic.asp?TOPIC_ID=12274