New Insteon Access Point
- Thread starter Smarty
- Start date
Odd that I don't see it here. I wonder if it was fixed with a newer revision? I also searched SmartHome's forums, and couldn't find any mention of it there.
"Compatibility
SwitchLinc V2 Dimmer is fully INSTEON compatible and X10 ready"
Statements such as this from SH advertising sometimes dissappear over time when things change. Problem is when you buy the stuff you beleive it.
Soooooooo do V2 dimmers have extended messaging etc.? Will they work with all future products that use the Insteon protocal?
SwitchLinc V2 Dimmer is fully INSTEON compatible and X10 ready"
Statements such as this from SH advertising sometimes dissappear over time when things change. Problem is when you buy the stuff you beleive it.
Soooooooo do V2 dimmers have extended messaging etc.? Will they work with all future products that use the Insteon protocal?
Yeah, I asked that question, but you notice nobody responded....
rocco
Active Member
What's a poor giant corporation to do? This is my take on the gestation period of Insteon:
Year 2000:
SmartHome was very happy making X10 devices. They had become one of the largest and most respected X10 sources. They had great products at decent prices, with a lot of volume.
Year 2004:
UPB and ZWave are not only on the market, but are rapidly gaining acceptance, and eroding the X10 market. ACT had already jumped from X10 onto the ZWave bandwagon. Also Zigbee is on the horizon (very far on the horizon, in hindsight). SmartHome's marketing is caught snoozing.
Realizing that they needed to quickly move from X10, not wishing to pay license fees for the other technologies or being a minor player, and feeling like the 600-pound gorilla, they decide that they should do their own protocol, and leverage their X10 muscle to make sure it was accepted.
But ZWave and UPB were building momentum, and SmartHome had to move into the market fast! They started development years behind, the last horse out of the gate (both UPB and ZWave started development in the 1990s). They needed to make up for the lost time, and decided that it was more important to get products out of the door than it was to have those products solid.
They copied the X10 paradigm, with both PLC and RF components. They threw together a protocol, with the mantra that simple was better (because it was quicker for them to develop). But overly simple can become overly complicated. Some blunders were made in the original specification. Some of the technical assumptions were not correct. But the protocol's survival depended on getting products into the field.
Year 2007:
They are shipping products based on an incomplete protocol, but they are shipping products. They gained a lot of momentum by selling the ICON products at a loss. They lost a lot of money by needing to swap-out defective products. Those problems cost a lot of customer-goodwill. They will likely loose more money and more goodwill in the future. But Insteon product volume is high.
So I might speculate that they accomplished the goals: They are no longer dependent on the faltering X10 market. They came from way behind to offer an alternative to UPB and ZWave. It may be a poor alternative right now, and only time will tell if the strategy will work for the long run. I'm betting it won't.
I also tried this on 2 KeypadLincs in my garage that I KNOW I've never dimmed before, and hitting C and F again seems to return it to the original level. Have other people reported this issue?
I wonder if dhoward knows, since he knew about extended messaging with the SignalLinc and AccessPoint?
What would make you think that it might not work with future Insteon products, just because they might not support extended messaging? I may not be fully understanding it, but my impression is that extended messaging adds additional functions, like speedier linking. I can't see why your existing SwitchLincs would stop functioning and/or linking to new Insteon products.
In my opinion, it's more important to have the SignalLinc/AccessPoint support extended messaging, because if that unit lacks it, so will all your RF devices (whether the RF device itself supports it or not).
rocco
Active Member
I think the assumption is that the current method of linking, peek and poke device memory, will not be supported by newer software once the simpler and more reliable extended-message method is available on all devices.
keepersg
Active Member
My 2 cents. In the interests of accuracy, according the the documents on Insteon.net, development of Insteon began in 2001. The protocol doesn't look "thrown together" to me but since its specifications are documented, people can decide for themselves: http://www.insteon.net/pdf/insteondetails.pdf.
Its unclear to me what is meant by "copied the X10 paradigm". The protocols are very different. They do share the mediums (powerline and EMR) for communication but thats about it.
I speculate that a factor completely ignored in the hypothetical history above may have affected Insteon development substantially: Lutron patents. This has been explored on these pages previously.
"You can also purchase SignaLinc RFs in a set of two. Installing them throughout the house eliminates RF "dead spots" and facilitates your INSTEON network to support large or complex installations."
Still on their website as of today for teh Signalinc marketing literature. So they WERE meant to provide RF Signal reception the way I read it....
Interesting note about CS...... I called yessterday after getting my catalog in the mail around lunch time. I was about to order a few things and noted the prices were cheaoer in the catalog then on the website. Also both the catalog and the website are offereing 10% off (different codes). They would not honor the catalog prices saying they are outdated. I had the catalog maybe 2 hours or so............... geez talk about hurry up and order before the prices go up.
It was an insginificant amount of money so I gave up. Just a stupid response from the company in my opinion.
Still on their website as of today for teh Signalinc marketing literature. So they WERE meant to provide RF Signal reception the way I read it....
Interesting note about CS...... I called yessterday after getting my catalog in the mail around lunch time. I was about to order a few things and noted the prices were cheaoer in the catalog then on the website. Also both the catalog and the website are offereing 10% off (different codes). They would not honor the catalog prices saying they are outdated. I had the catalog maybe 2 hours or so............... geez talk about hurry up and order before the prices go up.
It was an insginificant amount of money so I gave up. Just a stupid response from the company in my opinion.
KenM
Active Member
That may, or may not, become an issue. INSTEON modules repeat INSTEON and not X10, that leads me to believe that the hardware checks for a valid message prior to repeating it. If your current hardware does not recognize extended messages, it stands to reason that it will not repeat extended messages. That could open up a rather large can of worms.
I imagine that a firmware upgrade would repair the problem, unfortunately, that involves removing switches and sending them back to the factory. V3 anyone?
I would dearly like to see some type of official comment from SmartLabs on this. Leaving all of this up to conjecture and guessing cannot be too good for business.
I still have high hopes for INSTEON hardware. The protocol allows for control of just about anything that does not need a high speed interface. Specifically, the extended data packets can be encrypted to control secure devices like entry and security systems. As far as I know Z-Wave has no provisions for encryption. I do have a garage door interface with a couple of Z-Wave buttons on the keychain remote. Technically, it is not a Z-Wave garage interface, it uses standard RF rolling security code type of communications, and adds a couple of Z-Wave control buttons.
Ken
edit corrected spelling
upstatemike
Senior Member
I wonder if there is a V3 in the works? There are a couple of other issues that can probably only be addresses in a next generation product:
1) Need to be able to set a different ramp rate for On and OFF. There are a lot of situations where you would want the lights to ramp up quickly as you enter a room but fade out slowly so you have time to exit safely.
2) Need to be able to have links respond only to On or only to OFF. Example: I want to turn on the switch at the top of the basement stairs and only have that light go on. Then I want to turn on other lights in the basement only as I need them. When I leave the basement I want to turn off the switch at the top of the stairs and have all of the lights go off. I should not have to have a PC running to accomplish this (like I do now).
3) Need to be able to program all parameters, including local dim, local ramp rate and X-10 address, via software without touching the actual device. The claim that allowing remote programming breaks the security features is silly because you don't need high security on light switches. The local setup requirement should be reserved for devices where it is applicable and not be allowed to cripple the ability to remotely manage lighting devices.
rocco
Active Member
But if you read the spec carefully, almost everything about it is lifted from the other protocols. Compare the addressing with Ethernet. Compare the packet structure with UPB. Compare the ACK mechanism with ZWave (and many other protocols), Compare the retry algorithm with UPB. The address security mechanism is not at all secure, and was obviously not seriously considered. I could go on and on.
The one unique thing about Insteon is the simulcast feature. However, the assumptions made about RF simulcast, and the conclusions drawn, are flat-out wrong. The concepts clearly were not tested prior to release of the white-paper.
Insteon and X10 are the only protocols that use both RF and PLC together, with PLC being primary. In both protocols, PLC drives the devices, and the RF signals are relayed onto PLC. Computer interfaces are PLC. RF is used primarily for battery powered devices.
Also note the X10 compatibility mode.
And I agree. It may be why we have not seen much movement in the RF area. But I suspect that the RF problems run deeper, as simulcasting simply won't work.
rocco
Active Member
Oh, I agree. I can't say whether that concern is well founded. But the situation with the SignalLincs fails to quell the concern.
Mike,
I was able to accomplish this with a keypad at the top of the stairs. I programmed the top ON button to turn on ALL the basement lights and the 4 keypad buttons to turn on "zones:. For example, I had one "zone" for the playroom which turned on the stair lights and playroom lights. Another "zone" was set up for watching TV. Then no matter what we did while in the basement, the OFF button would turn everything OFF.
Also, the ALL ON button was nice for my wife who didn't like to go to the basement at night if I wasn't home. This way she could turn on all the basement lights from the top of the stairs.
OTOH, a programmable double-tap could do the same with a switch.