larryllix

@TekenThis is the shot I thought would be of most interest to you. It shows the built-in fan cycler at work on the 5 minutes per hour setting. Note the time settings do not equate to actual minutes but rather to cycle ratios based on 5 minute clicks. IIRC this setting gives 15 minutes off and 5 minutes on. The scale can be mouse scrolled to expand to display about a minute per 1/4" of screen.

The black round looks odd at first and the black shows the fingerprints easily. However, now I find white thermostats looks like cheap plastic. Mounting one for a sister-in-law I screwed up and had to use the supplied white rings to cover the sins. I hate the look of them but it is not as obnoxious as a thermostat screen with bright colour photographs behind large number displays that cannot bee recognised due to numeric cover.

Yes. There is a tonne (2200#) of other stuff but it is mostly crap abut better or worse than your neighbours with similar houses.

I assume you have seen some of the ecobee screenshots in old posts? I cannot find the posts anymore but found these in my reserves.

AFAICT the limits are settable from 7 to 49C. I imagine the limits control the setpoint ranges anyway so I didn't try those again. The sliders you see are not absolute but rather a control to cause the main setting to "ramp" either way. The numbers are fictitious and only indicate "direction". It's a little awkward but you only adjust it at set up or when somebody decides the "smarts" are not warm/cold enough. My wife never touches it, and I might do that twice per year after having trouble with my HA that day.

Other than what I already posted, I don't know what you are asking. If you don't want the setpoints to go outside 15-26C then you set that locally as the limits. Now, nothing can set the setpoints outside of that. If you don't want anything to change the setpoint at all then lock it with a password.

I am not sure how low the stat can go because I have the range restricted to a range of about 15c (heat vacation temp) to 26c (cooling vacation temp). These can only be set on the stat face. In addition all setpoints can be passworded. Ecobee3 and 4 stats have absolutely no dependencies on the cloud except for firmware updates, if enabled. The ecobee4 has Alexa built in. Slightly crippled and doesn't hear well mounted against a wall. No 5GHz, and no routines to speak for ISY. I also don't vocal command my thermostats. I got automatic ones that can look after themselves properly and only touch them a few times per year with season changes. I don't use automatic changeover, auto-occupancy, or auto Follow me features as my home is too slow to respond and I am too sensitive to a temperature more than 0.5C off of setpoint. My basement ecobee3 sets the slab heat on and off about 8-12 hours ahead of needing the temperature setting sleep/day. ISY helps adjust those advanced climate type times by outside temperature based algorithms.

Ecobee uses a higher accuracy internally at 0.1C. Users can calibrate all aspects to 0.3C. WiFi and cloud access only, unfortunately. A bunch of silly cloud statistics against neighbours are available (of course it is cheaper to turn your heat down to 'Off') but the run time graphing of run/fan cycles is useful. Downloadable sensor input and averages etc. are available in spreadsheet format (to 0.1C) Fan cycler is very smart with short time cycling, and based on last run instead of just every hour. Setpoints have a local only setting for high and low allowances from any angle of control. A password lockout is also available for use to lockout local and remote setpoint access. I have not seen any firmware updates that control my stat yet. They are tooted to be fully disableable though. I don't know what you mean by "blocked". The stat has no dependence on cloud, only for monitoring and remote control. Programmable climates (I have about 8 now) with dual schedules for heating and cooling. Just switch the mode without reconfiguring times or temps. Sensor calibration wanders the least of any stat I have tried. (Venstar, Insteon, Honeywell) Sensing and setpoints on 0.5C clicks can net you about 1-1.5C off of your setpoint. Ecobee is 0.1C sensing. Sensor is very isolated from electronics and any wall draughts.

Comfort with them will come with beating down your anxieties with practice. Just experiment with them using little programs. You can always delete the whole thing when you are done. ISY is your playground. I think we have a success with the light blink program for you. It is very handy for troubleshooting questionable programs. Insert a program call to the flash program, move it up and down in your programs and delete the lune when done. Keep your programs small and limited to small tasks at a time. Here is a simple programmable timer using State variables. It counts down by minutes during waking hours only. Occupied.countdowner - [ID 0167][Parent 000B][Run At Startup] If $sHouse.occupied.timer > 0 And From 7:00:00AM To 11:00:00PM (same day) Then Wait 1 minute $sHouse.occupied.timer -= 1 Else - No Actions - (To add one, press 'Action') Self retriggering timer. Enabled to run at startup! -If startup occurs ouside wake timeframe, will self start at beginning of timeframe. -If timeframe commences while .timer is 0, first new occupied.timer value will start again. This is the resultant checker that monitors the variable and controls the Occupancy flag variable. That controls all the other functions Occupied.flagger - [ID 0168][Parent 000B] If $sHouse.occupied.timer > 0 Then $sHouse.occupied = $cTRUE Else $sHouse.occupied = $cFALSE Power up assumes home unoccupied! Shouldn't be long to correct that. Program cannot be combined into "Occupied countdowner" program as it's timeframe end would zero occupied.timer Here is a sample MS program that triggers the timer. I have about 12 MSes that activate the timer with different times. Motion.MBR - [ID 0009][Parent 000B] If 'Master Bedroom / MBR.MS' is switched On Then Wait 2 seconds $sHouse.occupied.timer = 180 <----- in 180 minutes the house will be considered "Unoccupied" Else - No Actions - (To add one, press 'Action')

No. You just picked a complex variable application...LOL I think this should work but it will seem complicated, since ISY does not have a proper inline "If" construct. This is being typed freestyle. If MS1 is switched On OR MS2 is switched ON Then Repeat while $lamp.level1 < 0 <---- use variable also as a flag (-1) to indicate it is already in use $lamp.level1 = light status <------ not in use, save the current light level in it Repeat 1 time <----close out the inline "If" condition, back to our regularly scheduled program. Set Light On Wait 5 minutes Set Light $lamp.level1 % <---- restore the light to the found value, not Off $lamp.level1 = -1 <--- restore flag value = "not in use" for the next time Else ---- Go to the Integer variable page and set the value of $lamp.level1 to -1, and then set the "init to" value to -1, also. This will guarantee the variable will always boot up with a negative value.

You have the right idea but this will have problems! The first time an MS triggers it will go through the motions and work properly. As posted above @DrLumen the second last line should be eliminated otherwise flashes could occur with useless command sends. However, While the light is on and another motion is sensed, the Then will start again and, while it works for Wait timer to extend the time, it will overwrite the variable storing the lamp level and later restore the lamp to the latest overwritten value, which will be the one from the program, and the light will never return to the way it was found. This will likely take two programs where the second program disables the first program so it cannot get triggered repeatedly. That may not work either. There may be a way to put a conditional "If" line into your program to prevent all this. Let me think on that one....trouble maker!

Yes. It was the most useful, and simplest variable program I could think of to get you past your variaphobia. Try a few other and useful application that fit your purpose. As @@mwester noted above, until you have a use for them it is just dry homework. OTOH Until you understand some of the uses, you will have no uses for them. It's a double edged sword and a vicious cycle and a.... The first program example was an example of how variables can be triggers. The last one was how they can save things. For that application, think of variables as small boxes you can store things in, so you can het them out later, except they are like bottomless coffee, you take a copy out and it is still there. I'll be back later tonight. I have to take my sweetie out to keep her satisfied happy. Dang spell correct!

This is one thing you cannot d with only programs. I saved a bank of space so they don't end up strewn throughout my 4-500 variables. Please note my variable grouping title as the top variable? (OP @MolsonB). I also can save colours (eh?) of coloured bulbs and strips. I don't think that will work south of the border.

Now I want you to go to the Integer variable tab and create another new variable, called $Lamp.level.saved.asbril. Click save. Now create a new program like this. Flash lamp.abril - [ID 0003][Parent 0001][Not Enabled] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $Lamp.level.saved.asbril = 'MyTestLamp' Status Repeat 2 times Set 'MyTestLamp' Fast On Set 'MyTestLamp' Fast Off Wait 1 second Repeat 1 times Wait 1 second Set 'MyTestLamp' On '$Lamp.level.saved.asbril %' Else - No Actions - (To add one, press 'Action') Now set MyTestLamp to some level of brightness, full on or Off is not dimmable. Click on the new program and run 'Then' See how the lamp gets borrowed for flashing and then returns to what it was at before? This is a program you can keep for testing your other programs. To determine your program has advanced to a certain line, you can insert a call to this program to verify it actually got there. my lines of code Run Program 'Flash Lamp.asbril' (if) my lines of code Use it elsewhere to indicate a household alarm...borrowing the lamp and then "putting it back" to where it started. This is a practical usage of a variable, remembering the status of a light, for temporary usage with another purpose. I use this to flash lights at midnight as a bedtime reminder. The lights return to On, Off, or dimmed level, wherever they were before.

Now a second stage. Add this program 'Time Test' If Then set $testVar = 1 Wait 30 seconds set $testVar = 0 Else ---- Try right clicking on the new program, run Then.

ISY cannot use the example of Wait $variable1 minutes or any other variable, regardless of name. That may be very confusing to a person starting out.

Those were mostly hypothetical programming lines that ISY cannot do yet, only for examples. You already use variables in devices, called fields or parameters. Some you can only read, and some you can only write and some you can read and write the values. When you set your lamp to 50% you are writing to a dedicated variable, and after is sets and reads back the light the variable will show you the result, which you can now use. These may be called fields or nodes or parameters for each device but work almost exactly the same as variables. You have already been using them! Only thing is, with variables they don't do anything in the background, they are for YOUR usage exclusively. Try this. Create a State variable under the State variable tab. Hit "Add" at the bottom, click on the new name that pops up, and edit it to read "testVar", click Save at the bottom. Create a simple program called 'Variable Test' like this. 'Variable test' If $testVar = 1 <------- ISY adds the "$" to indicate it is a variable Then set some test lamp On Else set same test lamp Off Click save Now go back to the State variable tab page. Click on the value at the right beside the name you entered. Type "1", hit enter a few times, or click on another spot to "seal the deal". Try entering "0". Check back when you see what that does for you and we can advance your brain some more. Best of luck!

No. "Init to" does not affect any triggers. The ROM "init to" value is copied to the RAM copy for program usage before any programs are released into the wild upon boot up of ISY. It is an attempt to have ISY continue after a power failure/reboot like nothing happened.

Start Top of Hour Clock - [ID 000A][Parent 000D][Run at Startup] <------------- If Then Send Notification to 'MY_GROUP' content 'ISY_REBOOTED.NTF' $Minutes_of_Hour = [Current Minute ] Run Program 'Find First Top of Hour' (If) <---- only ever calls program once upon power up. Else - No Actions - (To add one, press 'Action') Find First Top of Hour - [ID 000C][Parent 000D] If $Minutes_of_Hour is 0 Then $.Top_of_Hour += 1 <--- is this a State variable? Most here denote State with "s" prefix Else Wait 20 seconds $Minutes_of_Hour = [Current Minute ] Run Program 'Find First Top of Hour' (If) Note Top of Hour - [ID 000B][Parent 000D] If $.Top_of_Hour > 0 <---- must be State variable to trigger program, Self triggering loop? Then Wait 1 hour $.Top_of_Hour += 1 Else - No Actions - (To add one, press 'Action')Note Top of Hour - [ID 000B][Parent 000D] An alternate consideration -could use absolute real time hour above (Not +=1) also $.Top_of_Hour = [Current Hour] Note Top of Hour - [ID 000B][Parent 000D] If Then Wait 10 seconds <------ keep away from jitter point Repeat every 1 hour $.Top_of_Hour = [Current Hour] <-----create real time hour variable for usage elsewhere. Else ----- Very confusing method for me but looks like it should work if a State variable was the intent. You will always need to kickstart it manually after editing it. Proofing will be the final test.

Awesome concept! I like it! I am not sure UDI has gone that far for process control yet though. OTOH they did make some basic engine changes on or about v5.0.4 that apparently sped up processing. Who knows? M. told me there was no list, at one time.

My understanding is when the program is installed, each line is compiled into ISY isms, and triggers are installed into a table or list for the processor to check every X CPU clicks, or whatever time base ISY uses internally. This would avoid the ISY engine from having to "dig" through all the programs looking for what needs doing...for CPU speed and efficiency. Of course this is all conjecture on my part, from writing machine level code with less than 400 bytes of memory and a 1MHz CPU in 1971.

I have no special ISY inside information, but MY logic tells me, based on best resolution of each program element... - Wait lines would need an low-level ISY algorithm that checks for the end timeout every second. -Time trigger lines would have to have an low-level ISY algorithm that checks all time triggers every 60 seconds. Without knowing exact processing times one check every second vs. 24 checks every 60 seconds..... looks like you won!

Nice! With this technique it would be simple for newbie ISY programmers and result in a state variable containing the current system hour, usable elsewhere and never have to be used again. To keep the hour under 24 hours the second program could look like this. If $sHourlyIncrement >= 23 Then $sHourlyIncrement = -1 Run 'Program ThisOne (Else)' Else $sHourlyIncrement += 1 Run stuff The two programs could be combined into one with a more compound If section logic but I would likely separate it into two programs by logical function. One for e the clock setting the variable, and one for the slave function at each hour top. Just the way I tend to think.

For inefficiency and CPU cycle wasting...I doubt you would have to worry about it with ISY and when it comes time, you will have a Polisy running about 40 times the processor speed, with hardware clock and hardware buffered I/O etc.. The repeat every 20 seconds...Correct, runs forever. Init to is a variable assignment statement that programs a ROM copy of the variable for boot up, initial value. One of the first things ISY does is to copy all the "init to" ROM variable values over to the RAM copies of the same name.

I have to agree with that logic. I used a previous system which limited the number of timers available while ISY doesn't, and I suspect too many may bog some processes down. This is one reason to create a central time keeper and have all other programs use it. However, causing ISY to have to check each of 24 time triggers, every system minute change, in a program, may have more detriments to the CPU schedule, anyway. With down to one second resolution, ISY Wait timers may get checked every second? hmmmmmm…. I see the need for the Polisy CPU speed increase coming. Looks to be about 40 times the processing speed.