Getting Serious - When Comm issues strike

[Brian H]

Strangeness in some communications.

 

Like Extended Messages popping out of the blue. When I was doing a Show Devices Links Table.

Just stopping for a few seconds with no responses from the module being accessed.

Though that maybe a problem with the old v1.3 ApplianceLincs.

 

Messages indicating the new firmware handled communications better.

 

Replaced the two V1.6 Access Points with the latest ones also.

 

Biggest reason. 20% off Black Friday sale.

[ELA]

I would be very curious if your mysterious extended messages disappear with the new PLM.

 

I experienced a lot of corrupted msgs initially and then as I improved the communications environment they changed to being extraneous (often extended).

 

I do believe I bench tested the newer PLM and also got some extraneous msgs (but don't hold me to that).

I am unsure since I ended up putting the build of a 3rd ELAMontor on hold ... so that newest PLM is resting on a shelf for now.

I may end up just keeping it as a spare for my home installation.

[Brian H]

I will try some Device Link Table tests and see what I can find.

The two today had no ERX Extended Message in the logs.

Part of my problem maybe my revision 1.3 ApplianceLincs.

They are getting old and are the ones that have power supplies with the 30 volt zener that gets warm.

I also found the main filter cap gets to about 115 to 118 degrees F case temperature. From I believe ripple current.

Then to add more. I have two stacked in a horizontally positioned AC outlet.

[ELA]

After discovering the ARSSI output available from the transceiver chip I could not resist adding that function to one of my two ELAMs.

Here is a picture of it when receiving from the access point right next to it (Access point in the 4 tap test mode).

 

 

Once I saw that the received signal strength could be monitored via an Oscilloscope I then added a mode to monitor it in the ELAM using an extra analog input on the microcontroller.

 

It appears that this ARSSI pin outputs a constant level for background RF levels of around 400 millivolts. The controller averages many readings and displays that as a background level.

It monitors and then also displays any peak values registered.

 

This peak level shown is from the nearby Access point's RF output. As you move the two units apart the peak level drops.

Should be a handy tool to confirm that a devices RF output is working as well as to gauge relative signal strengths.

 

I brought the antennas outside of the case because the ELAM microcontroller PCA ground plane reduces the RF transmit capability.

I did not care much about that previously but for this new function it became more important.

[ELA]

Some results from testing with this new capability to measure RF signal strengths:

 

I posted in another thread this initial testing using an aluminum box to purposely create a worst case attenuation:

Using a triggerlinc mounted inside of the box and an ELAM to translate the RF to PLC to an IOlinc as the receiver.

 

Tests using a aluminum box of 10" x 5" x 2.5" as faraday cage showed that only about 1/8" opening was all it took for the RF to get between two devices at 4ft apart.

These first tests were 4ft from sender to receiver:

Open air between = 1070 millivolts

box closed on 5 sides = 800-900 when opening was facing toward the receiver.

box closed on 5 sides = 700-800 when opening was facing away the receiver

approx same results with a varied opening of 5" down to 1/2 inch.

 

It was very cool to see the RF theory prove out. From within about 4 ft of the ELAM I was able to completely close the lid ( complete the Faraday cage) and see you no RF on the ELAM background

level of ~400 -500 millivolts and the IOLinc would not activate.

 

 

I have two DB KPLs in my house about 35 ft apart.

When I run the 4 tap comm. test they are not able to "see" each other in one direction. The level at the sender reads 1100mv and at the receiver about 530mv. Going in the opposite direction the comm does work and the receiver measures about 620 mv.

 

 

I then did an "open field test". A rough version of one within the confines of my yard. Using an access point as the sender and the ELAM to measure I started at 1 ft. The results varied greatly depending upon angles and height above the ground but give a rough indication of how good the comm can be in open air.

1ft = 1100mv

30 ft = 930mv

60 ft = 850mv

75' = 830 mv.

 

So I could the units working at 100 -150ft in open air.

 

Interesting to compare the open air to the KPLs in the house.

The level between KPLs at 12ft (in one direction with 3 walls between) was 820mv, that same level reduction in open air would be at about 75ft. 6:1 ratio! Appears my house is not very RF friendly...

[Teken]

Some results from testing with this new capability to measure RF signal strengths:

 

I posted in another thread this initial testing using an aluminum box to purposely create a worst case attenuation:

Using a triggerlinc mounted inside of the box and an ELAM to translate the RF to PLC to an IOlinc as the receiver.

 

Tests using a aluminum box of 10" x 5" x 2.5" as faraday cage showed that only about 1/8" opening was all it took for the RF to get between two devices at 4ft apart.

These first tests were 4ft from sender to receiver:

Open air between = 1070 millivolts

box closed on 5 sides = 800-900 when opening was facing toward the receiver.

box closed on 5 sides = 700-800 when opening was facing away the receiver

approx same results with a varied opening of 5" down to 1/2 inch.

 

It was very cool to see the RF theory prove out. From within about 4 ft of the ELAM I was able to completely close the lid ( complete the Faraday cage) and see you no RF on the ELAM background

level of ~400 -500 millivolts and the IOLinc would not activate.

 

 

I have two DB KPLs in my house about 35 ft apart.

When I run the 4 tap comm. test they are not able to "see" each other in one direction. The level at the sender reads 1100mv and at the receiver about 530mv. Going in the opposite direction the comm does work and the receiver measures about 620 mv.

 

 

I then did an "open field test". A rough version of one within the confines of my yard. Using an access point as the sender and the ELAM to measure I started at 1 ft. The results varied greatly depending upon angles and height above the ground but give a rough indication of how good the comm can be in open air.

1ft = 1100mv

30 ft = 930mv

60 ft = 850mv

75' = 830 mv.

 

So I could the units working at 100 -150ft in open air.

 

Interesting to compare the open air to the KPLs in the house.

The level between KPLs at 12ft (in one direction with 3 walls between) was 820mv, that same level reduction in open air would be at about 75ft. 6:1 ratio! Appears my house is not very RF friendly...

 

ELA,

 

What is your educated guess, as to why the signal would not be received from one dual band KPL to the other. While performing the exact same phase bridging test in the opposite direction does work?

 

I ask, because this has been my experience as well. I went so far as removing them from their final installation place and replacing them in opposite order. The results were still the same, the phase bridging would complete only one way.

 

My observations are that the metal J box plays one role. The other is that there are variability in power output of the devices. The other guess is that the placement of the coiled antenna should be in the next *update* be placed closer to the face of the device where the keys are and two of the antennas be present, rather than one.

 

While performing this test all the circuit breakers were shut off so I could have a controlled test environment.

 

(Note, don't try this at home while the whole family is present. You will either get lots of rolling eyes, or the SO (Significant Other) giving you lots of grief!)

 

The only thing on these circuits were the two dual band KPL's . . . In my humble opinion, Insteon continues to progress and improve their product offerings. But, these dual band devices need to be re-designed to offer higher RF / powerline power output. While reworking the placement of their antenna's.

 

Lastly, the use of the AP modules in my opinion is a must, and not just a nice to have in any installation.

 

Teken . . .

[ELA]

Hi Teken,

I am not sure of the scope of your question.

Assuming we are talking about an "RF only" communication like the 4 tap test then the reason is that the RF level is very low going either way ( in my KPLs test).

 

The RF paths are slightly different going one way than the other, reflections change based on the RF paths direction etc. Since the signals are already marginal one makes it and one does not. Also as you said the transmitters may not be exactly the same strength. RF has so many variables involved.

 

This is why it is very cool to have signal strength tools. If I move the ELAM about 10ft to the left of the KPL that is not receiving ( level at 530mv), the overall distance is still 35ft (from originator) but at a different angle and the level rises to 600-700mv and the ELAM LED blinks (receiving the 4 tap signal).

 

I agree that they are stretching it with this dual band stuff. I have used the FCC site to compare as many Dual band RF power output tests as they present there and the Access point wins!

 

Yesterday I checked the new DB FanLink. It is the worst I have compared, just as I would have predicted. Too much stuff in too small of a space.

 

Have a great Christmas!

[Brian H]

I have found in weak spots. Where I stand can sometime change things.

[ELA]

deleted: Since response was to a garbage poster.

[LeeG]

ELA

 

That post is an advertisement! The forum was flooded with posts from that user essentially providing a link to his product.

 

Lee

[ELA]

A followup to a new feature I added to the ELAM tester. As shown a few posts back this unit can measure RF signal levels.

I have now added another screen that can be displayed when connected to a terminal program. It is a "Virtual Oscope" graph of RF signal strength vertically vs. time horizontally. Overall time scale is limited to about 650 msec. This is just enough to capture a good group msg exchange.

 

I created this feature so that I could evaluate the relative RF signal strengths of the sender vs. the responder.

 

In particular I had purchased a Fanlinc and before installation I wanted to test it to see if the fan housing would be limiting its RF capability. ( There had been some questions about the fan canopy acting as a faraday cage and blocking the RF, especially if a metal box were used.)

 

The graphs below should very good communications on a bench top test ( first two) . The third shows what a marginal communications looks like. In the third the ack was received but it was just barely above the background "noise level".

 

I then measured the response of the Fanlinc after I installed it in my fan. I got a very good RF response level and the graph looked very similar to the second (middle graph).

 

 

I suspect that I got a good response because my Fan had an RF remote previous to the Fanlinc. I am thinking they might design for that since there is about a 1/2" gap at the top of the fan canopy where it meets the ceiling box (and I have a metal ceiling box).

 

When I first installed the fan that gap bothered me a little bit but now I wonder if it is actually by design. I was expecting to see more RF signal degradation but I am happy that the gap seems to be all that is required.

[ELA]

I have added a new feature to read the PIR sensors (2420M) Battery Voltage with my tester(ELAM).

 

Many thanks to LeeG for providing the command required, data fields, and the knowledge that you can poll the device for data after detecting an ON broadcast message.

 

I was able to get this to work very nicely for my home installed MS's.

It can be a bit of tricky timing and is likely to have issues if the MS has a lot of links installed.

 

( In my home network I rely on the ISY and programs to do most of the work and thus the MS's only need a link to the ISY. This makes the timing issues for this feature more predictable and easier to deal with.)

 

With this setup I can tell the ELAM what address (which device) I want to poll. It then waits in a monitor mode until it detects an ON broadcast msg from the desired MS. Once the msg is detected (after causing motion in front of that sensor) it then requests the devices configuration data. The batteries current voltage level is included in that data.

 

Worked great on all 6 of my MS's:

 

That value is decoded and displayed to the screen as shown below.

There is an implied decimal so this units battery was 8.9V ( with a 0.1 Volts resolution).

It detected 5 msgs and the last one's hop info is shown as well.

[Teken]

ELA,

 

If this hasn't been said before. I really do hope once you get this diagnostic tool all sorted out and in a solid form factor. That you consider producing a few for those interested in its powerful feed back and diagnostic abilities.

 

I am very interested in having one for my own install . . .

 

Teken . . .

[ELA]

Hello and thank you Teken,

 

I appreciate your expressed interest.

 

I am still on the fence about making this an available tool to others. I would absolutely love to if it were not so much of a hassle. I feel that getting the required full approvals are out of the question.

That leaves me with making it available as a kit ( or assembled and tested with a disclaimer). This option was suggested by someone a while back and I may still look into that.

I would then need to start a business, get a web site, pay pal etc. I am a designer and not a business man.

 

Not totally out of the question but a ways off if I do.

 

I really do not think there are many who would be interested in attempting to solder the fine pitch ICs used on this PCA. Most are surface mount and one is 0.025" pitch.

There are also a number of jumper modifications that need to be made to the base PLM to interface properly with the ELAM -PCA in order to support full functionality.

 

I have gone through three iterations of the PCB design, countless revisions of the firmware w/adding new features, built two prototypes, wrote a manual and partial assembly instructions. It is close to being able to put it out there. Just have to get motivated to start a business and web site.

 

This device has over 24K of programming and I feel it has a lot of diagnostic capabilities that are desirable. At its most basic (original design intent) it would be nice to have - even if you never used all of its functionality. Of course then there is the cost issue. Unless you are a techie and want full functionality it might be difficult to justify the cost. Unknown what that would be at this point.

[Teken]

Hello and thank you Teken,

 

I appreciate your expressed interest.

 

I am still on the fence about making this an available tool to others. I would absolutely love to if it were not so much of a hassle. I feel that getting the required full approvals are out of the question.

That leaves me with making it available as a kit ( or assembled and tested with a disclaimer). This option was suggested by someone a while back and I may still look into that.

I would then need to start a business, get a web site, pay pal etc. I am a designer and not a business man.

 

Not totally out of the question but a ways off if I do.

 

I really do not think there are many who would be interested in attempting to solder the fine pitch ICs used on this PCA. Most are surface mount and one is 0.025" pitch.

There are also a number of jumper modifications that need to be made to the base PLM to interface properly with the ELAM -PCA in order to support full functionality.

 

I have gone through three iterations of the PCB design, countless revisions of the firmware w/adding new features, built two prototypes, wrote a manual and partial assembly instructions. It is close to being able to put it out there. Just have to get motivated to start a business and web site.

 

This device has over 24K of programming and I feel it has a lot of diagnostic capabilities that are desirable. At its most basic (original design intent) it would be nice to have - even if you never used all of its functionality. Of course then there is the cost issue. Unless you are a techie and want full functionality it might be difficult to justify the cost. Unknown what that would be at this point.

 

 

I can appreciate the long hours and hard work you have invested thus far. In the interim, I shall sit on the side lines and live through you, as you continue to publish and share your findings with your ELAM.

 

Teken . . .

[ELA]

Thank you Teken,

 

This discussion reminded me of another reason I have been a little hesitant to put the ELAM out there for others.

I have put a lot of work into it and I would not be crazy about having to maintain code upgrades. If there were bugs that would be one thing but if a person had to chase changes made by Smartlabs that could be a very daunting task. Especially without being "in the know" about when and why things were changing.

 

In particular what about this new I2CS? From what little I have read about it here it means i2 communications with a new or enhanced CheckSum?

Is there more information available, or more accurate info, if my initial assessment is incorrect? From what I read it should be compatible with existing installs. I sure would like to know more. When would the benefits of the new protocol come into effect?

Would we need to upgrade all of our devices to take full advantage of this improvement

 

More directly would I need to better understand this protocol to maintain code in the ELAM. The ELAM consists of a daughter board add-on to a 2413 base unit. A new 2413 would be part of each new ELAM. When the 2413 changes, either hardware or firmware, what issues might present themselves for the ELAM? Or other products based on the daughter-brd interface to the 2413.

 

A while back in my testing I added a feature to the ELAM to detect corrupted messages. It was my suspicion that the checksum was not sufficient and failing to detect corrupted messages.

Now i2CS is being presented. .... Makes me very curious ?

[Teken]

Thank you Teken,

 

This discussion reminded me of another reason I have been a little hesitant to put the ELAM out there for others.

I have put a lot of work into it and I would not be crazy about having to maintain code upgrades. If there were bugs that would be one thing but if a person had to chase changes made by Smartlabs that could be a very daunting task. Especially without being "in the know" about when and why things were changing.

 

In particular what about this new I2CS? From what little I have read about it here it means i2 communications with a new or enhanced CheckSum?

Is there more information available, or more accurate info, if my initial assessment is incorrect? From what I read it should be compatible with existing installs. I sure would like to know more. When would the benefits of the new protocol come into effect?

Would we need to upgrade all of our devices to take full advantage of this improvement

 

More directly would I need to better understand this protocol to maintain code in the ELAM. The ELAM consists of a daughter board add-on to a 2413 base unit. A new 2413 would be part of each new ELAM. When the 2413 changes, either hardware or firmware, what issues might present themselves for the ELAM? Or other products based on the daughter-brd interface to the 2413.

 

A while back in my testing I added a feature to the ELAM to detect corrupted messages. It was my suspicion that the checksum was not sufficient and failing to detect corrupted messages.

Now i2CS is being presented. .... Makes me very curious ?

 

Yes, than it would more than likely require you to purchase the SDK kit to keep abreast of all the internal changes. As I stated earlier (baring ongoing changes) I know your continued efforts into this project at best is a never ending and elusive test, validate, and check again.

 

Regardless, your efforts thus far have been impressive and inspiring at the end of the day.

 

Teken . . .

[LeeG]

ELA

 

Your ELAM PLM may not be able to communicate with an I2CS device. Some commands may work, extended commands may not work. Although not quite as strict as the MorningLinc it is something like that. The I2CS devices do not accept some commands from PLMs they do not know about. That is in addition to the "checksum" aspects of I2 CheckSum. I realize my information is wishy washy because I just do not know. I have done some testing with I2CS devices. They are in the retail stream from Smarthome. I know some things have not worked but do not have a good list of what does or does not work. Also finding out that not all I2CS devices reject commands the same way (why would they, that would be too much to hope for).

 

Go to this topic to see an event trace (about 4 posts in) from an I2CS device that could not be added to the ISY on 3.1.17 because no I2CS support. Might provide some insight as to how things fail.

 

viewtopic.php?f=27&t=8419

 

EDIT: the long awaited drop of Peek/Poke is happening with I2CS.

[ELA]

Teken,

From what I have heard the developers registration is not as informative as one might hope? Plus there is the NDA signing thing.

 

Thanks for offering what you know about I2CS LeeG,

When you say in the retail stream does that mean we may be purchasing them when we make new orders? Is there an outward marking that lets us know they are I2CS?

 

The reason I ask is that I just ordered a switchlinc replacement for the one i1 device that remains in my home. I was curious if it might be a I2CS device?

 

If it is I2CS then replacing my one and only i1 device with it would make my communications flawless huh

 

I do not know anything about Morninglinc. I had followed a few posts on I2CS and the need to upgrade ISY code.

[Brian H]

Yes there are users here with I2CS modules now.

I have not seen any official announcement even though the Developers Group members where told one would be made before releasing them.

Some I1 and I2 commands no longer work with I2CS modules. That is one reason the ISY Firmware added I2CS at 3.2.0 and added corrections to the just released 3.2.2.

[LeeG]

It is very likely the SwitchLinc will be I2CS. A few users have already encountered problems with I2CS SwitchLincs on 3.1.17. Nothing indicates such on the box. Like I2, the devices just come with it. It should not matter as far as compatibility with normal Insteon usage. Of course users will have to upgrade to the 3.2.x beta stream. I picked up a Motion Sensor and FanLinc from Smarthome a few weeks ago, both were I2CS devices. The Motion Sensor is Rev 2.1, the FanLinc Rev 1.05. Like I2 there will be some noise for a few weeks until users get on 3.2.x and any bugs get ironed out. After that it won’t matter. Nobody talks about Hey I got an I2 device anymore.

[ELA]

Thank you both,

 

I find it both enjoyable and invaluable to be able to discuss Insteon details with people on this forum.

I understand a desire to keep their IP protected but I would hope for at least a notification in advance. SmartHome could do much better at sharing that which they are able to.

 

Looks like I will have an interesting change-out coming up with my switchlinc.

It was the last i1 device I had. It is located at the end of a circuit run with over 11 devices on that run. That is a heavy Insteon load and that circuit is the one (known) remaining weak area in my home network. I have a lot of data collected from that area and it will be interesting to see if I can detect any improvement when this device is changed out.

 

One other question I would like to ask is what is the best method at this point to assure yourself that you have an I2CS device?

Hardware version numbers? ... Is this a firmware only change? If so then I would guess Firmware version number? Or is there an internal value in the device ID message that might be best?

 

As always I appreciate your knowledge and your willingess to share.

[LeeG]

I am sure a few months from now the list of device/firmware levels will be created by someone. There is a user web site that is collecting all the information users send to him. Of course it is dependent on users feeding back the device information so it can be compiled. This web site has been collecting and publishing device information for a long time.

 

http://www.madreporite.com/insteon/Inst ... e_list.htm

 

No doubt SmartLabs knows what firmware has I2CS but that will not be shared. They never have in the past. Not sure about hardware. Both the FanLinc and Motion Sensor have higher Rev levels along with I2CS but that could be coincidence.

 

As far as knowing it is I2CS, not being able to write to device. Unfortunately how you know the writes do not work varies. I have seen commands get a FD in the ACK cmd2 field. Guess is that means the CheckSum value is not correct or maybe the PLM is not authorized to access the device. I have seen commands look like they work fine but the link database is not valid. It looks like the I2CS devices have dropped Peek/Poke which may explain the link database being wrong. This is observed information from a limited set of devices. Likely more variations will surface over time.

[Brian H]

ELA; You maybe able to see some things if you have the Event Viewer running in #3 Communications Events. When you add the replacement SwitchLinc to your setup.

 

Here is a Link Database read for a Beta I2CS 4050 I/OLInc.

Sat 03/31/2012 02:58:10 PM : [iNST-TX-I2CS] 02 62 1C 06 23 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2

 

Sat 03/31/2012 02:58:10 PM : [iNST-ACK ] 02 62 1C.06.23 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00)

 

Sat 03/31/2012 02:58:11 PM : [iNST-SRX ] 02 50 1C.06.23 19.70.1A 2B 2F 00 (00)

 

Sat 03/31/2012 02:58:11 PM : [standard-Direct Ack][1C.06.23-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

Sat 03/31/2012 02:58:11 PM : [iNST-ERX ] 02 51 1C 06 23 19 70 1A 11 2F 00 01 01 0F FF 00 A2 00 19 70 1A FF 1F 01 5D

 

Sat 03/31/2012 02:58:11 PM : [Extended-Direct][1C.06.23-->ISY/PLM Group=0] Max Hops=1, Hops Left=0

 

Sat 03/31/2012 02:58:11 PM : [iNST-TX-I2CS] 02 62 1C 06 23 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 CA

 

Sat 03/31/2012 02:58:11 PM : [iNST-ACK ] 02 62 1C.06.23 1F 2F 00 00 00 0F F7 01 00 00 00 00 00 00 00 00 CA 06 (00)

 

Sat 03/31/2012 02:58:12 PM : [iNST-SRX ] 02 50 1C.06.23 19.70.1A 2B 2F 00 (00)

 

Sat 03/31/2012 02:58:12 PM : [standard-Direct Ack][1C.06.23-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

Sat 03/31/2012 02:58:12 PM : [iNST-ERX ] 02 51 1C 06 23 19 70 1A 11 2F 00 01 01 0F F7 00 E2 01 19 70 1A FF 1F 01 24

 

Sat 03/31/2012 02:58:12 PM : [Extended-Direct][1C.06.23-->ISY/PLM Group=0] Max Hops=1, Hops Left=0

 

Sat 03/31/2012 02:58:12 PM : [iNST-TX-I2CS] 02 62 1C 06 23 1F 2F 00 00 00 0F EF 01 00 00 00 00 00 00 00 00 D2

 

Sat 03/31/2012 02:58:12 PM : [iNST-ACK ] 02 62 1C.06.23 1F 2F 00 00 00 0F EF 01 00 00 00 00 00 00 00 00 D2 06 (00)

 

Sat 03/31/2012 02:58:13 PM : [iNST-SRX ] 02 50 1C.06.23 19.70.1A 2B 2F 00 (00)

 

Sat 03/31/2012 02:58:13 PM : [standard-Direct Ack][1C.06.23-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

Sat 03/31/2012 02:58:13 PM : [iNST-ERX ] 02 51 1C 06 23 19 70 1A 11 2F 00 01 01 0F EF 00 00 00 00 00 00 00 00 00 D1

 

Sat 03/31/2012 02:58:13 PM : [Extended-Direct][1C.06.23-->ISY/PLM Group=0] Max Hops=1, Hops Left=0

 

Sat 03/31/2012 02:58:13 PM : [All ] Writing 0 bytes to devices

 

Query Engine same module.

Sat 03/31/2012 02:58:37 PM : [All ] Writing 1 bytes to devices

 

Sat 03/31/2012 02:58:37 PM : [iNST-TX-I1 ] 02 62 1C 06 23 0F 0D 00

 

Sat 03/31/2012 02:58:37 PM : [iNST-ACK ] 02 62 1C.06.23 0F 0D 00 06 (00)

 

Sat 03/31/2012 02:58:38 PM : [iNST-SRX ] 02 50 1C.06.23 19.70.1A 2B 0D 02 (02)

 

Sat 03/31/2012 02:58:38 PM : [standard-Direct Ack][1C.06.23-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

Sat 03/31/2012 02:58:38 PM : [1C 6 23 0 ] Calibrating engine version

[ELA]

Thanks Brian, I will try to digest what "detail" I can glean from the communications traces when I get my first I2CS device.

 

I will be updating my ISY code tomorrow. I had recently installed a Fanlinc and was waiting for the update in the ISY. I did not anticipate needing the I2CS aspect as well.

I am also getting an appliancelinc with the switchlink ordered and if that is I2CS it will be a handy experimental module before I install it.