Keypad 2334-222 Programming Issues

[codyo]

I have recently replaced a defective 2486D keypad with a 234-222 keypad. However, after installing the new keypad, it appears as a simple switch device noted as "Unsupported Device 1.66". Is there some reason that this device should not be configured in ISY-99 the same as the 2486D keypad?

[Brian H]

They are not the same.

The 2334-222 is a Dual Band module and the 2486D is an older power line only module.

They have different Sub Cat Numbers and the latest firmware for the ISY99i may not support it completely and it was added as a generic device.

 

I just looked at the Firmware Release Notes and the 2334-222 was added in 4.0.1 and only for the ISY994i as the ISY99i firmware was frozen at 3.3.10.

viewtopic.php?f=44&t=10771

[LeeG]

As Brian has already covered the new Dual Band device is supported by ISY firmware later then 3.3.10. It is best to move to a 994i as this is not the only case of a new device being released by Smarthome after 3.3.10 was released.

 

Try using New INSTEON Device and select the specific Device Type for 2486D. Not sure but that may override the normal ISY use of the cat/subcat (device type) retrieved from the device.

[codyo]

Thanks for the info!

[andrew67]

This DOES NOT work. Apparently you can set the device type to whatever you like, but the recovered data from the device always overrides it. SO forced obsolescence is alive and well. Some dual band devices seem to be covered, but apparently the keypad dimmer isn't. That's really sad, and I expect a LOT of people will run into this, especially since smarthome lists it as ISY compatible.

 

 

I don't see this as an acceptable situation. Thoughts?

[LeeG]

The KeypadLinc Dual Band device was released after 3.3.10 was released. Only one of several devices that have come out since 3.3.10 was released. The problem is the 99i memory it not large enough to accept the support for all the devices that have come out since and will continue to come out later.

 

There was an update path announced back in Feb to get from a 99i to a 994i. This has long since expired being some 7 months ago. The OP should contact UDI directly.

 

andrew67

 

All things have a life span. The Dual Band KeypadLinc is not compatible with an ISY-26, nor an ISY-99i. It is compatible with an ISY 994i. There is no doubt in my mind that somewhere in the future the 994i will be replaced with something bigger and better. That is the nature of technology.

[MWareman]

especially since smarthome lists it as ISY compatible.

 

 

I don't see this as an acceptable situation. Thoughts?

 

My thought is you should ping Starthome about that. ISY994 compatible maybe, but saying ISY is misleading in my opinion - for those that have the 99.

 

Either way, its not UDI's issue - they have been very open about this. My $0.02. As LeeG said, all devices have an end of life. Either RMA it to Smarthome on their mis-description, or buy a 994i for support of the latest devices.

[andrew67]

I understand. Its just that this is one of those things which causes home automation to have the shitty reputation it has to begin with.

 

So now I have two options:

1) spend 2 hours ripping the device back out of the wall, returning it to smarthome, getting a different one, and then finally reprogramming my ISY99

2) spend $400 getting a new ISY, and then spend another (hopefully) 2 hours upgrading, and (hope) nothing else breaks in the process.

 

Not exactly what I had in mind when I needed to replace a failed dimmer.

 

With 140 devices scattered over 2 properties, I now have 8 error devices in the last 6 months. No usable diagnostics. Good thing I'm handling this myself. If I called an electrician, that would end up being $3K, and I'd have to give him a key to my place given how many times he would have been there..... Oh, and one is behind the fridge, and one in a fixture.

fun eh?

 

[food for thought, not asking for a response, and not interested in a flame war]

I'm a tech guy, and I understand what the conditions under which all this stuff is supposed to work are, and I probably understand more technically about why things are the way they are than almost everyone else here. Thankfully I really couldn't care less about the money involved either.

 

But If any of this is going to have an actual impact on peoples lives beyond the people who will pick up the screwdriver themselves, then this kind of thing can't be considered normal.

 

It is not acceptable to ask people to constantly check for new versions of parts of their house and try to figure out compatibility lists when doing so.

 

Its also not acceptable to have to constantly replace switches and deal with the dreaded comm errors, with no available diagnostic or network verification capabilities.

 

Maybe none of this is UD's "problem". Smarthome isn't blameless obviously, and I'm sure things are getting better. But that's really not the point.

 

[iF THE SWITCHES CAN BUILD LINKS BETWEEN THEMSELVES, THEN THERE IS NO REASON WHY ISY CAN'T LET YOU OVERRIDE THE DEVICE SETTINGS AND MAKE IT CONTINUE TO WORK TOO]

 

And if we are upgrading, then how about we upgrade to something which can actually help make everything a lot better.

[oberkc]

andrew67

 

Unfortunately, when we left the world of dumb switches, I believe we accepted these types of problems as the cost of admission. And it gets worse. What happens if smartlabs goes out of business and takes with it insteon?

 

Until we can convince the rest of the world that insteon is the correct way to go, and until insteon becomes open source, and until we can convince people that new features and capabilities are not needed...this is the world in which we live.

 

It is still worth it to me, but I mitigate this risk by wiring in such a way as to allow reverting back to dumb switches.

 

The biggest benefit of the -994, to me, is the growth potential into protocols other than insteon. I just hope that this potential is realized.

[LeeG]

andrew67

 

I agree with much of what you wrote. However, it is not possible to do as you suggest. Commands which were available for device link management since day one of Insteon have been physically removed from the new devices. SmartLabs told everyone these commands were depreciated back in 2007. However, it was not until the new I2CS protocol surfaced beginning in March 2012 were these depreciated commands actually removed from the new devices. Defining a device as an old KeypadLinc where the ISY used commands that have been around literally forever no longer work with the new devices. It is absolutely necessary for the ISY to dynamically obtain the information from the device itself to know what the device is and what commands must be used.

 

If the ISY accepted a device override all the link management commands would fail as they literally no longer exist in the new devices.

 

For years one could buy an 8 button KeypadLinc where link management commands that worked in 2006 continued to work even into 2012. Certainly new features such as Beep and better Backlight control were introduced but the underlying device link management remained intact. It took months for SmartLabs to roll out devices with firmware containing I2CS protocol and SmartLabs did not publish a schedule when each device type would be converted to I2CS.

 

In a perfect world one could install Insteon and walk away. Unfortunately that is not possible with Insteon. With the changes to the basic protocol and its additional requirements combined with the removal of commands that have been with use literally from day one of Insteon it cannot be installed and forgotten.

 

It is a guarantee that a user will be burned if he/she does not stay actively aware of what SmartLabs/Smarthome is doing and what the ISY is forced to adapt to.

[Brian H]

Manual linking had to be kept or many users with no controllers would be out of luck and Insteon would quickly fade into oblivion.

 

I2CS messed up may hardware and software vendors. Along with end users.

Old I1 commands ignored and new restrictions on if a module will respond. Depending on what is in each Link Database.

Check Sum incorrect all you get is a NAK response.