MWareman

I had an interesting one in the irrigation module. I don't know if its new or not (or even an issue) - but I just noticed it. At 4am, my ISY 4.0.4 program ran and determined that the irrigation_needs was 0.657 - so it kicked off a cycle of 0.5. I have 80% absorption set right now, so I would expect 0.4 to come off the irrigation_needed figure, but it did not - at least not right away. The figure read from the module immediately after the complete command ran was still 0.657 (I notify by email immediately before and immediately after the cycle). Two hours later (6am check of irrigation_needs), it reported 0.257 - which is correct. How long should it take for the irrigation_required figure to update after a cycle complete command is issued? Should I add a short wait after calling irrigation complete before re-reading the data to send the notification? Michael.

Weatherbug gives a rain_rate and a rain_today figure. Surely, the rain_today could be monitored with each reading (or every few readings, depending on reading rate) - to determine an actual rate per interval - and therefore be able to determine runoff and quantity absorbed when knowing the absorption rate per interval? Either way - this is more into it than I think I need. I just want to base my irrigation on last nights 'irrigation_required' less the 'rain_today' at the moment of deciding if we need to start a cycle. Should be easy - but I cannot seem to figure it out. And I do understand that I'm assuming 100% absorption of the rain here - but it's close enough for me. When the irrigation_needed figure is calculated again at the end of the day it will be brought back to the correct amount accounting for absorption. Michael.

No need to apologize! Any question answered is hugely appreciated. Even none answered with an opinion posted is still helpful to complete understanding.. and not wasted. I will indeed override all algorithms for the initial 10 days - as that's what our local village allows. I will program the aggressive initial watering needed - and that also needs a permit from the village. Such a pain - but that's how it is. I'm more interested in the ET figure. I apologize - I apparently mis-posted (or mis-read my excel sheet..). I'm getting between 0.08" and 0.18" ET per day according to the ISY. That seems to fit with what you expect for the area. I'll take your recommendation and set the absorption to 80%. That should slightly under-water for me - and that would seem to be OK for turf grass. As I've said - I'm not after perfection - just trying to avoid dead grass (either by over or under watering) - and keep the water bill to something tolerable. Thanks for the help - it's very much appreciated. Michael. (Still interested if anyone has solved the rain fall post-calculation issue.. )

During a rain event - my ISY shows the rate in Rain_Rate coming from Weatherbug - and manual measurements I am planning to do will give me the inches/hour of my system. Does the ISY not take this into account at all? I would think that it could. Anyway - I'm really not needing/wanting to get into this. Just adjusting the amount applied responding to the climate (ET and rain). Michael.

Thanks IndyMike - I have seen your other posts on the subject (especially the monster thread during development) and you are *way* more knowledgeable than I am on this subject. IT does seem though that the final algorithm and recomended programs are somewhat missing from the wiki. Especially the v3 program example linked from http://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:How-To_Guide#Irrigation. Ultimately - I'm only trying to ballpark it, and save water as much as possible. I don't have my system installed yet (next few weeks - depending on city permitting) - but I did get the EZFlora and am trying to figure the programming before I get the rest of the system in. I plan on measuring the run time of each zone to get 0.5" of water deposited, on average. That will set the timings for me. Right now, I have completely bogus run times of 2 minutes a zone, for my (literally) 'dry' runs. I'm told I can easily get my 4 zones to put 0.5" down within an hour. I'm not a gardener - I have no idea how to tell what kind of soil I have. This site http://casoilresource.lawr.ucdavis.edu/soilweb_gmap/ claims I have 325B 'Dresden silt loam, 2 to 4 percent slopes'. How that correlates to 'Soil Type' and '% Absorption' that you need, I don't know. For the time being, I have set the ISY 'Absorption Factor / Soil Type' to '58% - Loam'. Daily ET as calculated by the ISY seems to vary - this is spring in the Chicago area. Seems to be between 0.8 and 1.7. Root depth is something tricky - the area I will be irrigating is getting new sod (it's pretty dead after last years very dry summer - this is the main driving force of the project). So - I assume we start with just a couple of inches and adjust up as the turf grows in. Honestly - I was hoping not to have to get into the science of it too much. I'm actually relatively OK with the irrigation requirement figures coming out of the ISY calculation so far. The issue I have (and am trying to solve) is the 'Irrigation Requirement' (as calculated at midnight) is currently decremented after a 'Irrigation Complete' command - but not with rain fall (until the next calculation run the following night). Without this - I may have an 'Irrigation_Requirement' or 0.6" at midnight - but if at 3am a storm blew thru and dropped 0.5" of rain, the irrigation would still cycle at 4am and be a complete waste. The limitations on programming prevent me from taking the 'Irrigation Requirement' value and subtracting the 'Rain_Today' variable and using that in the calculation. Right now - I'm using programs to track if it's raining - and update a variable if it's 'recently rained'. If so - I simply skip the cycle. Likewise - I'm using calendar functions (from http://wiki.universal-devices.com/index.php?title=ISY-99i_Generic_Calendar_Using_Programs_and_Variables) to track odd or even days - and if even I suppress the cycle. I then put several cycles within the allowed time. By local ordinance I can irrigate only on odd days 4am=>9am and 6pm=>9pm. So, at 4am if the irrigation requirement is <0.5 - I skip it. If not, I initiate a 0.5" cycle and run 'Irrigation Complete' (reducing the irrigation requirement by 0.5). At 5:30am, if the irrigation requirement is <0.5 - I skip it. If not, I initiate a 0.5" cycle and run 'Irrigation Complete' (reducing the irrigation requirement by 0.5). At 7am, if the irrigation requirement is <0.5 - I skip it. If not, I initiate a 0.5" cycle and run 'Irrigation Complete' (reducing the irrigation requirement by 0.5). At 6pm, if the irrigation requirement is <0.5 - I skip it. If not, I initiate a 0.5" cycle and run 'Irrigation Complete' (reducing the irrigation requirement by 0.5). In all cases - if it rained in the 4 hours prior to a cycle - it's skipped. The theory being 'catchup' cycles will happen on the next odd day. Overall effect should be (I hope) an under irrigation. I do agree that over watering will lead to fungus problems - as well as just be wasting water. However, I would prefer the rain block to be smarter then the current 'If it rained any amount int he last 4 hours - don't irrigate now' I have. If it's only rained 0.1" that should not stop a cycle being triggered if the 'Irrigation Requirement' from the last calculation is more than 0.6". Likewise - 'Rain_Today' of 0.2" should not stop the first cycle if the 'Irrigation Requirement' is > 0.7". This would then allow for a cycle still running if a recent rain was only very light - but still suppress it if the rain was heavier and extended. Basically - I want to irrigate less if it rains - but not block it entirely if the rain quantity is too light. I sense I am going to have to call the ISY API from an external machine to get the 'Rain_Today' and 'Irrigation_Requirement', subtract one from the other and write the value back to the ISY as a variable - then trigger the cycle from the variable instead. I just surprise I cannot do this from a program on the ISY itself.

Awesome! - Thanks. One small clarification... In the example... If Irrigation_Required > 0.5 and Rain_today < 0.5 ..this gets messed up if it effectively rained 0.4" (meaning I'm applying 0.4" too much - and wasting water). If Irrigation_Required > 0.5 and Rain_today < 0.2 ..this gets messed up if it effectively rained 0.3" (meaning I'm getting .2" too little). Because Irrigation_Required is updated only once a day at midnight - what I really need to do is subtract Rain_Today from Irrigation_Required and see if the result of that exceeds my threshold. I cannot seem to do that in an ISY program (in the same way that water applied by irrigation is currently subtracted from the irrigation required when a cycle complete is executed). I also have every-other-day and time-of-day restrictions to my irrigation - so I have to be able to do the math for twice a day irrigation on the days allowed. During the summer months (and factoring the absorption rate) it is very difficult to apply the needed water in only one cycle without busting the time restriction. I can irrigate at 4am first - so the time from calculation (midnight) to 4 am is not so great. But the second cycle cannot be until 6pm - and there can be a substantial change between midnight and 6pm. Functionally - is it possible that the Irrigation_Required calculation can be run on demand (rather than just at midnight) - and still function (rather than just at midnight)? Or - have a second program variable 'Irrigation_Required_Live' or similar tracking rain and ET 'real time' as it were. That way - I can have the ISY account for all the variables just before deciding if the threshold is exceeded? I do also want to avoid the "Hey - look at that idiot - it's raining and his irrigation is running" comments.. - but I know that's simply a timer attached to the Rain_Rate. Otherwise - I'm wondering if anyone else has solved the problem or rain falling after the Irrigation_Requirement was calculated - and how. Thanks, Michael.

I understand that the daily ET is calculated only once a day - is it based on the prior day's actual stats? From the Wiki: I'm reading http://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Using_the_WeatherBug_Irrigation_Module and trying to understand the irrigation module with Weatherbug stats. "Yesterday's Water Deficit - total amount of water that has evapotranspired during a twenty four hour window from the day before." The way it's written - this is calculated at the end of the day and then fixed thru the next day - ignoring any ET that happens since - or any rain that falls after the calculation, but adjusting for any rain that fell during the prior day. Is this the case? I seem to have a -ve deficit at the moment - so I assume that simply means it rained more yesterday than was lost to evapotranspiration. "Irrigation Requirement - amount of water to be applied based on the accumulation of previous day(s) water deficits." So this is just a running total of deficits? I assume this is only calculated once each day - and ignores any rain that falls after the calculation - or any ET that happens during the day. Is this correct? By example, today. Irrigation Needs 2013/05/03 at 04:00:00 is 0.3625 inches ET is 0.1006 inches/day. Yesterdays deficit is -0.0443 inches Rain today so far is 0 inches Irrigation Needs 2013/05/03 at 18:00:00 is 0.3625 inches ET is 0.1006 inches/day. Yesterdays deficit is -0.0443 inches Rain today so far is 0.16 inches It rained 0.16 inches between 4am and 6pm today - but the 'irrigation requirement' still shows 0.3625 now at 7pm. Shouldn't it have gone down? I'm getting myself a little confused in that if it rains during the day (after the ET is calculated) but my cycle is triggered at 6pm - I seem to get a situation where the rain during the day is not assessed in determining if the 'Irrigation Requirement' threshold has been exceeded. Should I subtract 'Rain Today' from 'Irrigation Requirement' and see if that exceeds the threshold for irrigation at the end of the day? What is everyone else doing? Thanks, Michael.

I am doing this already with some functions in my house.. It's very kludgy though and not very workable for many. Hence my 'first class device' question - having the ability to have generic nodes in the device tree that do custom API calls to other network devices. I use a Raspberry Pi, but sometimes it feels like I'm just reimplementing the ISY in PHP..... I guess I, again, need to exhibit patience .It sounds like this is what I'm missing and it sounds like you are already on it. Thanks! Michael.

I can't wait... Looking forward to seeing what you have in mind.

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.