Some 2413S Hardware 2 Observations

[Brian H]

I received a hardware 2.1, Firmware 9E, 2413S PLM. That I wanted to evaluate.

C3 6.8Uf/250V, C11 100uF/25V and C8 10uF/16V. Same as hardware 1 models.
C7 and C13. Now 100uF/35V Fujicon RK series capacitor.
Fujicon RK specifications sheet says General Purpose, 105C Wide Temperature.

I exchanged my older PLM for the new one. 

 

As other had found the original 2440 RemoteLincs would not update or restore.
I did my test with the PLM as the only Dual Band Module in the system and it didn't matter close or far from the PLM.
Today I tried a different test. Put the 2440 at the other end of the house next to an Access Point and it restored fine.
I also found a Read a Device Link Tables did not work if the PLM was the only Dual Band Module in the setup but was fine again if I had it all the way at the other end of the house next to an Access Point.

I don't know if the RF controller chips firmware is different from the older models as I have no way to find it. Other than maybe looking for a sticker on the controller.
The Beacon-Communications Tests. Seemed to be about the same with it as a sender or receiver. With tests comparing it in different locations to known modules.
One thing I did see. Was the LED on the new PLM flashed a different pattern on receiving. Both same and opposite phase detection.
When sending. The receiving Dual Band Modules also flashed in a different pattern from what I had seen with other Dual band Modules sending.

I have some Event Viewer Level 3 files I am going to post later after I clean them up and add some information. For the 2440 RemoteLinc issue.
 

[Brian H]

Event Viewer Level 3.

RemotrLinc Factory Reset between tries.
Long Event Viewer files only showing the starting lines not the whole file.

New 2413S PLM Hardware 2.1, Firmware 9E, ID:34.E9.19
All other Dual Band Modules Disconnected.

Thu 05/21/2015 02:44:46 PM : [    A C CE 1] Preparing Device 'RemoteLinc 1 Button ' for Restore
Thu 05/21/2015 02:44:46 PM : [    A C CE 1] Device 'RemoteLinc 1 Button ' ready for Full Restore
Thu 05/21/2015 02:44:46 PM : [All         ] Writing 185 bytes to devices
Thu 05/21/2015 02:44:46 PM : [iNST-TX-I1  ] 02 62 0A 0C CE 0F 0D 00
Thu 05/21/2015 02:44:46 PM : [iNST-ACK    ] 02 62 0A.0C.CE 0F 0D 00 06                 (00)
Thu 05/21/2015 02:44:55 PM : [iNST-TX-I1  ] 02 62 0A 0C CE 0F 0D 00
Thu 05/21/2015 02:44:55 PM : [iNST-ACK    ] 02 62 0A.0C.CE 0F 0D 00 06                 (00)
Thu 05/21/2015 02:45:04 PM : [iNST-TX-I1  ] 02 62 0A 0C CE 0F 0D 00
Thu 05/21/2015 02:45:04 PM : [iNST-ACK    ] 02 62 0A.0C.CE 0F 0D 00 06                 (00)

Older 2413S PLM Hardware 1.5, Firmware 98, ID:19.70.1A
All other Dual Band Modules Disconnected.

Thu 05/21/2015 03:21:01 PM : [    A C CE 1] Preparing Device 'RemoteLinc 1 Button ' for Restore
Thu 05/21/2015 03:21:01 PM : [    A C CE 1] Device 'RemoteLinc 1 Button ' ready for Full Restore
Thu 05/21/2015 03:21:01 PM : [All         ] Writing 0 bytes to devices
Thu 05/21/2015 03:21:15 PM : [All         ] Writing 185 bytes to devices
Thu 05/21/2015 03:21:15 PM : [iNST-TX-I1  ] 02 62 0A 0C CE 0F 0D 00
Thu 05/21/2015 03:21:15 PM : [iNST-ACK    ] 02 62 0A.0C.CE 0F 0D 00 06                 (00)
Thu 05/21/2015 03:21:15 PM : [iNST-SRX    ] 02 50 0A.0C.CE 19.70.1A 2B 0D 01           (01)
Thu 05/21/2015 03:21:15 PM : [std-Direct Ack] 0A.0C.CE-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Thu 05/21/2015 03:21:15 PM : [A C CE 0    ] Calibrating engine version
Thu 05/21/2015 03:21:15 PM : [A C CE 0    ] May not fully support i2, reverting to i1

The new PLM never showed a INST-SRX message received back from the Remotelinc.

Tested with new PLM again. This time at the other end of the house. Near a 2443 Access Point.

Fri 05/22/2015 03:26:39 PM : [        Time] 15:26:39 0(0)

Fri 05/22/2015 03:26:53 PM : [    A C CE 1] Preparing Device 'RemoteLinc 1 Button ' for Restore

Fri 05/22/2015 03:26:53 PM : [    A C CE 1] Device 'RemoteLinc 1 Button ' ready for Full Restore

Fri 05/22/2015 03:26:54 PM : [All         ] Writing 185 bytes to devices

Fri 05/22/2015 03:26:54 PM : [iNST-TX-I1  ] 02 62 0A 0C CE 0F 0D 00

Fri 05/22/2015 03:26:54 PM : [iNST-ACK    ] 02 62 0A.0C.CE 0F 0D 00 06                 (00)

Fri 05/22/2015 03:26:54 PM : [iNST-SRX    ] 02 50 0A.0C.CE 34.E9.19 2B 0D 01           (01)

Fri 05/22/2015 03:26:54 PM : [std-Direct Ack] 0A.0C.CE-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Fri 05/22/2015 03:26:54 PM : [A C CE 0    ] Calibrating engine version

Fri 05/22/2015 03:26:54 PM : [A C CE 0    ] May not fully support i2, reverting to i1

Tried reading the Device Link Table on the Remotelinc. With only the PLM and no other Dual Band Modules.
It also failed.

Fri 05/22/2015 03:50:17 PM : [iNST-TX-I1  ] 02 62 0A 0C CE 0F 28 0F

Fri 05/22/2015 03:50:17 PM : [iNST-ACK    ] 02 62 0A.0C.CE 0F 28 0F 06          SET-MSB(0F)

Fri 05/22/2015 03:50:26 PM : [iNST-TX-I1  ] 02 62 0A 0C CE 0F 28 0F

Fri 05/22/2015 03:50:26 PM : [iNST-ACK    ] 02 62 0A.0C.CE 0F 28 0F 06          SET-MSB(0F)

Fri 05/22/2015 03:50:35 PM : [iNST-TX-I1  ] 02 62 0A 0C CE 0F 28 0F

Fri 05/22/2015 03:50:35 PM : [iNST-ACK    ] 02 62 0A.0C.CE 0F 28 0F 06          SET-MSB(0F)

Fri 05/22/2015 03:50:39 PM : [All         ] Writing 0 bytes to devices


With all the Dual Band Modules and near the Access Point at the other end of the house. Read Device Link Table also worked OK.

Fri 05/22/2015 03:59:28 PM : [iNST-TX-I1  ] 02 62 0A 0C CE 0F 28 0F

Fri 05/22/2015 03:59:28 PM : [iNST-ACK    ] 02 62 0A.0C.CE 0F 28 0F 06          SET-MSB(0F)

Fri 05/22/2015 03:59:28 PM : [iNST-SRX    ] 02 50 0A.0C.CE 34.E9.19 2B 28 0F    SET-MSB(0F)

Fri 05/22/2015 03:59:28 PM : [std-Direct Ack] 0A.0C.CE-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Fri 05/22/2015 03:59:28 PM : [iNST-TX-I1  ] 02 62 0A 0C CE 0F 2B F8

Fri 05/22/2015 03:59:28 PM : [iNST-ACK    ] 02 62 0A.0C.CE 0F 2B F8 06          PEEK   (F8)

Fri 05/22/2015 03:59:29 PM : [iNST-SRX    ] 02 50 0A.0C.CE 34.E9.19 2B 2B E2    PEEK   (E2)

Fri 05/22/2015 03:59:29 PM : [std-Direct Ack] 0A.0C.CE-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Fri 05/22/2015 03:59:29 PM : [iNST-TX-I1  ] 02 62 0A 0C CE 0F 28 0F

Fri 05/22/2015 03:59:29 PM : [iNST-ACK    ] 02 62 0A.0C.CE 0F 28 0F 06          SET-MSB(0F)
 

[Brian H]

I also saw what others have reported.

Event Viewer now may show Max Hops=3  Hops Left=3. On some modules. Even my original I1 2456S firmware v.28 Appliancelincs.

[Teken]

I also saw what others have reported.

Event Viewer now may show Max Hops=3 Hops Left=3. On some modules. Even my original I1 2456S firmware v.28 Appliancelincs.

What exactly is the reason for this? That makes no sense at all from a technical stand point.

 

 

Ideals are peaceful - History is violent

[LeeG]

The Hops Left=3 started with the v2.0 PLM.  I don't know what PLM firmware logic change produces that count.

 

Example...

 

http://forum.universal-devices.com/topic/16112-just-started-having-problems-writing-updates/

[Teken]

The Hops Left=3 started with the v2.0 PLM. I don't know what PLM firmware logic change produces that count.

 

Example...

 

http://forum.universal-devices.com/topic/16112-just-started-having-problems-writing-updates/

Using this current method of 3 hops left is one to assume this mirrors what a 2 hops left was before?

 

Meaning 2 hops left was perfect and ideal because 1 hop was used to send and ack the signal.

 

Now with the new method if the system returns a 3 hops left a person should assume this means the same thing as the 2 hops premise.

 

 

Ideals are peaceful - History is violent

[LeeG]

That is what I have been assuming (until someone can explain the actual reason for change).  The devices themselves have not changed so something in the PLM looks at the results differently.

 

I have considered it may be receiving an RF message by PLM but that is only a guess.  No testing to verify that.

[larryllix]

Using this current method of 3 hops left is one to assume this mirrors what a 2 hops left was before?

 

Meaning 2 hops left was perfect and ideal because 1 hop was used to send and ack the signal.

 

Now with the new method if the system returns a 3 hops left a person should assume this means the same thing as the 2 hops premise.

 

 

Ideals are peaceful - History is violent

I never read "hops" to mean transmissions between devices but rather "repeats" by the the devices.

 

If a signal is transmitted by one device and received by the intended end device that would be zero hops involved.

 

Perhaps the PLM has just realised the error of it's ways.

[Teken]

That is what I have been assuming (until someone can explain the actual reason for change). The devices themselves have not changed so something in the PLM looks at the results differently.

 

I have considered it may be receiving an RF message by PLM but that is only a guess. No testing to verify that.

Understood, most of us are simply guessing basing our trouble shooting based on personals observation and trial and error.

 

Perhaps one day someone will take the time to update the Insteon white paper and explain some of this to the masses.

 

What I do know is some of these features and firmware updates we have slowly seen integrated into various products like the leak sensor, open close, dual outlet, etc.

 

Are feature sets getting ready for i3CS. There was a draft document I saw from someone online a few months back. Wish I had book marked that discussion ha!

 

 

Ideals are peaceful - History is violent

[Teken]

I never read "hops" to mean transmissions between devices but rather "repeats" by the the devices.

 

If a signal is transmitted by one device and received by the intended end device that would be zero hops involved.

 

Perhaps the PLM has just realised the error of it's ways.

Perhaps that is one way to look at it! Because if I follow your logic it makes sense. If you send a command and it works there is no retry.

 

So based on the Insteon protocol that would be accurately reflected. If the system needs to retry then it should deprecate the count by one.

 

 

Ideals are peaceful - History is violent

[larryllix]

Perhaps that is one way to look at it! Because if I follow your logic it makes sense. If you send a command and it works there is no retry.

 

So based on the Insteon protocol that would be accurately reflected. If the system needs to retry then it should deprecate the count by one.

 

 

Ideals are peaceful - History is violent

Retries are not hop counts! I think we have terminology mixed up. Whether the end device receives it on the virgin signal or not the hops are going to happen anyway 'cause that is what a mesh network will do limited by the hop allowance.

 

As I understand it, if after all the hopping needed to get to the end device,  the end device does not send ACK back through all the hops needed again to the originator of the message, the originator  of the message sends it again doing a retry.

 

With the mesh network, dual bands, hopping, and retries,   a noisy Insteon network can bog down with just politics of communication protocols and no actual communications get through. I am sure this is why hops and retries are limited to small numbers  'cause the confusion goes up exponentially with the allowed quantities of system distrust compensation when signal channels get bad.

[G W]

I never read "hops" to mean transmissions between devices but rather "repeats" by the the devices.

 

If a signal is transmitted by one device and received by the intended end device that would be zero hops involved.

 

Perhaps the PLM has just realised the error of it's ways.

That's how I read it.

[Teken]

Retries are not hop counts! I think we have terminology mixed up. Whether the end device receives it on the virgin signal or not the hops are going to happen anyway 'cause that is what a mesh network will do limited by the hop allowance.

 

As I understand it, if after all the hopping needed to get to the end device,  the end device does not send ACK back through all the hops needed again to the originator of the message, the originator  of the message sends it again doing a retry.

 

With the mesh network, dual bands, hopping, and retries,   a noisy Insteon network can bog down with just politics of communication protocols and no actual communications get through. I am sure this is why hops and retries are limited to small numbers  'cause the confusion goes up exponentially with the allowed quantities of system distrust compensation when signal channels get bad.

 

Well technically the two are related because you can't say a retry isn't going to impact the hop count. If I send a command from a originator that is going to a end device. If it doesn't respond the system will retry 2 more times which is two more hops.

 

So what you're saying is if I start this process right now and I press on a paddle. This is considered one attempt and the system will try to hop three times to rebroadcast this message until the end device acks said messages. If the three hops are maxed out the system can be programmed (as seen in various options) to retry from 0-9 times I think.

 

This would essentially mimic me pressing the paddle 0-9 more times and the three hop process would continue. This is how I understand it but in the big scheme of things it doesn't really matter because it doesn't address to physical hardware limitations and technology being used.

 

Case in point only most recently has Insteon increased the RF output which is good because it was brutal. But this does not address the problem of them still installing the antenna in the rear of the devices for those hardwired devices like switches.

 

It also does not address the simple fact the RF portion is tied and linked to the power line.  

[JayC]

Or does it determine the best path to ensure only a maximum of 3 hops are required to communicate from device to device?  In networking the number of hops represents the many paths it takes for one device to communicate with its end device.  From a PC standpoint you can open CMD and type "tracrt google.com".  This will display each hop the PC takes in order to be able to communicate with google.com.  PC's go through various gateways to get to other networks, and each of those are represented by 1 hop.  I am not sure if hops on a PC directly correlates to the hops on the PLM, I can only assume.  If I am way off base, then please pardon my ignorance.

 

Edit:  I know this in the wrong forum, however, I am new to ISY and perhaps if it isn't a feature already maybe a tracert type of diagnostic tool could be implemented so that you can test communication hops between devices.

[Teken]

Or does it determine the best path to ensure only a maximum of 3 hops are required to communicate from device to device?  In networking the number of hops represents the many paths it takes for one device to communicate with its end device.  From a PC standpoint you can open CMD and type "tracrt google.com".  This will display each hop the PC takes in order to be able to communicate with google.com.  PC's go through various gateways to get to other networks, and each of those are represented by 1 hop.  I am not sure if hops on a PC directly correlates to the hops on the PLM, I can only assume.  If I am way off base, then please pardon my ignorance.

 

Edit:  I know this in the wrong forum, however, I am new to ISY and perhaps if it isn't a feature already maybe a tracert type of diagnostic tool could be implemented so that you can test communication hops between devices.

 

In the Insteon world each device is sent a message and each device simultaneously re-transmits the originator signal. In the networking world the hops show physical nodes that handle the traffic to then pass them on to the next node.

 

Insteon does not do selective node transmissions . . . 

[larryllix]

In the Insteon world each device is sent a message and each device simultaneously re-transmits the originator signal. In the networking world the hops show physical nodes that handle the traffic to then pass them on to the next node.

 

Insteon does not do selective node transmissions . . . 

Quite correct but "Retries" are something different than "Hops" and performed by a different layer of the protocol. The originating device does not perform the hop. The originating device does the retry.

 

Try this:

In the Admin Console, Right click on a commonly used device, select Advanced | PLM Communication

Now you should see the setting for the "Reties" for that device. It will probably be set to "1"     (***UDI note the box is too small top to bottom to see the contents***)

 

But your device still does 3 hops, if needed.

 

Hops are a hardware facilitated technique the intermediary devices use for the signal to get to the end device. 

     Orig--->1--hop-->2--hop--->End

 

Retries are a software facilitated technique for the sender to attempt it again upon failure of the above system.

      Orig--->1--hop--2-->hop-->End.........Retry =Orig--->1--hop-->2--hop-->End.........Retry=Orig--hop-->1--hop-->2--hop-->End

[Teken]

Quite correct but "Retries" are something different than "Hops" and performed by a different layer of the protocol. The originating device does not perform the hop. The originating device does the retry.

 

Try this:

In the Admin Console, Right click on a commonly used device, select Advanced | PLM Communication

Now you should see the setting for the "Reties" for that device. It will probably be set to "1"     (***UDI note the box is too small top to bottom to see the contents***)

 

But your device still does 3 hops, if needed.

 

Hops are a hardware facilitated technique the intermediary devices use for the signal to get to the end device. 

     Orig--->1--hop-->2--hop--->End

 

Retries are a software facilitated technique for the sender to attempt it again upon failure of the above system.

      Orig--->1--hop--2-->hop-->End.........Retry =Orig--->1--hop-->2--hop-->End.........Retry=Orig--hop-->1--hop-->2--hop-->End

 

 

I believe your above illustration explained it much better than my (attempted) hack wording.

 

Ha . . . 

[LeeG]

Just to make things more complex the Retry Count applies to I2CS devices only.  I1 and I2 devices do not have that capability.  Many of my house/garage/dock installed devices are years old and do not have Retry Count adjustment.

 

Many of my test bed devices are I2CS and do support setting Retry.

 

 

[Teken]

Has anyone performed any stringent testing to see if a Insteon storm would ensure setting various devices to say 9 retries? I too have older products which do not support the retry attempt.

 

I do however believe its a great feature / tool should it be required. But, don't think its something that should be relied upon just to make something operate as it should. Doing so in my mind indicates a fault in the Insteon network whether that be no coupling / bridging, to noise makers, signal suckers.

 

At the end of the day Smartlabs has made great strides in the hardware / protocol firmware front. It would just be a lot better if they took the time to explain the theory of operations and what to expect given a specific instance etc.

[larryllix]

...

 

 

At the end of the day Smartlabs has made great strides in the hardware / protocol firmware front. It would just be a lot better if they took the time to explain the theory of operations and what to expect given a specific instance etc.

The manufacturers have a hard enough time translating the Engrish spec let alone writing instructions for it. I don't believe SH does much other than engineer new products, if they even do that anymore, or ever did.

 

How does anyone know that SH isn't just a sales outlet / warehouser to bypass some country border politics? SH may not know what some of the features are that are built in without paying for the extra special package. (would you like fries with that?)

[Teken]

The manufacturers have a hard enough time translating the Engrish spec let alone writing instructions for it. I don't believe SH does much other than engineer new products, if they even do that anymore, or ever did.

 

How does anyone know that SH isn't just a sales outlet / warehouser to bypass some country border politics? SH may not know what some of the features are that are built in without paying for the extra special package. (would you like fries with that?)

 

LOL, no . . .

 

Joe Dada knows and so does the rest of the upper management. The honest truth is they have decided to keep a tight lip on even the most non important aspects of their hardware, software, firmware. In 2015 where they stand alone its evident not a soul is interested in supporting them.

 

So, there is no reason to keep any secrets or otherwise . . .

 

I know in another forum there was a ex engineer who actually spoke very openly about *his views and thoughts* as to the why's which is where I have also come to the same conclusions of some of my views and comments.

 

Nobody can go back in time and change history as we all know it. The only reason Joe Dada has jumped on the Apple Home Kit, and similar platforms is because they have absolutely no other third party backers making their wares!

 

As I stated long ago their long term plan should be to hand out free Insteon chips to all makers so it can be included into their finished products. These advanced chips would not only allow the end user to turn something on/off but also know the energy consumption, along with other variables should the product support it.

 

Like say a hot water kettle: It would allow you to turn it on, off, show the power consumption in watts, KWH, and the line voltage. It would allow you to natively schedule the device to come on/off for a what ever period etc.

 

I can't recall the Chinese company that Paul mentioned wanting to do the very same. But the reality is this X company clearly has the common sense and will to do so and they obviously wont miss the HA train unlike Smartlabs / Smarthome.

 

Embedded tech is where its at and this is such a basic concept that I have to shake my head at as to why its not being pushed. 

[stusviews]

The manufacturers have a hard enough time translating the Engrish spec let alone writing instructions for it. I don't believe SH does much other than engineer new products, if they even do that anymore, or ever did.

 

How does anyone know that SH isn't just a sales outlet / warehouser to bypass some country border politics? SH may not know what some of the features are that are built in without paying for the extra special package. (would you like fries with that?)

 

I've been to and toured virtually all of SH/Insteon Labs. The building is replete with engineers constantly buzzing with about how to add features and designing new products. They're well aware of all the features (and lack of) of the products because they designed and incorporated them.

 

The SwitchLinc paddles have a hole in one corner so that devices can be flashed and used (and ultimately tested) by non-technical persons such as secretaries and maintenance personnel.

 

There are writers revising instructions. That's a tough chore. Even standard devices such as fixtures come with directions that are meant for a person with at least a minimal knowledge of wiring and mechanical skills which is not always the case. Have you ever explained something to someone only to find they got it wrong?

 

New devices are tested extensively (Alpha) and then sent to a larger group of Betas testers for evaluation in-the-field. Some devices never make it to market.

 

A separate part of the building is the retail store. That part is a sales outlet/warehouse which includes a stockpile of Insteon devices and virtually all the other products seen on their website

[larryllix]

I've been to and toured virtually all of SH/Insteon Labs. The building is replete with engineers constantly buzzing with about how to add features and designing new products. They're well aware of all the features (and lack of) of the products because they designed and incorporated them.

 

The SwitchLinc paddles have a hole in one corner so that devices can be flashed and used (and ultimately tested) by non-technical persons such as secretaries and maintenance personnel.

 

There are writers revising instructions. That's a tough chore. Even standard devices such as fixtures come with directions that are meant for a person with at least a minimal knowledge of wiring and mechanical skills which is not always the case. Have you ever explained something to someone only to find they got it wrong?

 

New devices are tested extensively (Alpha) and then sent to a larger group of Betas testers for evaluation in-the-field. Some devices never make it to market.

 

A separate part of the building is the retail store. That part is a sales outlet/warehouse which includes a stockpile of Insteon devices and virtually all the other products seen on their website

Thanks for that Stu!

 

This is good to hear but disappointingly it points back to their attitude or just shortage of money.

Being their hardware is all manufactured in China it would really surprise me that at east some of the firmware is not written there also. I would be sure the Chinese would gobble that one up.

 

The instruction they include with hardware are just a joke. I don't even bother opening most of them before the garbage now. I hope they don't change wiring colours in N. America.