Nuttycomputer

Hey rsstansbury, Can you clarify when you say the device shows one thing and the ISY shows another. In your screenshot you have selected the scene properties. In this case those setpoints will only be made active on the thermostat when the scene is turned on and is not the actual state of the thermostat. To see and adjust the actual state you want to select the Thermostat listed under the ISY group. Additionally unless you have controllers you are adding to that scene it might be easier to remove that scene completely as it doesn't appear to serve any use.

Referring to the 2441TH - Good to know you are still looking into it.. I'm available for any testing you might need

Hey Michel I believe this may be related to the general controller group problems as I'm sure your working to get this device ironed out. One thing I noticed though is while the Thermostat Mode, States, Temperature, Set Points, Humidity can be resynced with the ISY via a Query it appears the Fan State never updates in the ISY regardless. This mimics the experience I'm seeing on the Mobilinc as well where it doesn't even give you option of controlling fan. Now interestingly enough this appears to only break when controlling the fan status locally. If I change the fan status in the ISY it is controllable again from the Mobilinc and all devices / programs respond correctly until the next time I change fan state directly with the local button. Trying to get a feel for this but is it because according to documentation the FAN doesn't have a controller group at all anyway and it's status should update via that Broadcast on Any Change group?

Recommend electrical tape or IR Repeaters... If you still want to see the status lights I found 5 strips of masking tape over the lights brings them down to a more acceptable level.

Glad someone posted this. I just changed out my Venstar for this and sent it back. The future wireless thermostats, 7 day programmable, cheaper pricetag, and the venstar's onboard module continually stopping on me made this one dream come true. I was about to post in the Mobilinc forums since that's how I primarily connect but now I'm assuming the problems I'm seeing on the mobilinc (inability to adjust fan, having to continually hit refresh) are probably the same issues you are having. In my ISY I also only have the single node and have to do queries to get temperatures to update.

LeeG might be able to chime in as I'm not in a position to really test this locally for another little while here. However, if your goal is to simply bring the light down to 20% if it is already on when the program runs then instead of Dining.SceneChange issuing an on command you can have it set the level to 20%. The ramp rate was already set so it should be nice and gentle transition still. On a side note there is a difference between issuing an on command to a scene or via a controller. Different controllers of a scene can have different on levels and rates. The scene itself can also have a seperate on level and rate. Is it possible your program is issuing the command to the scene instead of the designated controller?

Disable the Dining.ChangeScene program. That will stop it from running the IF statement automatically.

Good to know that even if I did take it all apart (major pita for my fan i learned) that it might not even resolve the problem.

Hey Everyone, Installed a Fanlinc a few days ago in the bedroom. Nice product that I've had minor issues (mostly due to it being a Responder Only Device), but that is another forum topic. I also found I should have read one of the other reviews that talked about how bright the LEDs were and taped them before I got the fan back together. However, one of the reviews on the smarthome webpage indicated houselinc allows you to turn these bright LEDs off. Can anyone confirm this and can we add this to the ISY? I really don't want to pull the fan apart again and would wait a few weeks for that functionality versus doing that.

It also looks like you can simplify the program. Based on what I'm seeing your simply trying to have the program turn on the outside lights when it gets dark and turn them back off again when it gets light. For example: IF: From 8:30 PM To 9:00 AM (next day) Then Set Garage Lights On Set Front Porch On Else Set Garage Lights Off Set Front Porch Off Nice, simple and condensed. I use a similar program for my outside lights. (except I use the time of sunset/sunrise)

Depending on what your trying to achieve, as LeeG said you can just not attach a load. And if you need to attach the load that was there you may be able to add one of these. http://www.smarthome.com/2475D/In-LineL ... mer/p.aspx

If same day reply is tardy for your company then I think I'm enjoying buying an ISY more and more. I'll cross post this into the necessary forum thanks.

I think the easiest way to test further would be to start a diagnostic trace (level 3) at x:30 run through the steps (if it takes you longer than 10 minutes adjust accordingly) and see what happens at x:40... unless there is an easier way I'm not seeing.. Lee?

LeeG can correct me if I'm wrong but I believe you need to add a turn motor off command to the Else line. Otherwise I don't see why the motor would turn off at 7:21 pm anyway. At 7:00 pm the motor is turned on. The program enters a wait stage... at the end of the wait stage the program is re-evaluated (it may even be at the trigger I'm not clear on that yet). It is now 7:40 pm, the program is false, so the "Then" portion of the rest of the program will not run. Instead the Else will be evaluated.

EDIT: Michel, I got a chance to read those 19 pages again and I see what went wrong and I stand behind the problem I'm reporting. Perhaps it was because I got to read it all in one sitting as an observer instead of trying to participate. Absorption Factor / Soil Type is indeed what I hypothesized it might have been in the original post that follows. It was added to ensure that Rain was correctly accounted for. The problem is it is a rate, that is how much water the soil can absorb over a period of time, in this case hours) which is suitable for being applied to rain because ISY measures rainfall and rain rate. For example if I receive 5 inches of rain within an hour and my soil absorption rate is 2 inches an hour (or 20%) then 3 inches is lost to runoff and so assuming it stops raining for the rest of the day then only the 2 inches should be removed from the irrigation requirement. The Core of the problem however arose around page 15 where it was included, unexpectedly based on previous discussions, into the calculation of Water Applied per Irrigation. Then it was suggested, incorrectly in my opinion, to rename it to Allowable Depletion. The problem isn't the name, which I admit is confusing and incorrect, it is that soil absorption was added into the Water Applied per Irrigation in the first place. The problem is that Soil Absorption is a Rate that can't simply be added to Water Applied per Irrigation unless you know not only how much water was applied but for how long it took to apply that water. For that you would need to have the user input station run times and calculate it for each station. That is far more work on your part than I think is necessary. I think it is better to leave it up to the user to tell you how much water was added to the soil when they ran their system. Even then it still isn't allowable depletion which is based on the factors I listed below and were correctly discussed until page 15. Michel, In addition would it better to move this entire post over to the original discussion? ----- ORIGINAL POST ----- Sigh - I wrote out a nice several paragraph response when my browser decided to crash lol. I guess the confusion Michel is that the Allowable Depletion and why it is multiplied by the absorption factor and water applied per a cycle is not matching with what I've read it should be. Allowable Depletion from my understanding of multiple sources including the wiki you posted above ( http://www.universal-devices.com/mwiki/ ... Irrigation ) is the amount of water that can be lost from the Available Water before the crop/plant/grass has problems with water stress. You are correct this is a set constant amount but it shouldn't have anything to do with how much water I'm putting into the system or absorption factor (I admit I couldn't find this term in any of my reading) On a high level, and some websites out there will walk you through it, these are the factors I understand should be at play when deciding if/when to water: Allowable Depletion: Again, how much water could be lost from the soil before the plants are water stressed. This is a product of the Max Available Water and a Percentage Factor based on type of plant. (For simplicity they recommend using 50% for cool grasses, such as mine, but you could taylor it to specific crop/plant) Max Available Water: Product of Soil Water Storage Capacity and Root Depth. This is what is actually available to the plants. Soil Water Storage Capacity: This is where Clay shines. Though clay takes longer to reach this point, shorter but more irrigation cycles, it holds more moisture. I've seen estimates listing 2.0 in/ft to 2.5 in/ft capacity Root Depth: Self Explanatory ET: Water loss from soil through evaporation and transpiration. I won't get into the math behind this. I barely understand most of it and I have no doubt the program does this part very well. Water Defifcit / Irrigation Requirement: Max Available Water - ET Goal: Run Irrigation Cycle when the ET causes the water deficit to reach the Allowable Depletion Threshold. - To use an analogy. Max available water is how much gas my car tank can hold, allowable depletion is the point my light comes on, and ET is my gas mileage. This is how I understand how this should work and matches the diagram. So to through some numbers in here. Water Storage Capacity - I'll use 2.0 in/ft for clay. It's on the lower conservative side though I could do an experiment to actually test this for my specific soil and maybe someday I will. Root Depth - I actually have about 3 different grasses that grow in my yard due to the temperature swings of my area. For simplicity though we'll use the cool Kentucky Blue Grass that has started greening. Local College has done this work for me and says they grow a root depth of anywhere from 8 inches to 14 inches for my area. I'll use a simple 10 inches. It's on the lower side and I don't feel like digging it up to see what the actual root depth is right now Max Available Water ~ 1.6 inches. Any percipitation/irrigation put into the soil beyond this point is useless to the grass and is the equivelant of letting the gas just spill out of the tank. Allowable Depletion: .80 inches using the simple 50% for cool grasses ET: The controller does this work for me but to make it simple I'll take the value of yesterday which was .13 (cool spring day) If I assume for simplicity sake the ET is constant and reset the system such that is assumes I have a full tank of water it should call for water in about 7 days. I can then setup my program to add the full .8 back or do a partial and just add .5 inches back in assuming the spring rains we have around here will probably make up the difference in the next few days. This historically matches my experience with watering in the spring. So the problem I'm having with my understanding of how the controller works is if I tell it I'm going to put in .8 inches of water it calculates an Allowable Depletion of .136 using %17 clay. It is the .136 number that is subtracted from the Irrigation Requirement. This means given the ET above the system would be calling for water (.8 inches of it) nearly every day. In the summer I would never be able to make up deficit represented even though I would be putting down 7 inches of water a week. In the meantime it would drown my lawn. So I guess given the above am I missing something simple, are the terms being used different? Going back to how Allowable Depletion is calculated as the program understands it: Allowable Depletion = Absorption Factor (<=1) * Water applied per cycle. That actually sounds like it's trying to determine absorption rate except missing the time factor of the cycle. This would make more sense as yes Clay is horrible at actually absorbing the water. Mine can only absorb probably about .2 inches an hour. Which is why I water using multiple short cycles. But this is all done on my end.

Michel, I did attempt to read the history and have read as much as I can on the ideas behind evapotranspiration. I admit a lot of it is presently beyond me. However, I guess I'm confused because in my previous program I would put down about an inch of water a week. Putting out that water slowly so that it would get absorbed into the mostly clay soil. Where I'm getting confused though is everything so far that I've read regarding the evapotranspiration indicates the clay has a higher water storage capacity then any other soil and consequently will provide for the grass longer with less watering (as long as you make sure to water intermittently as to avoid runoff) However if I set my irrigation system up to deliver .5 inches of water a run and set it to Clay the last few days I've been monitoring the irrigation module would have me watering every day because the Allowable Depletion is .085 but we've lost average this week .15 inches a day... That surely can't be right can it.. not in the spring? Perhaps I'm doing something else fundamentally wrong? I will re-review that forum and see if I can locate the problem. Thanks again for the continued responses to my questions throughout the forum as I ramp up my system.

The nice thing about the ISY is I can do the short cycles and wait. This is no problem. However once it actually gets into the clay it should also stay moist and be providing water at the root level for far longer then other soil types such as sand that will just drain straight through. At least that is my understanding. Is the absorption factor in this case factoring in runoff as if I watered the system in one long cycle with no break? If so then it would make sense why numbers are so low...

I'm having the same difficulty. After getting the EZFlora and a sprinkler leak fixed I was ready to get my program running and saving me water. However the absorption factor is where I'm stuck. From what I understand earlier in the post it was stated that the irrigation requirement was lowered by the Allowable Depletion... However when I set my soil type to the listed name of Clay it shows that as under an absorption rate of 17% and a very small Allowable Depletion number. If I used the program in this manner I would be watering far more often then I should. I'm struggling with this because that doesn't make sense unless the labels were inadvertently placed backwards. My understanding is clay is supposed to have a far superior water storage capacity and therefore I should be watering less. Is my thinking wrong or is the module using different terms than I am?

Thanks for that thread. I don't have the required programming knowledge or right now the network module but in the future it may work very well for cheaper wall panels or internet enabled TVs (far away for my setup) and I'm not above learning the required scripting. I mentioned this in another thread but the user-base and direct contact with developers is the reason I chose the do it yourself ISY centered setup I have now over just having someone like ADT come in and install a system. Granted I may have already been setup with them for a lot cheaper but the support would not be 1/10th as good nor would I have the vast functionality I already do.

The guest ability does get close and works great for guests. Unfortunately (and this is something Mobilinc could adjust) the Favorites is one page and doesn't carry over folders which I'm using to logically separate buttons/scenes by room. Nor does it allow you to exit out to check out something as simple as weather. In addition anytime I do programing (add new scenes/buttons/etc) I would need to go to each additional device instead of setting it locally. Again a lot of this could probably be done on the Mobilinc side. The control I would eventually be looking for would be something I could sit down and just input into the ISY then when the user performs a sync only the devices/programs/scenes (and in a perfect world how users could interact with those things) would be sent to the device. This would save management time and also provide some autonomy to the users. I don't know about anyone else but the WAF for me is all about simplicity for her. Me needing to get on her devices and control her app/favorites lowers the factor somewhat. However, my immediate concern (Since I assume you'll approach this in gradual steps) is the ability to restrict at the very least config changes to just the "administrative" account and to additionally only allow that account to be logged in via Lan. Edit: All this does provide good suggestions that I could provide mobilinc. Perhaps they could offer a cloud service in which they sync a "master controller" with the ISY. Then have slave controllers sync to master. Seems like the type of functionality I'm dreaming of could be accomplished that way. P.S. Though I'm not a programmer in the slightest so the actual technical feasibility of my suggestions and therefore ROI are beyond me.

Yeah I looked into these and we are currently using Mobilinc at my house and it performs well. The problem with every solution I've found so far (aside from building my own) is it provides too much information and is difficult to understand for a non-technical individual and/or someone who doesn't care/know what is going on in the background. For example I have a program to set the On Level and Ramp Rate for the Master Bathroom depending on time of day. This requires the Device, a Scene, and 2 Programs (One to change the levels and another to determine whether it is night or not). With the solutions I've seen, including mobilinc, all of these is visible/controllable from the device. While I may be interested in the true/false status of the programs and I know why there is a scene with only one device, it just adds confusion for end users of the system when all the end user really cares about is switching the light on/off. Being able to restrict a user to seeing/doing just that would be be helpful all around.

I second that. In addition I would like to see access control to the admin console. For example I would like to set it up so the admin console is only accessible via the "admin" account and only on local LAN not available via internet. Other users can access the granted devices either locally or over internet. To me this would provide great functionality, no need for standard day to day users to be able to run all programs/scenes/devices or access the admin console.

Avast yes! Using a separate system not running avast has cleared up all my problems so far. Will resolve the problem with Avast. I assume it is a blocking issue I will need to add exception for?

I tried searching this problem in the forums and wiki but either couldn't find it or missed it. I just received my device and I'm having an odd problem with the ISY Admin Console in that any changes I make are not reflected. For example if I add scene or add new insteon device it will let me name/put in address I then hit enter and nothing happens. To see the new scene/device I have to completely exit from the admin console and reload it. Additionally it is asking me to re-authenticate every few minutes. I'm not sure whether that is a related problem. I've tried different firmware versions, flushing the java cache each time, and it is currently running v.3.1.17. I've tried factory reloads with no change. This is very frustrating and I'm assuming not expected because it makes the device unusable to me.

I'll have to look into the programming side more. I just assumed running the program on the ISY itself would make it more difficult when wanting to do a temporary condition or making changes. However perhaps I'm approaching the program incorrectly...