MWareman

I don't know what's available, but I would think that as far as irrigation goes a program could be along the lines of "if soil is dryer than xx, then begin irrigation cycle" - subject to time of day and day of week restrictions. Basically, a way of suppressing the irrigation cycle if a soil sensor reports that the soil is damp above a certain level. Likewise, if VERY dry, have the ability to extend the irrigation cycle maybe. It would allow for the dependency on the weather module to be dropped. In my case, the nearest weather station does not provide rain fall data - so I have to go further away. I get rain data, but its very wrong for my rain fall. So, my irrigation requirements are necessarily very wrong when calculated just from the climate module. The system needs the feedback to close the loop. It would be *awesome* if there was, say, a Z-wave or wifi enabled weather sensor package that would pipe weather data directly to the ISY... Not sure if a) something like that exists or if the ISY could use such data.... I do know, I could get one and run software on a separate system to send my data to Weatherbug, then set the ISY to use *my* station, but that a lot of stuff in the loop if a sensor package can just send directly to the ISY. Lots of other 'enhancements' I'd like to see regarding irrigation if we are on it.. (Forgive me - just spent the last couple of days learning about this function...) My local ordinances require irrigation to only happen on odd or even days, depending on the address. I've managed to setup a variable and program set to do this, but its a heck of a kludge. I would think the calendar functions in the ISY should be extended to provide as many of the common timing possibilities to the system. Odd days, even days, every second Tuesday, third tuesday of each month etc etc.

I do agree with the 'anything that pops up' mentality. I get that. Perhaps something more generic though. The UBE is a generic network device. I realize there is no published API yet - but how about this in concept. I would like to know more about your statement 'Perhaps Ube can integrate with ISY which is should be quite easy.'. How would one integrate a third party device like this, assuming a REST API is available, such that it is a first-class device in the device tree? Michael.

Ube..... Michel - PLEASE say its so. Especially integrating the power metering capability of the devices. No special hardware needed, just an API on the device.

Possibly a sensor that directly measures soil moisture to optionally feed the irrigation module? Maybe several sensors - one per zone? Hoping.... I know.. Future plans etc... I'm just getting into irrigation now - getting my sprinkler heads, rpz and valves installed in a couple of weeks once my permit comes thru. Planning my programming now - seems there is more to this that I thought. Michael.

How did you do that? I've been trying, but nobody at Smarthome has been able to point me to the setting.

All sounds entirely reasonable to me. Thanks for clarifying that the documentation and advertisement will be corrected to be in line with the experience. I will say I would have added at least one more - had I not 'accidentally' discovered that PRO fixes the 'limitation'. At that point in time, I had spent several hours troubleshooting and finally setup a local HTTP-to-HTTPS proxy to work around it, thinking the SSL client in the ISY was just broken. I never got round to actually reporting this as a 'problem' because I was going to dig in and troubleshoot further before reporting it, and I had a workaround that was working for me. I still do submit that logging this as a 'timeout' in the event logs is hiding the issue. It should be logged as a 'Crypto Failure' - "I tried to connect but the server offered no crypto that I could agree to". Perhaps this can go in 4.x? Best regards, Michael.

I contend still that stating that the networking module supports HTTPS without qualifying that its crippled without PRO is what is confusing. I would rather you remove that entirely or outright state that for functional HTTPS support you need to also have PRO. Maybe even disable HTTPS support altogether from the Networking module unless installed on a PRO unit. The error you get when connecting to a URL that wants a stronger crypto than the standard unit can do is extremely confusing. It's currently logging a timeout. It should log a crypto failure. To me - that's the bug here - is logging an irrelevant error and not logging the real issue. Saying now that use of HTTPS in the networking module is intended just for LAN use is a very 'odd' position to take given the usage examples provided on the wiki and other places. Very odd indeed and not something I can really wrap my head around. Nothing in the Network Module documents implies that it's intended for LAN use only - that's just a limitation that I (for one) and many others (given the feedback I got to the wiki article I wrote about notification via NMA and Prowl) perceived. If fact quite the opposite. Why would you implement timeouts on the networking module connecting to URLs that go up to many seconds long - if not for the intent to access resources over latent networks (ie: outside of the LAN). Frankly - why even implement DNS in the networking module - since if all devices are inside the LAN that shouldn't be necessary. Web services on the LAN should have fixed IPs or DHCP reservations, no need to add complexity with DNS on the LAN. How many people run split-dns on their home networks? Many design decisions within the ISY product itself and the networking module in particular seem to make the opposite statement - is was intended to work to access resources on the LAN and the WAN. Anyway, I've said my piece now. Really - you can choose to license however you see fit. For my personal needs - I needed the PRO upgrade and the networking module. I am sure you get frustrated though troubleshooting issues like this - where people continue to purchase the networking module and only when they try to use it to call public REST APIs on most cloud providers find out they also need PRO as well due to the crypto limitation.

Perfectly acceptable. Again - perfectly acceptable. This is me - and the answer is 'Because I need to be able to connect TO the most possible remote HTTPS services to actually USE the networking module. I, as ythe customer, don't have control over the cipher suites those servers need. To restrict the cipher suites the HTTPS client can connect to simply means it cannot connect to most HTTPS destinations. That the situation people are finding themselves in with Pushover. I 'needed' PRO for the batch functionality. I didn't think I needed it to un-cripple the Networking module. Your advertising for the networking module does not make that clear. To be - there are two possible 'solutions'. 1) Bundle the PRO upgrade with the Networking module. Don't allow the purchase of the 'Networking Module' on non-PRO units. 2) Allow the Networking module to access strong crypto without PRO - just restrict strong crypto for the HTTPS server running on the ISY. I guess there is a 3) as well - you should warn purchasers of the networking module that they cannot connect to HTTPS at all if the HTTPS resource requires strong crypto unless you also buy the PRO upgrade. Michael.

Upgrading to 'PRO' adds the cipher suites as well. That's just a license addition - no additional firmware 'space' is added with the PRO upgrade. I doubt very much firmware space is the underlying reason.

More info for everyone. One resource that works, prowl. On a Ubuntu host, I have tested the SSL suite compatability: echo -n | openssl s_client -connect api.prowlapp.com:443 -cipher RC4-MD5 CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/serialNumber=JuOmlkd8/PwBVhskrT8v-p/w5eCFiUy9/OU=GT53872656/OU=See www.rapidssl.com/resources/cps (c)13/OU=Domain Control Validated - RapidSSL(R)/CN=*.prowlapp.com i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA 1 s:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- Server certificate -----BEGIN CERTIFICATE----- MIIFMDCCBBigAwIBAgIDCeLOMA0GCSqGSIb3DQEBBQUAMDwxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEUMBIGA1UEAxMLUmFwaWRTU0wgQ0Ew HhcNMTMwMTAxMTkyNDMwWhcNMTYwMzA0MDY0NTE2WjCBvTEpMCcGA1UEBRMgSnVP bWxrZDgvUHdCVmhza3JUOHYtcC93NWVDRmlVeTkxEzARBgNVBAsTCkdUNTM4NzI2 NTYxMTAvBgNVBAsTKFNlZSB3d3cucmFwaWRzc2wuY29tL3Jlc291cmNlcy9jcHMg KGMpMTMxLzAtBgNVBAsTJkRvbWFpbiBDb250cm9sIFZhbGlkYXRlZCAtIFJhcGlk U1NMKFIpMRcwFQYDVQQDDA4qLnByb3dsYXBwLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALM3AYr21gqMbIFV6/+w+MZEypZu8V4kUsO/+vhdje8Y Yy7kGp8DiO/6MnqPaToR+Fdwk348J3JRnXPHHkUuZROr11EfNUCGQsTwGZQ+0wM2 Ra3x678cTeQxTmEzkzJ7QM5sBCE2TwU90yEB6FMS1k8ny3hRJpFglPrPRyRa9RoL /XQCl4dNjoVpz4TuVagwZgOOBx6We8tnseW5sbIG6iuDuqjDzYqGdSuUwiD1hleM BsN3HJHRg2gV8AWdul9bbk2KN1xGogNDDTtlTjKpmJUoo1lSLYePFw/tqmNXKNIj cN2+0+YFkDwV6w50nyVJYtr/KiGQk5sacLB8dAe4/o8CAwEAAaOCAbcwggGzMB8G A1UdIwQYMBaAFGtpPWoYQkrdjwJlOf01JIZ4kRYwMA4GA1UdDwEB/wQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwJwYDVR0RBCAwHoIOKi5wcm93 bGFwcC5jb22CDHByb3dsYXBwLmNvbTBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v cmFwaWRzc2wtY3JsLmdlb3RydXN0LmNvbS9jcmxzL3JhcGlkc3NsLmNybDAdBgNV HQ4EFgQU3M32nHXaGsj+FKSbcKrhWsv2HWYwDAYDVR0TAQH/BAIwADB4BggrBgEF BQcBAQRsMGowLQYIKwYBBQUHMAGGIWh0dHA6Ly9yYXBpZHNzbC1vY3NwLmdlb3Ry dXN0LmNvbTA5BggrBgEFBQcwAoYtaHR0cDovL3JhcGlkc3NsLWFpYS5nZW90cnVz dC5jb20vcmFwaWRzc2wuY3J0MEwGA1UdIARFMEMwQQYKYIZIAYb4RQEHNjAzMDEG CCsGAQUFBwIBFiVodHRwOi8vd3d3Lmdlb3RydXN0LmNvbS9yZXNvdXJjZXMvY3Bz MA0GCSqGSIb3DQEBBQUAA4IBAQCQk+iIq1U307L8CdplvL0qCAu5SJGL8FxGccFw OyfRTMCYSUZeM8zsU3eVMBqvWuxoY/Sp1GSz4SD7PyUKE0H2xTeydY7dNd0Msd6i HXY+FJOARjFX8gVVZ82uPSCMT9drb/BMAcF/xMlGECXg2ak+PIbK04PntXmn83HB XWGAMkaREt7q+d7qe35pQ06zO2Fg590pGhnzkbOh2IwZRbYNBn8Z+MB3U4roF4lP E4PuBU7npiHy8E38IJTq79S2puynkhorcC/GPP3iqHcA9+MCSfgdcJQGLTJLehF9 /eF7B8yS+W4Uk14n/4lZ9f3Vb7YQvQL6iPy/ih5U4Axx+DHI -----END CERTIFICATE----- subject=/serialNumber=JuOmlkd8/PwBVhskrT8v-p/w5eCFiUy9/OU=GT53872656/OU=See www.rapidssl.com/resources/cps (c)13/OU=Domain Control Validated - RapidSSL(R)/CN=*.prowlapp.com issuer=/C=US/O=GeoTrust, Inc./CN=RapidSSL CA --- No client certificate CA names sent --- SSL handshake has read 3382 bytes and written 383 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1 Cipher : RC4-MD5 Session-ID: 4BF4093A657111AFD6BB9E8FE6639E9AAFA00823067C1D6EDFD9BB3DCD346B5B Session-ID-ctx: Master-Key: DDF7201B3D6CC192168076675B68B8B1A33126EBCC9916124BAF8452FB08FBA8FBD5050F579177DCFABC5CB6BB1DDC5D Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Compression: 1 (zlib compression) Start Time: 1361379765 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- DONE Success - and explains why the ISY can connect to it. For pushover, the following happens: echo -n | openssl s_client -connect api.pushover.net:443 -cipher RC4-MD5 CONNECTED(00000003) 3073435848:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:724: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 64 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- note the handshake failure. This means the cipher suite is NOT supported - and since this is the only cipher suite supported by the ISY (non PRO) - then you simply CANNOT communicate with the host. I tested with: echo -n | openssl s_client -connect api.pushover.net:443 -cipher AES128-SHA and it was successful. So - so can do SSL with either PRO or standard ISYs to Prowl - but to do SSL to Pushover you must have a PRO version ISY. It was not working for me even with the PRO. That was because I had the SSL client set to 'Low' in the dashboard ('Network' / 'HTTPS Client Settings'). I changed that to 'Medium' and from SSL3 to TLS 1.2 - and my issue with pushover.net went away. To me - advertising generic support for the network module to connect to remote SSL sites is a little disingenuous given that it's something of a crapshoot as to what remote servers you can connect to. People seem to buy the network module expecting to connect to any SSL API. I certainly did. It was only after I purchased PRO (due to batch support) that I realized that all my SSL issues went away. Limiting server side SSL in the standard version to me is fine (I, personally, would still pay for the PRO if I wanted stronger SSL on the ISY itself) - but all cipher suites should be available across both versions from a client perspective. Just my opinion. I hope this info helps at least someone else. Bottom line, to work with pushover - you must have the PRO version of the ISY. It's not a bug - it's a 'feature'. Michael.

I do this for exactly the reason - accessing multiple interfaces from work where only 80 and 443 is allowed out. There is also a forced proxy - and I wanted to securely access various hosts within my home network. I have an internal Apache host setup (Ubuntu) with a wildcard certificate for *.domain.com (in this example) from http://www.cacert.org/. Get Apache working with the cert first and then NAT in port 443. I have a dynamic DNS setup for my external IP. I then use CNAME records in my external DNS (so - if my dynamic dns is 'xyz.no-ip.org' my cnames would be 'router CNAME xyz.no-ip.org' 'isy CNAME xyz.no-ip.org' etc.. If you have a static IP - you could setup a wildcard 'a' record for the IP. So - I can now access my Apache install from the outside with the unique URLs all resolving tot he same IP 'https://router.domain.com' and 'https://isy.domain.com' and I get a valid certificate each time (assuming your remove machine trusts CACert as a root authority). Now - I create a config file for each internal site I wish to publish (/etc/apache2/sites-enabled/isy in this case) like the following: ServerAdmin webmaster@domain.com ServerName isy.domain.com ProxyRequests Off ProxyPreserveHost On ProxyVia On Order deny,allow Allow from all ProxyPass / http://1.2.3.5:80/ ProxyPassReverse / http://1.2.3.5:80/ CustomLog ${APACHE_LOG_DIR}/access_proxy.log combined ErrorLog ${APACHE_LOG_DIR}/error_proxy.log SSLEngine on SSLCertificateFile /etc/ssl/certs/cert.pem SSLCertificateKeyFile /etc/ssl/private/cert.key Be sure to set the certificate key paths correctly. Also - change 1.2.3.5:80 to the internal IP and port to the service to be published. You also need to set the 'ServerName' to match the external CNAME record you setup. A quick reload of Apache - and it should work. I use this to publish several security cameras, a mythtv system, my ISY and my router. Generally works fairly well - but there can be issues with some web services that embed absolute links in the HTML. There is no rewriting of URLs within the HTML going on - so each published service may involve some work. Michael.

Damn, why didn't I think of that. Great idea! Every bulb in my house is LED now, and this one was bugging me, due to how much power it consumes, 24x7. I'll probable use an InlineLinc to do this though. Thanks! Sent from my Nexus 7 using Tapatalk HD

Both my original and the replacement did this within hours after a factory reset - before ANY devices were linked. Empty link table and confirmed removed from the PLM link table, yet the issue still happened. Its not a protocol issue.

Same issue I'm still having with my replacement thermostat. I really wish SmartHome could figure it out. Michael. Sent from my Nexus 7 using Tapatalk HD

Thanks Steve. If there is *any* info I can provide to assist - I am more than willing to do so. I think the issue is in the power circuits to be honest - when I powered the 2441TH from my HVAC - I would randomly get the stat changing setpoints, mode and leaf mode. I added a 24VAC transformer to power the 2441TH - and only the left mode symptom remains. This indicates to me there is a sensitivity to noise on the power lines. Perhaps that will give your engineering an area to look at. Perhaps this is also the reason some people have issues - and others do not, and why my replacement unit had the same problems as the original. Michael.

@NHWA You said: "I spoke with smarthome today and they said they did have a few issues with this but that they haven't had any issues with anyone running the newest RC/beta for ISY" I hate to say this - but based on my communication with SmartHome they may have lied to you (or, at the very least, misled you). I'm on 3.3.7 since the day it came out - and I reported back to SmartHome that the 'leaf' issue is still present the day after I upgraded to it. So - they *do* know that there is at least one person with the left mode issue 'on the latest RC/beta'. they keep pointing the finger of blame at the ISY - but have failed to acknowledge my tests that confirm the leaf issue still happens when the link table is empty (immediately after a factory reset of the thermostat). It's getting frustrating to be sure. I truly don't believe they would lie like that. It's probably more likely that either my case was not updated with this information - or the tech that responded to you didn't actually bother to check before the statement was issued - but I do want it on record that on 3.3.7 the left issue is still present. It's present without a connection to the ISY. I just don't believe it's an ISY issue at all to be honest. It feels bad to say - but I am somewhat happy that others have now reported the same issue. It means it's not just me and (hopefully) should add additional priority to the issue - I hope. Michael.

Sounds reasonable. Just getting frustrated with the way SmartHome is handling issues with this device - generally be ignoring them. I just want it to stay at the temperature setpoint that I want.. I will reiterate this from earlier communications. An email from Danny Fehskens @ SmartHome support I received on November 14th stated: ""Leaf mode" is an energy saving mode that automatically reduces your high end temperature to save energy. Occasionally this mode can be inadvertently triggered within the ISY." I'd really like to know how this is even possible - or how he comes to this conclusion. They squarely seem to think it's an ISY issue - especially now that they have RMAd the original device and my replacement is doing the same thing. I'm OK at the moment with this program to work around the issue: If Status 'Thermostat' is not 71° (Heat Setpoint) Then Set 'Thermostat' 71° (Heat Setpoint) Seems ridiculous that I need to do that. From the log I can see it reset 3 times last night. Crazy. No correlation to other timings at all - 23:56, 23:57 and 0:50. Nothing else seems to run at that time - and since then it's been solid (now 10:43). My feeling is that it just has to be a bad device - again. However, I find it really hard to believe that nobody else is seeing this - I'm on my second device now both displaying the same issue. How am I to convince SmartHome that it's a second bad device? How can I find out if the 2441 is enabling the setback mode in response to an Insteon command - or if it's 'spontaneously' doing it without any command? Are there any debugging tools or analysis I can do? Thanks, Michael.

I tried that - and thought it worked around the issue. But it just came back.. Setpoint was 71 and heat turned on (23:19:46). Few seconds later - the setpoint changed to 67. How can I find out what is going on here - it's driving me nuts. I *really* need the ability to have the ISY read the current state of energy saving mode - and be able to adjust the setback. Can this at least be on the wish list? Thermostat - Heat Ctl Status On Sun 2012/12/23 23:19:46 System Log Thermostat Heat/Cool State Heat On Sun 2012/12/23 23:19:46 System Log Thermostat Status 69.5° Sun 2012/12/23 23:19:49 System Log Thermostat - Heat Ctl Status Off Sun 2012/12/23 23:20:21 System Log Thermostat Heat/Cool State Off Sun 2012/12/23 23:20:21 System Log Thermostat Heat Setpoint 67° Sun 2012/12/23 23:20:24 System Log Thermostat Cool Setpoint 79° Sun 2012/12/23 23:20:25 System Log I also noticed during the time the 2441TH was connected to HomeLinc - there are two more nodes there than are exposed thru ISY - in addition to 'Heat Ctl' and 'Cool Ctl' there are nodes for 'Humidify' and 'Dehumidify' based on the humidity setpoints relation to the measured humidity. Is this not implemented in ISY or is it planned? For the time being - I think I just have to continue my brute force program - simply set the temp to 71 every time it's not 71.. seems excessive but it's the only way to have a consistent temp in the house - something that should be a basic feature that SmartHome is just ignoring. I guess buyer beware. Thanks, Michael.

Hi Michel, What a drama. Smarthome replaced my 2441TH with a new unit. I replaced it and.... had exactly the same issues as I did with the old one. I began having one of those 'feeling' that it is a power related issue (the 2441TH was getting it's power from my HVAC control board) and every time the HVAC fan turns on it caused a voltage dip (or spike) enough to trigger random happenings on the thermostat. So - I picked myself up a 24VAC transformer from radio shack and wired that to supply the thermostat with power. It completely solved my random changes (heat/cool/set points) - it's not happened once since. I figured that if anyone else gets into random changes - they should possibly look at the power supply as a potential source. IMO - Smart Home need to do better with the power circuitry in the 2441TH - but that's another story. However, the issue I have of the thermostat going into 'energy saving setback' (or 'leaf') mode still happens. Usually - but not always - it's overnight. Smart Home are pretty insistent that the ISY is doing this thru an incomplete or improper I2CS implementation on the ISY - and I have no way to refute them. I don't have access to their documentation for the thermostat to know - so I'm hoping you can give me more to go on regarding this. Is this possible? I either need to change the setback to 0 degrees (since I'd implement a setback in the ISY anyway) or have the ISY read and be able to set the energy saving mode properly. Not sure where to go since I cannot do this in the ISY at all. I think I'm going to reinstall the HouseLinc software (I still have the HouseLinc PLM from the days before my ISY enlightening) and see if I can change the setback to 0 at least to minimize the effect of the issue. Any other ideas? Thanks, Michael.

Yelling!

Michel, I fully agree with you. I don't think it's possible for the ISY to do what I have been seeing out of the thermostat. I spent some time on the phone with Smarthome today - and it looks like I'm seeing things that simply shouldn't be happening - including having the thermostat spontaneously change from 'Heat' to 'Cool' when I turned off 'Leaf' mode. The two just shouldn't be linked - so we think it's very likely that the root cause if a bad thermostat. They are cross-shipping me a new one. Hopefully, that will resolve the issue - I don't see why not. Do you know if there are any plans to be able to enable, disable and poll the 'Leaf' or 'Energy Saver' mode that the thermostat has? Currently - there is no way to tell within the UI of the ISY. I'll be asking MobiLinc as well - since I'd like to see the current energy mode there as well. Thanks, Michael.

Oh - another question. It seems I cannot enable or disable energy saving mode from a program - or query for it's current status. I also cannot program what the setback is for energy saving mode - as Smarthome seems to suggest should be possible thru software (since they provide no way to set it thru the UI of the device). Is it possible to add this to the software? It's rather an important feature of the thermostat that's simply configurable right now thru the ISY. Michael.

Been away for a while. I managed to keep my 2441TH in check with a simple program: Repeat Every 15 minutes Set 'Thermostat - Main' Mode Heat Set 'Thermostat - Main' 70° (Heat Setpoint) Set 'Thermostat - Main' 77° (Cool Setpoint) Today, I got to looking at it again. Still having big issues. Here is my short process this morning: At 8am, I disabled all programs on the ISY. At 8:08 - I manually set the mode to 'Heat' and the setpoint to 70. At 8:40 I checked - it was still mode 'Heat' and 70. Good. At 8:43 - for some reason the thermo changed to mode 'Cool - and the heat turned off. I noticed this at 9:18. I disabled 'leaf' mode, set 'Heat' and the setpoint back to 70. (9:18:02) 9:18:37, leaf mode turned on again and system turned to mode 'off' (I saw the display change this time!). 9:19:35 I reset system again. Here is the log from the ISY: Thermostat - Main Heat Setpoint 70° Fri 2012/11/23 08:08:57 AM System Log Thermostat - Main Status 67.5° Fri 2012/11/23 08:09:42 AM System Log Thermostat - Main Status 68.5° Fri 2012/11/23 08:15:16 AM System Log Thermostat - Main Status 69° Fri 2012/11/23 08:22:55 AM System Log Thermostat - Heat Ctl Status On Fri 2012/11/23 08:42:37 AM System Log Thermostat - Main Heat/Cool State Heat On Fri 2012/11/23 08:42:37 AM System Log Thermostat - Main Heat Setpoint 66° Fri 2012/11/23 08:43:12 AM System Log Thermostat - Main Cool Setpoint 77° Fri 2012/11/23 08:43:13 AM System Log Thermostat - Main Thermostat Mode Cool Fri 2012/11/23 08:43:14 AM System Log Thermostat - Heat Ctl Status Off Fri 2012/11/23 08:43:19 AM System Log Thermostat - Main Heat/Cool State Off Fri 2012/11/23 08:43:19 AM System Log Thermostat - Heat Ctl Status On Fri 2012/11/23 09:18:02 AM System Log Thermostat - Main Heat/Cool State Heat On Fri 2012/11/23 09:18:02 AM System Log Thermostat - Main Heat Setpoint 70° Fri 2012/11/23 09:18:04 AM System Log Thermostat - Main Cool Setpoint 73° Fri 2012/11/23 09:18:05 AM System Log Thermostat - Main Thermostat Mode Heat Fri 2012/11/23 09:18:07 AM System Log Thermostat - Heat Ctl Status Off Fri 2012/11/23 09:18:37 AM System Log Thermostat - Main Heat/Cool State Off Fri 2012/11/23 09:18:37 AM System Log Thermostat - Main Heat Setpoint 66° Fri 2012/11/23 09:18:39 AM System Log Thermostat - Main Cool Setpoint 77° Fri 2012/11/23 09:18:40 AM System Log Thermostat - Main Status 68.5° Fri 2012/11/23 09:18:51 AM System Log Thermostat - Heat Ctl Status On Fri 2012/11/23 09:19:35 AM System Log Thermostat - Main Heat/Cool State Heat On Fri 2012/11/23 09:19:35 AM System Log Thermostat - Main Heat Setpoint 70° Fri 2012/11/23 09:19:37 AM System Log Thermostat - Main Cool Setpoint 73° Fri 2012/11/23 09:19:38 AM System Log Clearly - *something* is changing the thermostat into 'Energy Efficiency' or 'Leaf' mode, as well as changing the heat/cool mode. I have no programs running. Nothing shows up in the error log for the time period. I asked Smarthome - who tell me 'It sounds as if you have a program within the ISY that is causing this error. "Leaf mode" is an energy saving mode that automatically reduces your high end temperature to save energy. Occasionally this mode can be inadvertently triggered within the ISY.' Honestly - I'm not sure if I believe that. It's not just leaf mode being triggered - but the thermostat changes from 'Heat' to 'Cool' mode (or off) as well. Here is the 'Links' table from the 2441TH: Device Links Table : Thermostat - Main / 1D 6D CB 1 0 8184 226 239 1833911 16719855 1 8176 226 1 1833911 16719617 2 8168 226 2 1833911 16719618 3 8160 0 0 0 0 This table matches what the ISY thinks should be there. I have gone thru all the programs on the ISY. Nothing is touching the 2441TH. So - where to look. How can I find out what is doing this? Is this command being initiated from a faulty 2441TH? How can I tell, conclusively, that it's a faulty 2441TH and not a faulty ISY or something else entirely? I'm at 3.3.4 (both firmware and UI). michael.

New as in I cannot find any reference to this issue in the forum so far. My ISY 994 is at 3.3.3 - confirmed in in the client both for firmware and UI. I removed the 2441TH - did a reset on it - made sure it was 'Off' and re-added it to the ISY. I can control the 2441TH just fine - changes on the ISY get reflected fairly quickly on the 2441TH. When I change the 2441TH - the changes get reflected in the ISY. The problem I have is that the 2441TH seems to randomly change modes. This morning, I set it to 'Heat' and the setpoint to 70 via the ISY. Just now - I felt cold. I looked at the ISY and it reported the 2441TH was in 'Cool' mode with the setpoint at 80! On top of that - the 'energy saver' mode was enabled. Wow. I set the mode back to heat. This seems to happen every day or so - but to different modes. Sometimes the setpoint just changes - or the mode changes - or both. In all cases - the ISY and 2441TH stay in sync (they both change). How do I figure out where the change is coming from - the ISY or do I have a faulty 2441TH that is just 'messing up'? Right now - I have removed the 2441TH from my ISY so it's stand alone to see if it's config changes. Michael.