What IS I2?

[Sub-Routine]

I probably should aim this at Smarthome, but the experts here don't fly evasive maneuvers

 

I know that I2 allows for extended commands and that this method allows more parameters to be embedded in a command. I believe that this will make creating groups (scenes) quicker by a factor of about 8, right?

 

Are there any other advantages to it? Sending group commands and cleanups all use I1, short messages. Changing rates and levels in groups also use the short messages, right?

 

So once all my original scenes are created the only advantages would be in adding or deleting devices from scenes?

 

If so, why bother?

 

Rand

[Michel Kohanim]

Hi Rand,

 

Thanks so very much for the question and one which really does deserve an answer:

 

- Yes, i2 allows for extended messages

- In addition to extended messages, there are additional implicit things that also come with i2:

-- PEEK and POKE are deprecated

-- Setting scene attributes (on level/ramp rate) may require commands rather than PEEK POKE

-- Setting other settings such as backlight, mutex buttons, button groups require commands rather than PEEK POKE

 

Therefore, the crux of the problem is PEEK/POKE: had PEEK/POKE remained, then there would be NO problems whatsoever. I understand the reasoning behind deprecating PEEK/POKE: it removes SH from having to maintain or provide internal memory maps to developers since commands act as an abstraction thereof.

 

Now, the problem gets even more complicated since we actually gut out all our code to support i2 and what we found was horrifying:

Although there's a command to extract the engine version (i1 vs. i2), this flag is completely meaningless since there are devices that:

1) Are i2, support PEEK/POKE but do not support commands (RemoteLinc)

2) Are i2, support PEEK/POKE, support SOMEcommands (TimerLinc/KPL Relay)

3) Are i2, do not support PEEK/POKE, support SOME commands (Motion Sensor).

 

Emphasis on "SOME" because this "some" is actually quite arbitrary. In short, there's no algorithm to figure out what are device capabilities except through brute force having a table with each one.

 

Now, things get worse ... all the above may depend on the firmware version: the latest SWL 600 watts fits in category (1) above. So, we need a three dimensional array of device type, firmware version, capabilities. And, when new devices come, we have to test them, put them in the table, and figure out how to support them.

 

In summary, I really doubt if we can ever be able to support mixed i1/i2 installations 100% accurately.

 

As you might guess, our beloved SH rep (Steve Lee) already knows about this and I am 100% confident that he's doing as much as he can to resolve these issues. This said, however, I suspect there shall be no resolutions except slowly making i1 devices incompatible and ...

 

With kind regards,

Michel

 

 

I probably should aim this at Smarthome, but the experts here don't fly evasive maneuvers

 

I know that I2 allows for extended commands and that this method allows more parameters to be embedded in a command. I believe that this will make creating groups (scenes) quicker by a factor of about 8, right?

 

Are there any other advantages to it? Sending group commands and cleanups all use I1, short messages. Changing rates and levels in groups also use the short messages, right?

 

So once all my original scenes are created the only advantages would be in adding or deleting devices from scenes?

 

If so, why bother?

 

Rand

[upstatemike]

This is of course a concern for those of us with way too much I1 stuff to replace it all. I only see two possiblities:

 

1- Have a way to manually identify what table to use for a given device since you can't depend on the firmware version that it reports to tell you which commands to use. Of course you still have to figure out what manual setting to pick.

 

2- Come up with a way to overwrite the firmware on out of warranty devices with something that will work reliably. SH will not be pleased with this approach but in the absence of an official solution...

[Stowaway]

Michel

All I ask is that when a path & time line becomes more clear for "end game" you have described, I hope that we can be appraised so that I can plan for my next home move. Like Rand I don't want to have to replace my Insteon investment, I will just want to start over!!!

 

As you might guess, our beloved SH rep (Steve Lee) already knows about this and I am 100% confident that he's doing as much as he can to resolve these issues. This said, however, I suspect there shall be no resolutions except slowly making i1 devices incompatible and ...

 

With kind regards,

Michel

[Sub-Routine]

I am sure I am not the only one to appreciate your detailed response. Thank you very much Michel.

 

 

Therefore, the crux of the problem is PEEK/POKE: had PEEK/POKE remained, then there would be NO problems whatsoever. I understand the reasoning behind deprecating PEEK/POKE: it removes SH from having to maintain or provide internal memory maps to developers since commands act as an abstraction thereof.

 

 

 

Now, things get worse ... all the above may depend on the firmware version: the latest SWL 600 watts fits in category (1) above. So, we need a three dimensional array of device type, firmware version, capabilities. And, when new devices come, we have to test them, put them in the table, and figure out how to support them.

 

It can't get any easier than that, eh??

 

 

In summary, I really doubt if we can ever be able to support mixed i1/i2 installations 100% accurately.

 

As you might guess, our beloved SH rep (Steve Lee) already knows about this and I am 100% confident that he's doing as much as he can to resolve these issues. This said, however, I suspect there shall be no resolutions except slowly making i1 devices incompatible and ...

 

With kind regards,

Michel

 

Are you saying that if they kept the PEEK/POKE commands programming would be easier? All you need are memory maps? Sounds like the SDM built-in

 

At least Smarthome is employing programmers

Hopefully they will get things ironed out.

 

Rand

[Michel Kohanim]

upstatemike,

 

Option 1 (having a table) that the users use to pick devices sounds good. The main is not building the table; the main problem is NOT knowing what each table should have.

 

Option 2, wow, I don't want to even think about it

 

Stowaway

 

I shall surely keep everyone appraised of our progress.

 

Rand

 

Yes! All we need is to keep PEEK/POKE around. That solves most of the problems. Then again, I was playing with extended messages again and I must say that they are NOT reliable at all. In more than one occasion, the TimerLinc did not receive the whole packet and wrote the data in the wrong memory locations. My RemoteLinc simply crashed so badly that I had to factory reset it to revive it. Currently, using i2 commands, and using only i2 products, I have a system which is not manageable nor is it in synch with what the devices think.

 

I am sure we'll find a way!

 

Thanks so very much,

With kind regards,

Michel

[upstatemike]

So do we know what the last reliable (all I1) switch version was? Maybe I can find enough on the used market to finish my house.

[Michel Kohanim]

Hi upstatemike,

 

Unfortunately, I do not have that information.

 

With kind regards,

Michel

 

So do we know what the last reliable (all I1) switch version was? Maybe I can find enough on the used market to finish my house.

[Brian H]

Sounds like Smarthome has created a Monster!

[jhimmel]

upstatemike,Yes! All we need is to keep PEEK/POKE around. That solves most of the problems. Then again, I was playing with extended messages again and I must say that they are NOT reliable at all. In more than one occasion, the TimerLinc did not receive the whole packet and wrote the data in the wrong memory locations. My RemoteLinc simply crashed so badly that I had to factory reset it to revive it. Currently, using i2 commands, and using only i2 products, I have a system which is not manageable nor is it in synch with what the devices think.

With kind regards,

Michel

 

Do I correctly understand what you are saying?

They are phasing out the -working- PEEK/POKE methods, and replacing it with inadequately tested, unreliable, just plain not-working I2 methods?

 

Jim H.

[upstatemike]

Hi upstatemike,

 

Unfortunately, I do not have that information.

 

With kind regards,

Michel

 

So do we know what the last reliable (all I1) switch version was? Maybe I can find enough on the used market to finish my house.

 

OK, I'll do some testing. I think switches labeled V2.2 are reliable but I'll try to confirm it.

[MikeB]

I'll bite..

 

I have SwitchLinc Dimmers installed, labeled up to version v3.2 (ISY shows v.27), with no apparent issues.

 

I also have SwitchLinc Relays installed, labeled up to version v2.5 (ISY shows v.2C), with no apparent issues.

 

I do have a SwitchLinc Dimmer still in the box labeled v4.0 that I could hook up and run some basic tests when I have some time. Sorry I haven't been following all the threads - what kind of symptoms should I be looking for?

[upstatemike]

ISY not able to track local operation of the switch.

[MikeB]

OK. I hooked up the following switch for some quick tests. No load attached:

 

v2476D

labeled v4.0

date code 0828

 

I added it to the ISY via the address, and the ISY detected it correctly as a SwitchLinc Dimmer. ISY shows the firmware level as v.35.

 

ISY is seeing status changes when the switch is controlled locally. I was able to adjust the ramp rate of the switch via the ISY, but the switch did require a reboot to activate the new ramp rate.

 

I was able to create a scene containing both the above mentioned SwitchLinc Dimmer and an ApplianceLinc, and the scene seems to operate fine.

 

This is the newest SwitchLinc Dimmer I have. I will leave it on my test bench for a few days - please let me know if there's anything else I should test.

[upstatemike]

Scenes and programming would not be an issue, just local control tracking. I tried a 4.0 and got nothing. I tried two 2.5s and one worked and one did not. 2.2s always seem to work. (I am using relays not dimmers)

 

What is the version of your PLM? Mine is v63.

[MikeB]

Scenes and programming would not be an issue,

 

I just wanted to test fully.

 

 

just local control tracking.

 

Local control status updates to the ISY are definitely fine here with this switch.

 

 

What is the version of your PLM? Mine is v63.

 

My PLM is showing firmware v63 through the ISY. It is labeled Rev 2.75.

[upstatemike]

I'm glad you don't have any problems. I don't understand why it works fine for you while I have switches that don't register in ISY when operated locally.

[aLf]

OK Michel... Can you go out on a limb here? Are we. Or in this case me, going to have to replace all switches to eventually live happily ever after? In my case I am currently (life #2) with SH. I started with 2300 series X10 from SH and spent 1000's on new Insteon stuff. Yes my current I1 works good, but if I understand properly, my investment is now gone, and if a simple SWL or KPL fails, I have only one option... Buying I2 and the rest of my network won't like it?

 

If this is the case, to date my investment at UD is the only good money I've spent on Insteon.

 

Please tell me it t'aint so!

 

aLf

[Michel Kohanim]

Hello aLf,

 

We'll do all we can to support both: in computer science/programming, there's nothing you cannot do; it's just how ugly the solution will look (it's going to be a little ugly inside our code).

 

With kind regards,

Michel

 

OK Michel... Can you go out on a limb here? Are we. Or in this case me, going to have to replace all switches to eventually live happily ever after? In my case I am currently (life #2) with SH. I started with 2300 series X10 from SH and spent 1000's on new Insteon stuff. Yes my current I1 works good, but if I understand properly, my investment is now gone, and if a simple SWL or KPL fails, I have only one option... Buying I2 and the rest of my network won't like it?

 

If this is the case, to date my investment at UD is the only good money I've spent on Insteon.

 

Please tell me it t'aint so!

 

aLf

[MikeB]

I'm glad you don't have any problems. I don't understand why it works fine for you while I have switches that don't register in ISY when operated locally.

 

Well I don't have a Relay newer than hardware v2.5 - though I haven't hooked it up to check the firmware level. I'll give that one a shot later today if I can.

 

Is it possible you simply have a couple bad devices?

[MikeB]

OK, I hooked up the newest SwitchLinc Relay that I have (which isn't too new). It is:

 

2476S

labeled v2.5

date code 0739

 

ISY shows it as firmware v.2C. The ISY is seeing local status changes with no issue.

 

What is the date code on your problem switches, Mike?

[upstatemike]

OK, I hooked up the newest SwitchLinc Relay that I have (which isn't too new). It is:

 

2476S

labeled v2.5

date code 0739

 

ISY shows it as firmware v.2C. The ISY is seeing local status changes with no issue.

 

What is the date code on your problem switches, Mike?

 

v2.5

date code 0738

[MikeB]

Wow, that's very close to mine... maybe just a couple of bad switches?

 

I have no use for this switch at the moment - drop me an email if you'd like to borrow it as a test.

 

What hardware rev is your PLM?

[Michel Kohanim]

upstatemike,

 

Come to think of it, you have a very large installation. The last time we checked, you had about 900 links in your PLM.

 

One way to test is:

1. Go to Tools->Diagnostics->Show Device Link Table

2. Choose your SWL

3. Click on Start and then click Ok on the subsequent dialog

4. Look for E2 01 N.N.N 00 00 1 where N.N.N is your PLM id (Tools->Diagnostics->PLM Info/Status)

 

If you do NOT find this record, the we either have a bug in ISY or ISY was not able to write this record into your PLM.

 

If you do have this record, then the problem is either the PLM or the switch itself (we have ruled out noise, right).

 

To see if it's not the PLM, please

1. Go to Tools->Show PLMs Link Table, click on Start

2. Look for A2 01 M.M.M WW KK 1 where M.M.M is your SWL's address and WW and KK are immaterial

3. Click on the Count button to see how many records you have

 

If you do not find this record, then in all likelihood you have a defective PLM or one which overwrites others.

 

 

With kind regards,

Michel

[IndyMike]

Michel and Upstate,

 

I've been "lurking" for some time now as this thread developed. If I am correct, a missing link in the device/plm would cause the switch to malfunction 100% - correct.

 

From the previous thread, Upstate had reported that the problem switch plugged directly into the PLM would "sometimes" register: http://www.forum.universal-devices.com/viewtopic.php?p=12926#12926

 

This has still has me scratching my head. I also have a V2.5 SWL relay (date code 0750) which does not exhibit the problem. I am in no way inferring that the problem is not with the switch, just questioning whether this is I2 related. If SH is mixing I1 and I2 firmware within switch revs and date codes - well I'm not sure what I'd do...

 

Is it possible that the EEprom entries in the Switch itself were "badly programmed"? If the switch can't properly read it's own link table it would not transmit correctly for a local ON. A weak memory location shouldn't happen, but it's possible that the programming voltages for this unit are marginal or affected by local disturbances.

 

Upstate - have you tried clearing and programming the SWL with it plugged directly into the PLM?

 

IM