Bumbershoot

It's easy. Here's a sample of the body of an email with an embedded variable: The ISY was up ${var.1.4} hours between reboots. INTEGER variables are indicated by: ${var.1.x}. STATE variables are indicated by: ${var.2.x} In this example above, ${var.1.4} indicates an INTEGER variable with an ID of 4. You get the ID of the variable from the leftmost column of your variable list.

Greetings, With high August temperatures just around the corner, I've finally started thinking about automating a retractable awning that I have installed over my deck. This awning was installed by the previous owner when the house was built in 2000, and uses a pushbutton IGC switch (pictures posted below) that connects to the motor controller. Nothing fancy. I know very little about how these devices work, but I would prefer to either replace the IGC switch with an Insteon or Z-Wave device, or better yet, If it would work, insert an Insteon micro open/close module in the junction box which holds the IGC switch, which has plenty of space. The IGC switch has three wires coming from a cable out of the motor controller, which I believe are utilized as follows: white = up black = down green = common The Somfy motor apparently has limit switches for the extended and retracted positions already, and the "STOP" button on the IGC switch will immediately stop the awning in place, whether it's extending or retracting. This awning is old, but it works perfectly. If it's possible to manage this relatively cheaply (without replacing the Somfy motor), then I'll do it. I will certainly appreciate any insight/advice on how to accomplish this task. Thanks in advance, Bumbershoot

I believe you need the PRO version of the ISY to use node servers. I also believe your ISY is easily upgradeable by contacting UDI sales.

I just ordered one for backup. Thanks for the heads up!

I have the feeling there's an idea here that I haven't thought of. I'm beginning to fit out an artists studio with controllable bulbs (LIFX 3rd generation BR30 bulbs are preferred at the moment). The test bulb I have installed works fine with the ISY, the LIFX node server and with Alexa (as well as with the LIFX app), but I'm curious as to how you're using a SwitchLinc dimmer in this sort of application? Thanks.

Another option: If you're on firmware 5.x.x and interested/willing to run Nodelink (which I am for other functionality it provides), you can turn on the "ISY Data" node and this problem can be easily solved (see attached screenshot). I've run Nodelink on a Mac Mini and on a RaspberryPi and it's never hiccuped even once on either platform. For me, this is an easy solution.

Another good idea. The bouncing would be somewhat mitigated by the 300 second polling interval I have in climate module, but I think I'll add your hysteresis programs so I'll have the idea codified somewhere in my ISY. I know this will help trigger another solution for me somewhere in the future. Truth be told, I've never paid much attention to the "status" value of programs before. Very handy. Thanks again, this is very helpful.

I like this, and you've taught me something here. I'm currently building out my (somewhat simplistic) HA installation by putting in a ELK system, along with a variety of occupancy sensors. One of the questions I've started thinking about is how to use occupancy sensors in conjunction with lighting schedules, trying to make sure that lights don't get left on unnecessarily, while simultaneously not throwing people into the dark, all the while maintaining a good lighting ambience in the house. This gives me a way to start solving that problem, too. Thanks. I'll put this into production and watch my grass grow!

I understand how this would work. This is a variation of what I was thinking before I started reading this thread and confused myself. BTW, outside humidity where I live tends to swing quite a bit in the spring, with very localized rain and sun conditions. The weather station I use in the climate module is close, but not that close, and I don't need a great deal of precision with this application (the affected area is small).

You described the problem exactly. I've never used the true/false status of a program as a trigger, and I don't recall seeing that technique described before (though maybe I just haven't paid enough attention). I do see how this can solve some thorny conditional problems in other areas, such as lighting schedules being affected by occupancy.

I originally figured I would put the climate data into variables that a second program would check before running. I may still do that, but I thought I'd give this program a whirl after reading this thread and see how it behaved. You're right, this might be too much water. I just wrote this program this morning, figuring I'd adjust it before long. The program ran for the first time this morning, right when I expected it would (four hours after sunrise). As I was typing this response, the program fired again, though not when I expected it to, so it appears you're correct about climate data changes re-triggering the "if" clause (the wind speed was the value that changed). And yes, I definitely want to shut the water off! It fired off this morning and caught the dog out in the yard doing her business, so at the very least I've gotten a laugh out it! This has been very helpful. Back to the drawing board...

Okay, this thread has me a little confused. I wrote this little program to demonstrate my question. I want to water in some grass seed on the back lawn that suffered some winter/dog damage. Is there a way, within this program, to have the repeat clause reevaluate the conditions in the "if" statement prior to each repeat cycle (the climate module stuff is dynamic and would optimally be reevaluated each time the program repeats)? I was fairly certain that the "if" clause isn't reevaluated with each repeat cycle, but suddenly I'm unsure about that. Normally, I'd use one program to call other programs based on values from the climate module to accomplish this. Is that correct? BackLawnReSeed - [ID 008A][Parent 0089] If From 7:00:00AM on 2017/05/05 To 10:00:00PM on 2017/05/20 And ( From Sunrise + 4 hours To Sunset - 1 hour (same day) And ( Module 'Climate' Temperature > 50 °F And Module 'Climate' Total Rain Today < 0.2 " And Module 'Climate' Wind Speed < 15 mph ) ) Then Repeat Every 2 hours Set 'Devices / dirNodeServers / RainMachine / RainMachine / Rear Lawn' Start Wait 10 minutes Set 'Devices / dirNodeServers / RainMachine / RainMachine / Rear Lawn' Stop Else - No Actions - (To add one, press 'Action') Thanks in advance. This forum is invaluable!

Michel, If I understand you properly, devices such as the Ecobee thermostat or the CAO Wireless Sensors, both of which have cloud based API's, would be appropriate candidates for the development of UDI portal node servers? If so, then this nicely extends the idea of the node server, providing a significant extension for the ISY development community, and a clear win for ISY users. Thanks.

I did the exact same thing, and it worked perfectly the first time. It's nice that we don't have to run Polyglot to get these nodes, and it makes me wonder what other other plans UDI might have for incorporating node servers into the portal. I can imagine Polyglot running on the portal servers...

Indeed, there is a Nest node server, built by forum member einstein42. It runs on Polyglot, and allows your ISY to control your Nest and extends your Nest to control other devices on your ISY. I use ISY programs to change the heating/cooling mode when I'm away and return, to stop heating/cooling when a door or window is left open, to start/stop ceiling fans when heating/cooling modes change, etc. A good example use of the occupancy node in the ISY portal would be to use it to adjust your Nest when your home becomes unoccupied or occupied. Node servers are a bit of work to set up, but they'll help to keep your investment in the ISY relevant.

The calibration on mine seems pretty good. Before the Nest, this house had an ancient (1999) Carrier thermostat that varied from the security system temperature sensor by up to four degrees (they're actually about three inches apart, so they're easy to compare). After I installed the Nest, the two almost always agree, and I've never noticed them diverging by more than one degree Fahrenheit. I don't actually know if either one are accurate, just that they agree. Also, and also maybe more importantly, I can't dispute the high WAF score that Nest achieves. It's gorgeous hardware, if nothing else, and the Mrs. like to tell Alexa to, "Set the Family Room to 70". Happy wife, happy life. The Nest was my first venture into HA, and it created a small reservoir of spousal good will for future projects. I agree, it's not a device that completely gets out of the way and lets you tinker. For example, the API doesn't seem to expose a way for me to adjust the settings for my humidifier (that I've discovered, anyway). And yeah, the "learning mode" does me no good at all. All in all, I like it, and the Mrs. loves it. Win.

Wow, you guys work hard at this! I'm kinda lazy, so I let Nodelink running on my Rpi handle the heavy date/time lifting. Thanks io_guy!

I've had this happen a couple of times. Deleting the device from the ISY, air gapping it then re-adding it has resolved the problem. Fortunately, I haven't had this happen to devices that are used in a great number of scenes, programs, etc. If you are able to extract the needed file from the backup.zip, I don't understand how you would get the file back into the ISY's file system, other than with a system restore or through the "Configuration | Networking | Web Server" Tabs, which only exposes "/USER/WEB", not "/CONF", if that's even the correct path. Maybe there's a method using telnet (it looks like there's "List files/directories" command), or some REST command? I couldn't find it, and gave up.

You can also control Sonos using network resources. I find that using the node server to do the ordinary stuff is quite a bit easier to set up than network resources, though the possibilities are more limited. The screenshot shows your options when using the Sonos node server.

Nodelink provides devices, with properties, to the ISY that you can use in programs, scenes, etc. It is similar to Polyglot in usage on the ISY, though Polyglot requires Python and Nodelink requires the mono libraries (on an Rpi). The Nodelink binary is a Windows executable (Nodelink.exe), and the mono libraries provide a Windows run-time environment on Unix variant hosts. IMHO both Polyglot and Nodelink provide similar functionality to the ISY by working with the new Node Server functionality built into the 5.x.x firmware series -- they extend your ISY to interact with devices that the ISY wouldn't otherwise support. You are no longer limited to Insteon devices, Z-Wave devices, ELK devices or devices that you can interact with using network resources. I think it's huge for the ISY to have this, and I also think the work of the Nodelink and Polyglot developers is equally huge in keeping this platform relevant in the HA marketplace. I've attached a screenshot of the node server directory on my ISY. Polyglot provides: Hue, Nest, Sonos, IP Camera and LIFX control. Nodelink provides: RainMachine and ISY Data. Simply having better and precise control of my irrigation (RainMachine) has saved enough money (water's expensive where I live) to pay for at least pieces of my HA habit. The developers of Nodelink and Polyglot are unpaid, as far as I know, other then through voluntary PayPal donations. I hope this helps...

Thanks, I'd never poked around in the Ecobee developer site before. I see that all API calls use: https://api.ecobee.com That's too bad, though it might make their firmware easier to maintain and update. I appreciate the info...

PurdueGuy, I apologize if I'm intruding or suggesting the obvious, but I notice in your signature that you're using running DSCLink on a Rpi. If/when you run ISY firmware > 5.0.4, you would be able to run io_guys Nodelink on your Rpi, allowing local data for both DSC and your Ecobee with one node server. The benefit may be that there's no more reliance on the cloud. I have neither DSC nor Ecobee, so I can't speak as to how well they work, but Nodelink seems rock solid in my Rpi. Edit: added screenshot showing Nodelink supported devices.

The Nest is nice, and it has a high WAF, so I'm happy. Polyglot isn't bad to set up, but you'll need another device to run it on. Currently, I'm running it on an Rpi, but it runs well on my Mac mini. I recommend firmware version 5.0.9 if you're interested in that route. I have no real issues with the Nest at all.

You might want to look here for some information on Insteon thermostat compatibility with your heat pump. The Insteon thermostats that I installed are not on an ISY, but an Insteon Hub. The screenshot shows how a thermostat appears in the iOS Insteon app. Note however that this screenshot is from a thermostat that is in a home with a furnace and air conditioning, not a heat pump. I don't recall if the Insteon thermostat will control a whole home humidifier, though it certainly reports humidity. EDIT: The Insteon thermostat is an RF only device IIRC, so you may need a dual-band Insteon device somewhere in the vicinity.

If you're not averse to running Alpha firmware on your ISY (version > 5.0.4), then there are more options with Nodelink and Polyglot node servers. Running Polyglot, you can directly control Nest thermostats (which I'm using), and with Nodelink you have the ability to control at least three options: Venstar, Ecobee or Honeywell TCC. The Nest (see screenshot of Nest as a Polyglot node) operates just fine for me, and it plays well with Alexa. Were I to replace the Nest, I would likely go with Ecobee (I like the remote sensors) and control it using my ISY and Nodelink. I also installed two Insteon thermostats at a relatives house, and they've been entirely issue free (they've been installed about a year). All that said, I've had no problems at all with my Z-Wave devices, once I established a sufficient Z-Wave mesh. There are loads of Z-Wave thermostats (at least on Amazon), if you're willing to build the network.