WhiteSax

Here's a screen shot with the Daily Button unchecked. The following also has some handy capabilities: http://wiki.universal-devices.com/index.php?title=ISY-99i_Generic_Calendar_Using_Programs_and_Variables

If one was willing to use a scale back number in the ISY programming, and if one was willing to calculate either a needed series resistor, or select a different resistance NTC thermistor - then it could be make it work. It would take some testing, but odds are the 2441ZTH internal sensor circuit is probably a voltage divider implementation of a 10K precision resistor in series with a 10K NTC thermistor. NTC thermistors decrease their resistance as temperature increases. The conversion model is likely based on the Beta Parameter equation (a simplification over the Steinhart–Hart equation). Between the info here http://en.wikipedia.org/wiki/Thermistor and here http://learn.adafruit.com/thermistor you'll know enough to get the concept. If you have an electronics background - then it should be a bit easier. You'd just have to accept that a reading of something like 95, might actually mean 145 due to the scaling (depending on what factor you calculate). Just remember that the ISY doesn't do floating point, and the 2441ZTH is only going to return 0.5degree increments. In the end it's just math, some tinkering, and shopping research to find the right parts. A fast way to just check the idea would be to put a 5K film resistor trim pot in series with the external sensor you have. Zero the trim, and place the sensor in a glass of warm water (say 100 degrees), then turn the trim pot to increase resistance, which will decrease the current running through the 10K sensing resistor, and make the temp look like a cooler temperature. Then you can try making the water in the cup hotter, and check if the temperature reading increases. This method will likely not give one for one linearity, but it should be proportional provided the water temp is in the operating range of the thermistor. If you are trying to control between two temps (say 140 and 150) then pick a resistance with the water at 145, and try to keep the 2441ZTH readings on the higher end. Next take readings at your two control points, and use those in your ISY programming. Keep in mind that this is all based on the assumption that the 2441ZTH implemented a voltage divider sensor similar to the Beta equation method describe in the links above. One last note: If the Beta being used by the 2441ZTH is about 4000, then it will take about 5.7K Ohms to get a 100F. Whereas a 2K thermistor reading would be about 150F. In this case a 3.7K series resistor would skew the 150F actual temp to read as 100F. The trick is knowing the Beta so one can calculate the expectant resistances needed. Take some test measurements and do some calculations to determine what Beta is actually being used. Just put a 20K trim pot across the input, trim until the reading is 25 C. Then measure the resistance that provides the 25C reading. That is your Ro of the Beta equation (likely 10K). Then take some readings at higher pot values, representing temps colder than 77F (25C). Record the displayed temp, and record the resistance providing that temp. Do the same at lower pot values, representing temps hotter than 77F. Remember that the Beta equation uses Kelvin, so 1/To is not 1/25, but rather 1/(25+273.15). With the data collected solve for Beta. If the Beta values between high temp and low temp differ too much, then go with the Beta for the temp range that will be used in general for your situation. Now you have enough data to either select a series resistor value, or select a new NTC Thermistor with a different Ro and similar Beta. Load the equations into a spreadsheet and play around with expected results to get comfortable with the model behavior. Then go shopping. The graph below shows mapping of the skew, and why one should not expect a direct temp range skew of a fixed degree delta per change of temp. But for small temp ranges its a reasonable approach. Good Luck Enjoy.

If you know the type of grass, you can find the average temperature that starts dormancy. Biologically dormancy is triggered by several factors (soil temp, average temp, the amount light throughout the day, soil conditions, etc.) However temperature is a fairly reliable factor for a given area. You can check an online local weather almanac to find what day of the year reaches that average temperature for dormancy of your grass. Then just program the watering schedule to not trigger during that time of the year. You may want to resume watering a week before good conditions so the grass has an established moisture level to come out of dormancy. For instance, in Phoenix, AZ: http://aggie-horticulture.tamu.edu/arch ... rmuda.html Bermuda will continue to grow as long as the night temp is 34F or higher, and a day temp not less than 70F. The average high temp is at or below 70F from Nov 22nd through Feb 11th. http://www.weather.com/weather/wxclimat ... moMonth=11 This is why Phoenix residents who have grass generally start to plant winter Rye near October 14~20th, in order to keep the yard green and get the rye grass established before it gets too cold to germinate (or trampled by Halloween trick-or-treating). Once you know your type of grass, dormancy temp, and respective dates that meet that condition, one just needs to program the dates into the ISY (annually, or several years at a time using multiple conditions). Keep in mind that the irrigation module only provides an indication of when moisture is depleted and watering is needed. It is up to your ISY programs to actually turn on the water for the calculated duration of watering for your specific system. Enjoy!

Yes the module runs in the winter. The module only knows the type of soil it is watering, and the general location. It does not know the type of grass (or other plants) that it may be watering.

This is how I did it: 1 - update the 99i to the latest firmware. 2 - verify 99i is working properly. 3 - backup the 99i. 4 - remove 99i from the local network, and clear the java cache. 5 - add 994i to the local network, but do not yet plug in the PLM. 6 - check the router status to find the DNS assigned IP Use that IP going forward. 7 - Use Option D from new firmware announcement regarding how to access Admin for the 994i. 8 - backup the 994i before doing anything else. 8 - download and install the latest 994i firmware (matching version of the 99i). 9 - backup the 994i with the latest firmware. 10 - power everything down and connect the PLM from the 99i. 11 - power up and restore the 99i backup from step 3 into the 994i. 12 - set the location and time. 13 - manage modules to force download of 99i modules, and email Universal Devices to request all modules are transferred to 994i. They need the UUID of both the old and new units. 14 - Update the 994i username/password, and verify NTP works. 15 - triple check router to make sure the MAC for the 994i is allowed on the network 16 - reboot and review your programs (some may have Not Specified) items within if not all modules have transferred. 17 - at this point the 994i should be working just like the 99i. 18 - do a general system checkout. 19 - enjoy your new 994i. Hope that helps.

Thanks for the tip. Worked great. Temp Inside = ${sys.node.1F D FA 1.ST} Just had to make sure I didn't use ${sys.node.1F 0D FA 1.ST} as that leading 0 caused issues. Now my fish tank status condition emails can show the temperature near the tank. (I'm still waiting for the 2441ZTH to actually send external sensor temp, as I don't yet want to MOD the 2441ZTH to swap the thermistor for the external one. I'm hoping its just an interface documentation issue that will clean up in some firmware update).

Sorry to ask the typical customer support question, but do you have beeping enabled? 6 button uses B and C simultaneous pushes to toggle beep functions. 8 button uses D and E. Sorry I don't have a KPL in my system to test, but hopefully its just an enable issue. Hopefully someone else can give feedback on their results. WhiteSax

I see the new command in the programming options for scenes. Seems the Main Tab should add a Beep command option button with Scenes in order to provide an easy way to test. It would also provide consistency between the Main Tab scene options and the respective programming command options. Minor details, and not a concern given the quick feature add in 3.3.1 Beta. Just a consideration for the long term solution. Thanks again! -WhiteSax

Thanks Michel, I figured it wouldn't be long before it was supported; hence "currently does not offer" No need to apologize for adding a feature. Once deployed, every time a scene beeps, I'll smile knowing I helped make that happen. It was fun coming up with that one, just hacking around to figure out what can be done with REST commands. Enjoy, WhiteSax

If you like to make your devices beep for audible alerts, you've probably noticed that the ISY currently does not offer a direct command to beep a whole scene. Trying to program multiple devices to beep at the same time results in asynchronous beeps and a lot of network traffic. However, if you have the Network Module and understand REST commands, you can easily program a whole scene to beep. Here's how: First you need to know the Scene ID of the scene you wish to beep. A quick way to find a Scene ID is by using Firefox's Web Developer:Web Console (Ctrl+Shift+K) while browsing the built-in ISY homepage (http:///WEB/INDEX.HTM). * First browse to the My Scenes page, (http:///WEB/INDEX.HTM#/nodes/scenes/) * turn on the FireFox Web Console (Ctrl+Shift+K) (assuming Firefox version 15.0.1) * then scroll to the desired scene and click the OFF symbol * now look at the Web Console area and find an entry containing "/cmd/DOF". * The number between "nodes/" and "/cmd/DOF" is the scene ID. * If your not sure you have the right one, click it a few more times and look for duplicate looking commands. -- [11] GET http://192.168.0.3/rest/nodes/41587/cmd/DOF [HTTP/1.1 200 OK 13ms] For example: In the Web Console data above, the scene ID is 41587. You will want to write down the string from the end of your ISY IP address to the DOF. ( e.g. "/rest/nodes/41587/cmd/DOF".) The next step is to create a network resource using the above REST command but changing DOF to BEEP. Once you've done that you can call the network resource from a program an make the whole scene beep. Here's an example of the resulting network resource. Be sure to use your ISY Username and Password in the Authorization encoding. Be sure to use your own ISY IP address. GET /rest/nodes/41587/cmd/BEEP HTTP/1.1 Host: 192.168.0.3:80 User-Agent: Mozilla/4.0 Connection: closed Authorization: Basic Tm90TWluZTpMT0xfbm90X3NoYXJpbmdfdGhhdA== So lets say you named this Network Resource "BeepSecurityScene". In your program's "Then" section, just call Resource 'BeepSecurityScene'. Add a repeat condition before it to have it beep every second, or for so many counts; as you wish. Hopefully this example has provided you with some new ideas on how to create and use a Whole Scene Beep network resource. I use mine to help wake the family by beeping all the devices when an "at home" security event is detected. It also helps as a deterrent by beeping continuously for "not home" events. If someone breaks-in, they'll hear the beep and know something knows they are there, and hopefully they'll quickly leave. Too bad for them my system sends a text message to our police officer neighbors (with their permission), and to the entire family. One can put the system on battery backup UPS, and use a cell based ISP to make it difficult to circumvent your ISY from outside the home. Intruders can't cut; power, network cables, or phone lines to disable your security. Short of using an EMP or cell jammer, they'll very likely trip the alarm notifications. Enjoy!

Downloaded and installed. No installation issues. Noticed issues with programming LED brightness on 2476D v.40 & 2476S v.3A devices. Reverted back to 3.1.17 and device LEDs again recognize and respond to programming. Otherwise worked well.