Announcement

**Jon** · February 4, 2016, 11:04 PM

I think I have them all done except two now.
One is just refusing to program.

Device Type: SwitchLinc V2 600W Dimmer
Firmware Version: 35

It's showing the following links:
<TABLE cellSpacing=1 cellPadding=0 border=0> <TBODY> <TR> <TD>Link #1</TD> <TD>Switch/Load is controlled by Unregistered Device Group 0 (29.71.09) - On Level 100%, Ramp Rate 2 Sec.</TD></TR> <TR> <TD>Link #2</TD> <TD>Switch/Load is controlled by Family Room Side Ceiling (Slave Stairs Bottom) (0F.04.7A) - On Level 100%, Ramp Rate 2 Sec.</TD></TR> <TR> <TD>Link #3</TD> <TD>Switch/Load controls Unregistered Device (29.71.09)</TD></TR> <TR> <TD>Link #4</TD> <TD>Switch/Load is controlled by Unregistered Device Group 254 (29.71.09) - On Level 100%, Ramp Rate .1 Sec.</TD></TR> <TR> <TD>Link #5</TD> <TD>Switch/Load controls Family Room Side Ceiling (Slave Stairs Bottom) (0F.04.7A)</TD></TR> <TR> <TD>Link #6</TD> <TD>Switch/Load is controlled by Unregistered Device Group 1 (29.71.09) - On Level 0%, Ramp Rate 2 Sec.</TD></TR></TBODY></TABLE>

Comm reliability is pretty low. 56% The odd thing is that this device used to respond rather well all the time before this interface swap. Even without the hub links, It still seems to respond after a while to the on/off commands. (10-15 secs). It's part of a (virtual) 3 way circuit. It's the switch connected to the load. The link to the slave switch is working fine. The slave reprogrammed fine and they're not that far apart electrically. The weird thing is that I'm not getting an error. When the continue button shows up, I'm getting the following.

Now attempting to program your device Family Room Side Ceiling (0F.0B.96) for use with HomeSeer...
<HR noShade>

Press the 'Continue' button to continue setting up the plug-in

[Continue button]

Checking the logs I'm seeing a lot of this error:

Did not receive a response from Family Room Side Ceiling (0F.0B.96). Try #4 failed.
Oddly enough, every time I press a button on that switch itself, I'm seeing:

<TABLE class=log_table_row cellSpacing=0> <TBODY> <TR> <TD class=LogType0 colSpan=3 align=left></TD> <TD class=LogEntry0 colSpan=8 align=left>Received 0F.0B.96:1 (Family Room Side Ceiling) Go ON </TD></TR></TBODY></TABLE>

The other problem device is my IO Linc. I just got this last week. I struggled to get it programmed the first time, but I finally got it. Now I keep getting the "device cannot be contacted" error.

**Jon** · February 5, 2016, 09:41 AM

Update. I got all of my devices reprogrammed. I got the iolinc by moving it right next to the hub. To get the Switchlinc done I moved a dual band dimmer module around to different outlets in that room until I found one close enough where it worked. So I suppose in both cases it was just a case of power line Comm issues. Both modules still work after being linked when I put them back to their original positions without doing any other moving around. Though i could tell its bit as fast as it should.
So the lingering question remains, did I do something wrong in my process that made this so time consuming having to reconfigure every device?
It also appears there's a bug with the failed programming of that problem Switchlinc. I never got a message saying it failed.
Now a few feature requests.
In all of the device programming processes, the one status line refreshes in place at the top. First off it would be nice if this page updates in place in realtime rather than reloading. Secondly it would be nice if the status accrue into a list in screen rather than the best kne overwriting the first. Kinda like a log. It would also be nice for it to show the result of each step.
It would be nice to directly edit and add links to Devices by manually entered Insteon ID.
Here's a bigger change idea. I fully realize this is potentially a big change and could require a substantial rewrite. This whole hub replacement process suggests to me that it's not database driven. Or if it is, it's not used as effectively as possible. Please correct me if I'm wrong. It feels like it could be handled more smoothly If all links were stored in a database in the plugin. The DB would only need two tables for link maintenance. One table would be the device table. It would contain things like the Id of each device, name, HS reference, devCat, and maybe the basic stats and such that are in the table of the existing device page. The Insteon ID can be the PK. The other would be the link table. This would be simply be a unique link PK for each link and the source, destination, level and ramp rare for each link. With such a database it seems like device management could be simplified. You could maintain this link table complete in the plugin, including links that are not managed by HS. Each device could have a function to read links from the device and add them to the HS table, and there would also be the opposite to replace the link table with the info in the plugin database.
To further this idea, I'd suggest an option to read the link table from the device every time you enter the management page for the device. The link table can show on screen in a color coded fashion. Perhaps links that are only in the device are in yellow, links that are in the plugin but not the device are in red and the links that match in both are green. Check boxes on each line can be offered to remove the link, delete from homeseer, or delete from device.
An advantage of a DB based on a standard DB format could offload some of the advanced management and reporting tasks for some users. I for one would be perfectly comfortable using a SQL management tool to update records for a process like a hub or device swap. It would become simple SQL commands like "update link where sourceID = 'OldID' set sourceID = 'newID'" and a corresponding query for destinationID. Then I could just restart HS and use the function mentioned above to reconcile the devices with the plugin database.
There's several DB types that would work for this. Anything from SQLite to MS SQL compact or the heavier but more modern LocalDB.
In any case though, as tedious as my process was, it was still far simpler than anything else I'm aware of for Insteon management. All of the ideas above are just food for thought to potentially make it even better. Thanks Mark.

--Jon Chuchla--

Sent from my iPhone using Tapatalk

**mnsandler** · February 5, 2016, 11:30 AM

jon, thanks for the all the feedback. what plugin version were you running when you did this?

i made a change to the recent betas to simply the process. but comm reliability is a big part of the swap because the plugin has to rewrite every device with a plm id in its database.

**Jon** · February 5, 2016, 02:46 PM

I think it was .60. I just updated it last week when I was struggling with the new IO linc.

Most of the devices that failed on the first pass reprogrammed just fine when I did them individually. I think only 2 or 3 were successful on the first bulk reprogram. It was really only the two that gave me lots of trouble. So I suspect something more going on than just Comm reliability.

--Jon Chuchla--

Sent from my iPhone using Tapatalk

**Jon** · March 4, 2016, 06:49 PM

I wanted to follow up on this thread. I had my one switch that gave me trouble while doing the interface swap. It's still been much slower to respond than anything else in my system. But it was an older PL only switchlinc. So since smartphone had an awesome sale last week I picked up some new ones. I decided to replace this switch with a dual band version. But when I went to take the old one out of the wall here is what I found:

The filter cap next to the tuning pot was completely disintegrated. There was a diode on the other end of the board that has its outer coating burned off. No wonder it wasn't working right.
The funny thing is that it still works, just with a lot of Comm failures.
No it was not overloaded. Just 1 fixture with 3 60w Incan bulbs. This was the only dimmer in the wall box. The wall box is steel and the adjoining switch is a standard non-dim two way switch. So derating wasn't an issue.
I wonder what Insteon will have to say about this.

--Jon Chuchla--

Sent from my iPhone using Tapatalk

**mnsandler** · March 4, 2016, 09:11 PM

Jon, i pulled one of my old i1 switchlincs and found something similar. let us know what smarthome says or does.

**Jon** · March 4, 2016, 09:21 PM

Absolutely.
Ironically. I spent the last few days at a training program at Crestron. I've been a Crestron programmer/dealer for the last 15 years. We were having a conversation at lunch time about devices catching fire. The instructor of the class is also the tech support lead for this region. He was telling us they have a policy that any time there's fire or even a smoke smell involved, they immediately overnight a replacement product regardless of warranty status. They also issue a call tag to return ship the bad product at their expense. Their position is that they don't want any signs of a dangerous product on site. These problems are rare, but they do happen and they're better off just replacing it immediately and investigating the problem on the back end. I guess that's what you can expect from the premium product lines.

--Jon Chuchla--

Sent from my iPhone using Tapatalk

**Jon** · March 11, 2016, 10:17 AM

Well it took 5 days to get a response.... But it's positive. They're going to replace the switch for free despite its age. I submitted the service ticket using only the email support method. The subject line was simply "fire" which I'm sure helped to get their attention. They asked for photos and the serial number. I sent all of the photos I posted here, including the ones where I disassembled it I annotated the obviously fried parts and included my commentary that it still worked mostly and gave my educated guesses as to why it still partially worked with the blown components.
They informed me that I purchased it 11 years ago and it's well out of warranty. But that they are going to replace it anyway since I went out of my way to bring it to their attention with all of the detail (and I'm sure to avoid bad press)
I also got an email from the smartlabs engineering team thanking me for the detailed report and to tell me that the component BOM on the newer versions includes additional protection to avoid such failures. They're not asking for me to ship the bad one back. So I'm probably going to try and reverse engineer it to determine the appropriate replacement component values.

As a side note, In the disassembly process, I also looked at the logic components. It's actually a pretty simple design. I found that the EEPROM is not locked. I was able to suck the memory contents out of it. I'm really tempted to try my hand at analyzing it and writing my own firmware for it to adjust the behavior to take care of some of my wish list items.

--Jon Chuchla--

Sent from my iPhone using Tapatalk

Announcement

Replace Hub not working correctly

Replace Hub not working correctly

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment