HouseLinc now Free and works with many interfaces.

[Brian H]

Though with an ISY interface most will have no need for Houselinc but it has been released as a free program and all model PLMs and some of the new devices like the HUB will now work with Houselinc.

Maybe some would use the diagnostics feature. Though one has to be careful or unknown links to your ISY maybe a problem.

http://www.smarthome.com/houselinc.html

[Vyrolan]

I see this as a sign that more and more stuff is going to be "software only" for configuration. If they offer a free software, it's a lot easier for them to do that. It may be a good thing (more options, less complicated devices, etc) but it may also be a bad thing (more stuff for U-D to implement for each new device).

[LeeG]

Maybe that is the beginning of the end of HouseLinc. SmartLabs never gives things away.

[apostolakisl]

They give away the base program to get people using it which wets the appetite for some add-on modules that cost $.

 

Or similarly, they use it to wet the appetite for some other hardware as alluded to by Vyrolan.

 

Wonder what they tell the folks who have just recently paid money for the program?

[TJF1960]

Wonder what they tell the folks who have just recently paid money for the program?

I for one would be pretty upset if I had paid for a copy and now suddenly its free!

[Brian H]

Maybe it will be like the older Smarthome Manager for the 1132CU X10 controller.

The Essentials version was free and the Plus version with added features was an extra cost item.

[ELA]

It is interesting that it will now work with other PLMs such as the 2413S.

I had always thought it would make a nice diagnostic tool addition for an ISY based system. A way for people to reliability test by collecting statistical data.

 

However as you stated Brian and as LeeG had cautioned me on once before, you have to be very knowledgeable and careful if running on the same system that the ISY has designed and maintains links for.

 

I am curious as to when it became compatible with the non"H" version PLMs. Did the change possibly include some easy to use option for "diagnostics only" such that you could use it without possibly corrupting ISY established links?

 

 

 

 

LeeG,

Since it now supports the 2413S could a person disconnect the ISY from its existing 2413S (mate) and connect the existing 2413S (ISY mate) PLM to houselinc. Then run only diagnostics using houslinc without corrupting anything for the ISY?

 

I ask since a person would be using the very same PLM that the ISY normally uses and therefore I would not expect houselinc to want to establish any new links unless told to do so?

 

Or would this still be a very dangerous procedure. I know nothing of Houselinc so I do not know what it may want to do automatically?

[LeeG]

ELA

 

This is only guess work as I have not tried it with this 'free' version but I suspect HL will not run diagnostics on devices which it does not know about. This means defining the devices to HL and ISY. Using the same PLM may only result in duplicate link records in the PLM but may result in duplicate links in the devices which is not a good idea. The devices use standard Scene (group) protocol which will result in duplicate Group Cleanup Direct messages if duplicate link records are created.

 

A user on the Smarthome forum noted he had been using a 2413S with HL for some time. Only needed the 2413SH for the initial HL install where licensing was established. Once that part was complete the rest of the PLM interface is the same and apparently HL did not check license information past the install.

 

I think it will take a brave person who is able to recover the ISY environment to try the HL/ISY combination. Document the issues and how to recover before folks jump into using HL for the diagnostics.

[arw01]

ELA

 

A user on the Smarthome forum noted he had been using a 2413S with HL for some time. Only needed the 2413SH for the initial HL install where licensing was established. Once that part was complete the rest of the PLM interface is the same and apparently HL did not check license information past the install.

 

actually that was me and I think it was around here. I've had 2 plm's plugged into my house for months, either of which I would use with HL depending if I was on my laptop or desktop, and mainly running a Misterhouse instance (the 2413sh).

 

When I got the ISY, I ran on the S2413 I used with the laptop and left misterhouse running. This went on until I was messing with the RL2 and shut down Misterhouse to rob the plm to use to diagnose the issues with the laptop version of houselinc.

 

I never encountered any issue with the ISY and the other PLM while doing that, so I think you are just fine. Both the ISY and houselink require you link the devices for them to interact, but the logs work just fine without pieces being linked.

[IndyMike]

This thread caught my attention and I finally got a chance to circle back...

 

I had tried HL in the past with my 2413S and it refused to recognize it. I would only recognize my 2413UH that I purchased with the software. I use HL expressly for diagnostic purposes.

 

• [*:1ssl2eyz]Connected my 2413S V.99. HL Version 2.9.27 (released 7/10/2012) would not recognize the PLM on Com1. I could communicate with the PLM using the Busyrat tool.
  [*:1ssl2eyz]Upgraded HL to 2.9.59 (Current version). HL detected the PLM and I was able to control devices previously linked with the 2413UH PLM. In short, success.
  [*:1ssl2eyz]There is nothing in the release notes to indicate that HL was upgraded to support the non "H" version PLMs. Version 2.9.52 (released 11/21/2012) does appear to be a somewhat major update - but that's a total guess.

 

The diagnostic tools appear to be fully functional with the 2413S. The software doesn't "indicate" that any of the functions are disabled.

 

I am particularly interested in determining whether the HL software has the ability to "disable PLM retries" as indicated by the checkbox. I've verified that this does work on the 2413UH PLM and thought that it was an added feature of the "H" package. Unfortunately, I cannot determine from the logs whether this is working with the 2413S. I plan on pulling out the Oscilloscope this weekend.

 

If there are other requests, please post back and I'll try to fit them in.

[arw01]

I had not found that option in there myself!

 

What exactly are the PLM retries? Like when it's programming and it gets no ack, or if it's signalling a device that is no longer on the network or something else?

 

There was a message elsewhere on the board about forcing the PLM to use RF vs power line all the time, so with the oscilloscope could you check if the plm will only try to use the power line when a signal is weak and not send both the rf and the powerl ine all the time?

[ELA]

I think it will take a brave person who is able to recover the ISY environment to try the HL/ISY combination. Document the issues and how to recover before folks jump into using HL for the diagnostics.

 

Hello IndyMike,

I wonder if you could be the brave person that LeeG mentioned?

 

It would sure be nice if the average user could disconnect their ISY based 2413S serial cable, and plug a serial cable from that PLM into a HL serial port for diagnostics, without worrying about corrupting anything in the PLM or devices with regard to ISY operation. ( once they reconnected the PLM back to the ISY).

 

I am curious as to your "retry disable" result using the non "H" version PLM.

[IndyMike]

I had not found that option in there myself!

Click on "advanced options" on the Signaling Diagnostics screen.

What exactly are the PLM retries? Like when it's programming and it gets no ack, or if it's signalling a device that is no longer on the network or something else?

Correct - PLM retries are used for direct transmissions if the PLM does not receive a ack. The PLM will increase the HOP count by 1 (up to a max of 3) and retransmit the message up to 5 times. PLM retries are invisible to the ISY. They are not used for ISY scene control because the ISY is not requesting an ack.

There was a message elsewhere on the board about forcing the PLM to use RF vs power line all the time, so with the oscilloscope could you check if the plm will only try to use the power line when a signal is week and not send both the rf and the powerl ine all the time?

If I am thinking of the correct thread, I believe we were discussing using filter(s) on the PLM to prevent the powerline communication from reaching the PLM/other devices. With the PLM plugged into a filter, we are assuming that it is using 100% RF communication. I say "assume" because some powerline signal will make it past the filter. In the past I've used multiple filters to further reduce the powerline signal.

 

I do not know of a method to "instruct" the PLM to not send a powerline or RF signal. I have physically disabled the RF antenna on some units to prevent transmission. I believe ELA found a way to disable the RF section on his custom ELAM module. I have not tried to physically disable the powerline receiver/transmitter. My preference is to use powerline communications since I believe that the PLM has a preference for powerline over RF (conjecture on my part).

[LeeG]

IM

 

Are you going to add the full ISY inventory of Insteon devices to HouseLinc? I would be interested in any issues which develop if that is attempted. Thanks

[arw01]

Why put oneself through the possible pain for the PLM used on the ISY becoming corrupted or something from the houselink.

 

Why not, as I was doing, just use a second PLM for houselinc? If you just want diagnostics you can add only what you want to the table of it. The diagnostics will show anything that comes along the powerline in the logs if you set the level high enough.

 

I never added a couple of motion sensors to misterhouse or houselinc and I could see them on the logs when they fired all the time.

[LeeG]

arw01

 

The HouseLinc Signal Diagnostics uses the devices defined to HouseLinc. When a device is added to HouseLinc, just as with the ISY, link records are added to the device to point to the HL PLM so that HouseLinc is aware of device activity which can be used to trigger HL events. If a separate PLM is used with HL that is not powered all the time the device will try to communicate with a PLM that is not responsive forcing device retries. Even if the HL PLM remains powered the ISY is not aware of the link records HL created in the device(s) so they will eventually be overlaid and/or deleted as ISY manages link records in the device.

[ELA]

There was a message elsewhere on the board about forcing the PLM to use RF vs power line all the time, so with the oscilloscope could you check if the plm will only try to use the power line when a signal is weak and not send both the rf and the powerl ine all the time?

 

My test device can enable/disable the RF section at will. While it would also be fairly easy to add a program controlled switch to disable the power line transmissions I elected not to in favor of using dual Filterlincs to isolate from the power line when testing.

 

I am also able to measure the RF signal strength emitted from a device. Based on measurements I have taken I have not seen where the PLM makes a decision to purposely engage only one mode of transmission based on signal strengths. In other words in my experience it sends via both during each message exchange.

[IndyMike]

I think it will take a brave person who is able to recover the ISY environment to try the HL/ISY combination. Document the issues and how to recover before folks jump into using HL for the diagnostics.

 

Hello IndyMike,

I wonder if you could be the brave person that LeeG mentioned?

Brave? Absolutely not! I use HL in an extremely limited fashion and I really am not well versed on the "synch" features of the software. It has burned me in the past.

 

I am also using the "registered" version of the software. I have not idea whether the "free" version is the same. The link does indicate the same release notes. I'm rather hesitant to try installing the "free" version on my automation PC and I don't have another old dog PC with a serial port.

 

It would sure be nice if the average user could disconnect their ISY based 2413S serial cable, and plug a serial cable from that PLM into a HL serial port for diagnostics, without worrying about corrupting anything in the PLM or devices with regard to ISY operation. ( once they reconnected the PLM back to the ISY).

 

This I have not tried. If I understand your desire, you would like to create a duplicate HL setup of all linked devices using a common PLM. I have never used my primary ISY PLM (a 2412S) to link devices with HL. I have setup a "mirror" system on a spare PLM (2413S) and then swapped PLMs between the systems. Problems:

• 
  [*:2bmwstpp]Turn off all device synch in HL. I'm not sure how effective this is, but syncing will reconcile links between HL, PLM, devices (i.e. totally screw up your system). I've had problems with this being "re-enabled" after software updates and the normal thumb-finger on my part.
   
  [*:2bmwstpp]When linking a new device, HL will add links to the PLM. This is the reason I use a spare unit. I don't have the time/patience to restore my PLM after linking units. There is no way that I would use my primary unit to link modules with HL. It scares me.
  [*:2bmwstpp]When initially linking a device to the spare PLM, HL will write links to the device. I simply restore the device afterward with the ISY thereby eliminating the links. The devices do not require these links for the diagnostics package to function (direct commands). Note: This may not be true for I2CS device - I haven't tried them.
  [*:2bmwstpp]When linking a new device, HL will add links to the PLM. This is the reason I use a spare unit. I don't have the time/patience to restore my PLM after linking units.
  [*:2bmwstpp]Once you have the "software configuration" for your units, the PLM table doesn't matter - as long as you are only interested in performing diagnostics. The diagnostics package used direct messages and PLM links are not required (again, this may be different for I2Cs units). With my older units, I can factory reset the PLM and still run diagnostics on all of the units loaded into the HL "software configuration".
  

 

Not sure if that answers the question, or meets the need. Again, I am very hesitant in putting this forward. If you make a mis-step, you will be performing a system restore on the ISY. MAKE ABSOLUTELY SURE YOU HAVE A BACKUP.

 

I am curious as to your "retry disable" result using the non "H" version PLM.

 

The "retry disable" does function correctly on non "H" version PLMs (verified through the HL log and Oscilloscope). This turned out to be "stupid simple". I say stupid, because that's exactly how I feel for having overcomplicated this feature.

 

The "retry disable" is actually built into the protocol. The following is a ping transmission to one of my devices at 16.5C.7F:

02 62 16 5C 7F 00 0F 00 (retries on: Flag 00 indicates a direct message, with max hops 0 and 0 hops remaining)

02 62 16 5C 7F 20 0F 00 (retries off: Flag 20 indicates a ACK message, with max hops 0 and 0 hops remaining)

 

Apparently, by setting the "ACK" bit in the message flag the PLM disables the retries. Make sense since you don't expect a response to an ack transmission.

[ELA]

Interesting information on the retries disable, thank you IndyMike.

 

I have my own communications reliability tester so I am not interested directly in HL. Just always looking for a method for others to be able to use to get good statistical information to help them maintain their installs. Not having ever used HL I was interested in whether a person could simply use the existing links data base already installed in their their ISY based PLM by connecting it to HL without corrupting it.

 

From what you wrote I got that the "sync" feature should be turned off.

There would be no intention to create any new links via HL. Only run diagnostics on devices already in the PLMs data base. AS soon as diagnostics testing were done to disconnect HL and reconnect the PLM back to the ISY.

 

If I understood correctly you could configure one device at a time in HL for diagnostics. Since it uses direct messages it should be able to test any device. Since the PLM already contains all required links, even i2CS devices should ack a direct message.

 

Sounds like it could work as long as you make sure the "sync" function is not enabled? But still possibly dangerous if you forget about making sure "sync" is not disabled each time you use it?

Your having said you were burned in the past is enough for me to avoid any recommendations for casual users.

[IndyMike]

Interesting information on the retries disable, thank you IndyMike.

If I understood correctly you could configure one device at a time in HL for diagnostics. Since it uses direct messages it should be able to test any device. Since the PLM already contains all required links, even i2CS devices should ack a direct message.

 

ELA,

I do not believe the above will work without writing links to the PLM and devices. Like the ISY, HL has a software device Tree with knowledge of the links that "should" be in the PLM and devices. Again like the ISY, the HL software must have knowledge of the connected device types, addresses, etc.

 

If you connect a ISY configured PLM to HL (without configuring the units) you will have a blank device tree. You'll have intact device link tables, and PLM tables, but no software table. When you do link the devices in software (similar to linking a new device with the ISY) both the device and PLM link tables will be altered.

 

I'm willing to alter the device link tables because I can easily recover them using the ISY. This, by the way, is a testament to the fantastic work that the Universal Devices team has done in configuring the ISY.

 

I am not willing to use my ISY PLM to link devices in HL and thereby modify the PLM tables. This would require a PLM restore. The UD team has made this as painless as possible, but with my devices numbering around 100, it's still more than I'm willing to risk. This is why I use a separate PLM.

 

Once the HL software is configured, the PLM links don't matter (again, for diagnostics only). The tree below shows what I currently have loaded into HL (40+ devices). I can use the diagnostics to poll all of the devices even though the PLM has been factory reset. The software retains the necessary configuration. Likewise, after the software has been configured, I can connect the ISY 2412S and perform the same diagnostic tests.

 

The above may all fall apart when trying to use I2CS units. I have a working understanding of the requirements, but have not installed one as yet. If I get a chance I'll try wire nutting one of my new I2CS units to a cord to check things out.

 

Sounds like it could work as long as you make sure the "sync" function is not enabled? But still possibly dangerous if you forget about making sure "sync" is not disabled each time you use it?

Your having said you were burned in the past is enough for me to avoid any recommendations for casual users.

 

Disabling the "synch" function is easy. Keeping it disabled can be problematic. I was burned by a software update that restored the "synch" function to it's default state (ON!). I realized that HL was synching the units/plm and powered down the PLM before too many units were affected. The latest update (today) did not reset settings to default.

 

Regardless, I would classify this as an option for more advanced users that were comfortable with the usage of both the ISY and HL.

 

I hope the "PLM retry disable" proves useful for you. It has for me. It's the only way that I know of to truly check powerline efficiency. Of the 40+ units that I have loaded into HL, only 3 fail to respond 100% with 0 hops and retries disabled. 2 are known offenders (older KPL's). The third was a surprise this morning - a newer SWL. I need to check loading in that location.

[IndyMike]

IM

 

Are you going to add the full ISY inventory of Insteon devices to HouseLinc? I would be interested in any issues which develop if that is attempted. Thanks

 

Hello Lee,

 

To be honest, I was not planning on expanding the HL configuration past the 40 something units that are currently configured. I use it mostly for testing and setting up "experiments" with my oscilloscope. It's very nice to be able to set the diagnostics to loop on a particular unit while configuring my oscilloscope.

 

If someone has specific questions regarding a particular module, I'll try to oblige. I have a good selection of older units (wired) but very few I2CS (not installed) and no thermostats.

[arw01]

Indymike,

 

Thank you for your testing. I happen to have an older keypad that the ISY994 immediate returns an error when I try to change the LED brightness of the KPL.

 

I am curious if your older KPL return the same error.

 

[LeeG]

IM

 

Thanks for the update. I've been following the posts with great interest and agree completely with the conclusion this is for those who are familiar with HL and ISY. I’m pretty familiar with the pitfalls and have still made some careless mistakes that have caused headaches. I would not define my main house devices in mass but might pick a few scattered around to get an idea of how well things are actually working. I was hoping you (or someone) had some secrets to defining devices to both platforms without impact but I don't see that happening.

 

Setting the ACK bit in outbound messages was new information for me. Thanks for that insight. I'll bet there are other tidbits of information that could be useful if SmartLabs would release all the confidential information.

[LeeG]

arw01

 

I get that on my v.29 KPLs. The early KPLs supported LED backlight adjustments using the KPL buttons but had no programmatic interface. Do not know at what KPL firmware started the ability to adjust with a program.

[arw01]

arw01

 

I get that on my v.29 KPLs. The early KPLs supported LED backlight adjustments using the KPL buttons but had no programmatic interface. Do not know at what KPL firmware started the ability to adjust with a program.

 

Thanks Lee, I set them down as low as I could get them on the kpl manually now. Thinking I have the really old kpl in that box, they just toggle, which puts me at 1.4 or before I assume from the manual.