elvisimprsntr

Michel explained this a number of posts back: they are there so you can say, for example, IF Thermostat Cooling is On .... I'm not sure why that couldn't be just one of the many tests that you could do on the main thermostat status. Edit: Oh, now I understand, you can have put the device in as a controller for a scene so you could, for example, have a light go on when the Thermostat went to Cool mode. Not sure why you would want to do that but it is a capability of the v2.0 thermostats that UDI made accessible to us. I guess having some KPL buttons show you when heat or AC is running might be nice. Not sure yet why anyone would want to add it so a scene either, unless one needs to open a damper or turn on a secondary HVAC device. I'm considering removing the device and using the manual "add insteon device" method, which I did initially and didn't create 4 entries. I had less issues that way.

I sent UDI support an updated test results matrix that inlcudes log artifacts in case you need it. In short, FS is incorrect in ALL modes upon power up or manual query. SPs are incorrect in program modes upon power up or manual query. Elvis,

1. Regardless of the fact the tstat is not queried when first added, once power is cycled or the isy is reboot, the ISY does not restore the FS in any mode and SPs in program modes. 2. In program auto mode, when I perform a manual query of the tstat, I only see messages for ST, CLIMD/SP/HUM and do not see CLIFS/SPC/SPH. 3. In auto mode, I see query messages for ST,CLIMD/SP/SPC/SPH/HUM, but not CLIFS 4. I do not see where these states can be queried individually in programs. Only query as a device. It appears to me that not all values are queried in all modes. Elvis

OK, I retested everything after using the start linking method. The significant issues I noticed are: 1. Fan state is now commanded every time a mode change is made. This leads me to believe that CLIFS is not an item that can be queried. Unfortunately, upon power up, fan state is not correctly reported in any modes. 2. Set points will be zero upon power up and even after a query in any of the program modes. Thus this leads to confusing and misleading information in third party apps like eKeypad ISY and iLinc Pro the way it is currently implemented. The question is can the ISY query CLISP,C,H values even in program modes? 3. Wasn't fan mode to be removed? Questions If this is the way it works given some technical limitation, then is the work around to execute a program upon power up to: 1. Command the mode to auto and fan state to auto upon power up at least once, then set the mode and fan to your preferred states to get the ISY and tstat to sync up? 2. Or is there a way to query/report the CLIFS, CLISP, CLISPH, CLIPSC values during a query upon power up and/or when mode changes are mode? Any other ideas? Thanks, Elvis

D'oh! I added my 2.0 adapter using the new insteon device method and manually entered the particulars. Now that I used the start linking method, I also see the four entries. Ugh! Now I need to retest everything! Elvis

A significant improvement in the tstat inteface! Just completed an extensive matrix of tstat 2.0 adapter testing with 2.7.8a. I did not create programs that use tstat state values. I will email the complete results/artifacts to UDI support. Summary of significant findings as follows: 1. fan mode not correctly reported and never queried. 2. Setting fan mode removes heat/cool set points from interface. Fan turns on as expected, but changes tstat to auto mode. Manual query of tstat reports heat/cool set points and mode as auto. Humidity is incorrectly reported as cool set point value. Second and subsequent manual query humidity reported as correct value. Manually set mode to off. Subsequent manual query reported mode as fan mode. Confirmed tstat in off mode and fan running. 3. Manually changed mode and fan state, then rebooted ISY after last test. Current temp, humidity, and mode are correctly reported. Fan mode is incorrectly reported as ON. Set points are zero. Switching to auto mode then back to program auto mode, set points are properly reported. Questions/Observations. 1. The failure to report set points affects applications like iLink Pro and eKeypad ISY from properly reporting set points. It seems like there are three different set points CLISP, CLISPH, CLISPC which contain stale values depending on which mode the tstat is in. This results in confusing and misleading information being displayed in iLinc Pro and eKeypad ISY. Perhaps the stale and/or inappropriate information should be cleared based on which mode the tstat is actually in. 2. I did see intermittant incorrectly reported humidity values, but problem does not repeat consistantly only in program auto mode as with 2.7.7a. (Read TStat 2.0 Adapter - Humidity Problem thread.) Not sure if this eliminates the 2.0 adapter as a suspect or not. 3. Can CLIFS be queried? 4. Can the stale CLISP, CLISPH and CLISPC be cleared when not values not appropriate based on mode? 5. I thought I read somewhere the fan mode option was planned to be removed. Elvis.

You need to send a note to be added to the alpha release notices. Read release notice at top of this thread. I think I read that you need to remove and re-link the tstat adapter. Elvis

OK I stand corrected. I can no longer use the ElkRP applicaiton to log into my ELk M1 Gold. I have had no problems until I upgraded to 2.7.7. The error message i get is "Cound not initialize secure connection." Once this error occurs, the only way i can clear it is to reboot my Elk. I am reverting back to 2.7.6 which I have not have any of these problems before. UPDATE: Well it appears to be a conflict between Windows MCE (and no I don't have the MCE plug in installed) and the ElkRP application. When I an watching TV via MCE and trying to run the ElkRP applicaiton, I get the error message mentioned above. I'm going back to 2.7.7 to re-produce the problem. UPDATE2: Problem duplicated with 2.7.7 and conflict with MCE running. Don't run MCE when trying to run ElkRP application.

I'm trying to download the weather module and keep getting kicked out of the checkout process. It's not a problem with my account. I have had no problems using google checkout before. I give up! Oops! You are currently signed in to a Google Checkout account that does not have permission to perform the specified action. Please sign out of all Google Accounts, and then sign in to the appropriate Google Checkout account before retrying the desired action.

in my isy99i the version number is 2.7.7

Been running 2.7.7 alpha for a couple of days, interfacing using iLinc Pro and eKeypad ISY. Also acceing via the admin console. Once significant change I have noticed is the Controller/Responder and Manages/ManagedBy associations tree make a lot more logical sense now. Keep up the good work! Elvis