upstatemike

I have 3 Nest thermostats and like the look but otherwise am not entirely thrilled with them so have been researching Lyric and Ecobee3. At the end of the day it seems all of the nice looking designer thermostats rely too heavily on external Internet connections to provide core features like operating them from secondary locations in the house. (I have some trouble negotiating stairs and it is a big deal for me if I have to go to a different floor to adjust the thermostat because the Internet connection is down.) I used to use RCS serial thermostats connected to a Stargate controller which worked reliably but were not very attractive. In the end I suspect I'll end up going back to serial stats.. maybe HAI thermostats with remote display controllers on each floor. At least these can be connected to an Elk M1 and will not have any dependency on Google or the Internet.

Will the UDI PLM have a larger link capacity than the Smarthome one? Will it have a faster processor so it can find matches in the table faster?

Thanks but this is a controlinc not remotelinc. Ended up manually linking it to an appliance moduel then reading the link table to discover the new address.

Once again am having a Controlinc challenge... This time I pulled a spare off the shelf to replace a failing unit and discovered there is no address label on it. How do I "discover" the address on a Controlinc?

I'll give that a try eventually but for now I just dug out an older version ApplianceLinc and used it from the same location with no issues at all.

Update installed OK but tried to install an ApplienceLinc afterwards and had a lot of trouble discovering the module. Then lots of trouble adding it to a scene and had to hit "write updates to device" several times to get it to complete. Tried in several locations so I don't think it is a signal issue. ApplianceLinc sticker says rev 4.6. but forgot to note the firmware before I deleted from the module from ISY in frustration.

Interesting observation. I will retry with fresh batteries and see if that helps.

I had similiar issues in updating to a 2413S and spent a similiar amount of time working on it. Unfortunately I still have some motion sensors that do not work right even though I have removed and added them each a couple of times. Finally just ran out of time to mess with it. I think there is a post from a couple of weeks ago that talks about the best way to do a PLM restore if you have a lot of battery devices but it was too late to help me. Also a lot of scenes stopped working and I had to delete them and create them over again. I think that over Thanksgiving I might wipe the ISY completely and add everything over again, one device to a time, to see if that cleans things up once and for all.

Thanks for the examples. It takes about 15 minutes for the "all devices" query to run at 3AM so I will have to make some guesses about the timing for doing each scene separately with a pause in between. I don't really care about the system load. I would be happy to completely give up ISY's ability to control stuff in trade for truly accurate status.

I need some help writing a query program to keep the device status of my system up to date. What I want to do is write a program that does a query on all devices in my system, similiar to the 3AM event, except I want it to pause for a few seconds after each query to allow for regular traffic from programs and cotrollers. I also want it to start over as soon as it finishes so every device is rechecked every few minutes. Any thoughts on the best way to approach this?

I'm curious what this would mean should you be given the green light to proceed. I'm assuming one would need to purchase a new ISY with the chip included in order to get the functionality? I am happy to buy a new super PLM or even a new ISY if required. I have enough issues now, and they seem to be geting worse as I add devices, that I would embrace any solution that solves the scalability problem.

What is this about? I don't remember seeing this documented anywhere.

Wouldn't that node automatically get a query each night during the 3AM polling process? Is the manual step really needed?

If you can't find the directions to configure the OFF button manually it is as follows: 1. P&H (press and hold) large ON or OFF button for 10 seconds, putting it into linking mode. 2. P&H for 5 seconds, putting it into unlinking mode. 3. P&H for another 5 seconds until LED's stop blinking Now the OFF LED will not illuminate when the local load is OFF. To undo, just 10-5-5 it again. Hope that helps,

I currently have 878 links in my PLM and am concerned about this stability issue, particularly since I want to expand my system. What is the long term resolution to this limit?

Not sure if it is worth creating a special build based on such a small amount of information. Maybe it would be better for me to create a bunch more Insteon triggers in Homeseer and see if I produce additional anomalies. Maybe the fact that the trigger is a ControLinc button rather than a SwitchLinc button is not significant? I have 2 ControLincs and a RemoteLinc controlling these same lights. Might be worthwhile to put different responses on each buttton and then watch (actually listen) for errors over an extended period of use? Then if a pattern emerges we can decide what the next steps should be. Plugin is 1.0.1.5 Beta and ISY Firmware is 2.7.12

When button 2 is pressed it always controls the correct lights and does not trigger the button 1 lights. No, I cannot get it to happen again in a reasonable amount of time. Usually many days between incidents. Hitting the button many times in a row does not trigger it. Button 1 controls a single lamp. Button 2 controls 2 appliancelincs. ISY Device Trigger = When Office Desk 1 sends ON (Office Desk 1 is button 1 on the ControLinc)

I am using the ISY plugin for Homeseer and it mostly works fine except for 1 intermittent bug. I have a ControLinc on my desk and I use Homeseer to speak a confirmation everytime that ControLinc's button 1 ON is pressed. This works fine but sometimes when I press button 2 on I will also get the spoken confirmation message. Since it is intermittent I am having a hard time figuring out where the problem is: 1 - I know the ControLinc is sending the correct code because the linked lights operate correctly 2- The PLM could be hearing the correct code but incorrectly reporting it to ISY. Unfortunately when I look at the ISY log there is no record of the event at all. 3- ISY could be getting the correct code from the PLM but incorrectly report it to Homeseer via the Ethernet interface. Unfortunately the Homseer log just shows that the event to speak was triggered without identifying the trigger. 4- Homeseer could be getting the correct code from ISY and be incorrectly triggering the event due to a bug in the Homeseer plugin. Again no clues in the Homeseer log. Since I cannot force this intermittent problem to repeat at will, anybody have an idea how I can troubleshoot this?

I think you are in good shape, misssing both the paddle problem and the v.35 problem.

My understanding was that both dimmers and relays were affected.

Yes, the complexity is in programming. Once the links are in place Insteon is always more reliable than X-10. The problem is that you first have to configure the links and if you do that through programming you have more risk of being impacted by power line issues during the process. Folks often unfairly compare the communication they had with simple X-10 on/off commands to the communications problems in Insteon remote programming and claim X-10 was just as good or better, when in reality they are comparing apples to oranges.

If you do not have any issues on your powerline then having more devices will definitely improve reliability by virtue of the signals being repeated and this should more than compensate for any additional loading. If you have noise, or signal sucker loads then the signal repeating might not be enough to maintain reliability and you might need to use some filters or access points for reliable communications. If things are borderline then simple switch activation might work fine while more complicated activities like adding modules or creating scenes could generate errors.

All devices repeat in parallel in the same time window so the signals do not interfere. In a given time slice (position on the 60Hz sine wave) there will either be a signal or there won't. Does not matter if that signal comes from 1 module or 70 in parallel. X10 modules are usually only receivers so they do not load down the power line and they send much simpler messages. All Insteon modules are both receivers and transmitters so each one lowers the impedance of the power line which impacts signal strength. Also when links are being programmed (not an option with X-1o) there is a fair amount of data being exchanged so more opportunity for a bit to get dropped and the message lost.

1. yes - although they might not all see it on the first hop, but all that do will repeat it. 2. This is where the tightly defined broadcast window comes into play... as long as they are in sync it is not a problem. (Maybe this is what went wrong with v.35 switches?) 3. Repeating does not help overcome serious noise or serious signal suckers. If the signal can't be heard over the noise then it can't be repeated. if a sgnal sucker makes it too weak to get very far then it may run out of hop count before reaching its target.

Use the updater in Homeseer to download and install it and it will be in 30 day trial mode. When you are sure you want it, go back to the store and buy it which will just email you the license key to put into the plugin setup page to convert it to a registered copy.