MWareman

Yep. It's invalid when you update the ISY code, and a pain if you have multiple users on the same machine. I should mention, I got multiple logins when I tried the download method anyway. The Argo didn't make it worthwhile since it did not make the experience any better. Also, I launch from Chrome, not IE. I get the same multiple login issue with SSL or not. Been that way since 3.something. I've just grown to live with it - but the Java admin console of Cisco ASA firewalls don't do this, so I know it's not something broken in Java itself. It would be awesome to find out the cause and fix it though. Anything I can do? I'll try to get a wires hark capture of the non-SSL session connecting with multiple logins if you want. Michael.

Yep. See this all the time. Not sure why, but been seeing it for quite a few versions. Personally, I chalk it up to Java. I hate it, I really do...

Too many Michaels's here So, nightly calculation of irrigation requirement. Only gets decreased in between nightly calculations in response to 'irrigation complete' commands. Goes up every night at midnight in response to prior days ETo. Goes down each night at midnight in response to prior days rain total. Is this the correct current understanding? There are so many other criteria - best to look at the other thread on it though. To do what I need, I'm in the process of writing an external function to read the irrigation requirement and rain today (thru the API) to confirm that irrigation is still needed at 6pm - a full 18 hours after the calculation was done. I don't want the cycle to run if, for example, a storm blew thru earlier in the day. It sucks that I have to go external for this - hopefully we will eventually get first class variable handling in programs. It would be much easier to do something like: If (irrigation_requirement - rain_today) > 0.5 then Run irrigate (then) Truly, is it not possible to expose two irrigation_requirement variables? One that was calculated at midnight - and a second one with a different name but that tracks ET during the day as well as rainfall to allow it's use at any point in the day as better read on needs later in the day? It would be reset back to the nightly calculation at midnight, with the other variables? In response to the OPs question, since the irrigation variables are not really variables, its not possible (that I know) to trigger on them when they change. As far as I know. I just send an email at 4am and it seems to have the updated figure by then. Also, you cannot just subtract rain from the irrigation equipment. You have to account for absorption. So if only 80% of rain gets absorbed, then a 0.5" rain will only subtract 0.4" from the requirement. Michael.

My understanding is that the calculations are run at midnight, then static until he next run the next midnight, with the only exception being running an 'irrigate complete' command subtracts the configured amount from the irrigation needed variable. I've been asking for real time updated rain and et data to be applied to the irrigation requirement, but so far I've not seen any plan to integrate that. Michael.

I have that P-touch as well - but have not used it for ages. Thanks for the tip - I need to dig it out. If I remember correctly, they make clear tape for it as well (with black 'ink'). That would be perfect as an overlay on blank buttons. Thanks!

If you use a VPN and don't expose the ISY at all to the Internet, then there is no need for SSL at all on the ISY - as long as your internal network is secure (no guest wifi etc..). However, in my case at least, that would prevent effective use of products like MobiLinc, unless I dumb down the VPN choice to something that is easy to configure and automatic to use on both IOS and Android - like pptp (and I'm not willing to do that!).

Consider using cacert (http://www.cacert.org/). You'll likely have to install their root - but they are a chain-of-trust style free ca. I use them for ssl on all of my systems rather than self signed (which becomes difficult to securely manage). This is why NOT to do self signed. How do you verify that nobody has is performing a man in the middle attack on you if the cert is self signed? You would have to manually confirm the signature hash each time you connect. Bottom line, using self signed cents leaves you open to man in the middle attacks on your ssl sessions - if you are connecting from or thru untrusted networks. Michael.

Two issues I have. First, we shouldn't have to write a program to reset the temp we want. If the device was stable, it would stay set. The device seems extremely sensitive to power supply fluctuations caused when the hvac system cycles - at least that is what it seems to me. The second issue was that in my case it was the 'efficiency setback' feature the stat has that kept turning itself on and off. No way to control that thru a program (at the time, don't know if that's addressed yet). I couldn't even change he setback from anything other than the default 4 degrees. I would love it to work. It's a great looking device (imo) and has a humidity sensor in it as well. I want to use that in some programs as well and am still looking for other solutions.

Personally, I'm about to throw my 2441TH against a wall. I was an early adopter (pre-ordered when it was announced) - but I've now had 2 replacements and it still randomly changes settings. At this time, I cannot in all honesty recommend the product. I am currently using a Honeywell wifi stat, but it is only comparable with its own app. It does the job (as in, it holds the temperature I set) but the ISY cannot control it. I'm waiting until Z-Wave has matured a little on ISY and will jump then to a Z-Wave stat.

Is it silver, as so many have said? We have a cage inside a well known carrier interconnect facility in Chicago. Although photography is prohibited inside, I can assure you that it's not silver A strange hue of glowing blue is more accurate, with the LEDs on the palm readers glowing along the walk ways. It very neat inside - but not very 'cloud'-like.

Thanks!

Gotcha - I forgot that. Thanks for clarifying. Michael.

Indeed, it seems that when you favorite a program on Android, you cannot favorite the 'Run ....' branches. Clicking the favorite pops up a 'which path do you want to run' menu. Very annoying. Works perfectly on IOS though. Got the icons all setup and put that favorite on the camera page viewing the door. Just about as perfect as it gets. Thanks again Xathros. Michael.

Michel, The link on this wiki page to the ISY Runtime Calculator (http://www.universal-devices.com/tools/ ... n_time.htm) ends with a 404. Michael.

Xathros, Looks like I'm going to update my garage door programming. That looks neat. I have but one question. If the garage door is open and you reboot the ISY, doesn't the door get closed essentially uncommanded - since the state variable will be 1 and the program will run the then branch of boot of the ISY. I'm not sure I would want that - even though the chance of the ISY rebooting while the door is open is, I agree, slight. Michael.

Thanks IM - that's awesome. It really sums up the details. Only one question I have. Is rain that falls between the calculations being run (midnight) taken account of within the irrigation requirement 'published' by the module? In other words. At midnight, it is determined that the irrigation_requirement is 0.5" - but between 2am and 3am 0.5" of rain falls (and weatherbug reports it). What does Irrigation_requirement show at 4am? Is it 0.5 (rain that fell is ignored until the next calculation) or 0.1 (rain * absorption factor is subtracted from the requirement for that day). For me, the second one is preferred. Or, perhaps, and option to allow the administrator to choose. I guess the alternative is to be able to schedule when the calculation is run. If I can run the calculation at 4am instead of midnight this issue would be moot. I guess this also raises the question of can the calculation be run multiple times per day now? Thanks, Michael.

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.