gduprey

Howdy, I've been using several ISYs for a few years, but there are a few conditions and situations where I've never gotten a good handle on. One of them is what can be used to "trigger" a program to run and what wont. Previous (referenced in a thread from 2 weeks ago), I had it in my head that IF statements that checked a Status of a device (vs Control statements) would not be triggered when that status changed (that only Control statements allowed for an enabled program to be triggered and Status statements were for conditional evaluation only). Based on responses and to my surprise, that turned out to be bunk and Status checks worked fine in an IF to cause a program top run/trigger. I know that at least with variables, the big difference between regular variable and state variables is changes in a regular variable won't trigger a programs IF where changes in a State variable can. So to get final clarity on the topic, are there any other items that you can include in a programs IF statement that will not result in it being triggered (i.e. regular variables)? Or is it "beware of variables for triggering" and everything else you can reference in an IF is capable of triggering the IF to evaluate/execute? And in a similar vein, are there things that if evaluated (i.e. something else does a "Run (If)" vs an event the ISY processes) won't work except as a trigger? I'm wondering about Control type events -- those strike me as strictly "something happens for that instant of time" and subsequent evaluation of a If with a Control in it will fail because the event has passed) Gerry

Well, status checks work just fine. Not sure why I had it in my head they didn't, though there is some funkiness in what actually causes the "Calling for...." stuff on a thermostat (Calling for Fan doesn't seem to be the same as Fan On -- I get a subtlety there, but I can't reconcile those status's to what I'm seeing from the thermostats). Oh well, happy enough it all works. Thanks for getting me to believe again!

Howdy, I'm looking to augment some of my thermostat functions via the ISY. When trying to create ISY programs based on current thermostat action (like the fan being on or not), I do not see control events, just status events. From what I recall, status events will not cause a program to trigger when they change, but control events do. Short of a nasty busy loop, how would you trigger a program when a HVAC fan request occurs? This seems like a simple thing and I'm hoping I'm just missing something incredibly obvious. FYI -- thermostats are ZWave Honeywell units, though I don't think that is a huge deal -- thermostats being thermostats and the sort of things I'm looking to react to being pretty basic things. Thanks, Gerry

For folks looking to script this process, the wget command is available for all platforms (it's native to linux, but there are builds for Mac and Windows). With it, you can write a script file to set all your parameters, then run it and wake up your device to have it all set in one blurp (helpful for battery devices that might go back to sleep if you were to delay between each parameter setting). I actually created a script to setup each type of device. For example, my everspring climate sensors need 3 parameters set to work for my use. I have 12 of the sensors around this house and the settings are in a script where I pass the ZWave ID as a parameter. When I add a new or replace a unit, a single command configures it. I have a script for those, power sensors, doorbells, motion sensors. A typical usage would be: wget -q -O - --user=USRNAME --password=PASSWD http://isy994i/rest/zwave/node/ZID/config/set/P#/VALUE/SIZE where USRNAME is the ISY user name PASSWD is the ISY user password isy994i is the dns name of your unit (or use an IP address) ZID is the ZWave ID from the ISY (like 'ZW002_1') P# is the parameter # to set VALUE is the value to set into the parameter SIZE is the value size from the ZWave docs for that device/parameter (1,2 or 4) NOTE: The "-O -" (that is, dash oh, not zero) directs wget to write the results returned from the ISY to the console/display. If you'd rather not see it, you can put a file name there like "-O setparam.log" and direct it out to a file. Example: Setting Parameter 6 to a value of 1 for my climate device ZW031_1 would look like: wget -q -O - --user=admin --password=admin http://isy994i/rest/zwave/node/ZW031_1/config/set/6/1/2 Its pretty easy to string a bunch of these together in a script to program a specific kind of device You can also use this to query a configuration parameter like this: wget -q -O - --user=admin --password=admin http://isy994i/rest/zwave/node/ZW031_1/config/query/6 note that the result is returned as an XML fragment (just look for the value= part for the value) and it includes the size of parameter you'd use for setting the parameter (useful when you're not sure -- zwave docs can be very unreliable about actual size). Finally, a good (but not perfect) place to find ZWave parameter documentation is http://www.pepper1.net/zwavedb/device Gerry

It's supported at least as far back as 4.3 and likely close to when ZWave was added to the REST interface (1st line in post says 4.x.x or 5.x.x, so for a while). I'm running 4.3.26 and while not using it from a browser, I am using REST based scripts to do this and it works. One caveat - at least under 4.3.26, there is a problem where the set command always returns successful, even when it failed -- query works and reports errors appropriately if it can't contact the device (a more likely event for battery powered devices).

Hmm -- understood. I'll hold off on my implementation and the next time a motion sensor reports low battery, I'll do the 'query' thing to reset the ISY, not change the battery and see how long it takes before it's set again (if ever). This may take a long time (the batteries last a while), but once it does, I'll try to find this thread and report back. Gerry

So if you reset the low battery flag on a device (via admin console query) but don't actually replace the battery (and assuming the battery is just low, not dead), will it send the low-battery message again? If so, any idea how often? I always (seems wrongly) assumed that low battery was sent when the sensor sent a heartbeat message (i.e. a bit being set in the heartbeat meaning low battery). Since it seems it's an actual, discrete message, I'm wondering how often it sends it. Reason for asking: Around the house, its becoming a joke that replacing the battery doesn't work and to ignore all the low battery alerts. What I'd like to do, assuming the sensor periodically resends low-battery, is to have a scheduled task/program that resets/queries all 'low battery' nodes once a day. The problem is that I'm often not at the house for weeks at a time and other than myself, no one knows how to run the admin console to reset the battery. Remote access is possible, but I'd rather just automate the whole thing, if possible. Gerry

Thanks -- thats good to know! Is there any priority to the queue? If I have a run program and then an insteon command, they'll be in the queue and executed in order, correct? I mentioned earlier, but basically, except for testing state variable values and setting state variable values, they are not doing anything that should take any time until the end of the very last one (that one is the only one that activates an Insteon scene that then turns all lights off). Program 1 (enabled) If Control 'Bedroom Keypad' is switched Fast Off Then Run Program "Set Goodnight (if)" Program 2 - "Set Goodnight" - (disabled) <no If> $Time_of_day = 40 $Entertaining_mode = 0 $Cleaner_Present = 0 Run Program "Set Goodnight Home/Away" Run Program "Lights: Goodnight" Program 3 - "Set Goodnight Home/Away" (disabled) If $Occupancy_Mode is 0 Then <nothing> Else Run Program 'Set Away Patrol' Program 4: 'Lights: Goodnight" (disabled) <no If> Set Scene 'Lighting Scenes / Goodnight' On Run Program 'Secure House' If I take the 'Set Scene' from Program 4 and paste it into Program 1, everything works in 1-2 seconds. That's why I keep feeling it's the chaining between programs that seems to be introducing the delays. The 'Secure House' after the scene sends Zwave command to the locks and 2 Insteon commands to insure the garage doors are closed. But the perceived time delay is when the lights go out -- the "Set Scene" command. Gerry

I've watched the event viewer at least twice during this and see nothing Insteon or ZWave happening during that execution (it's usually a quiet time at night). The 15 seconds is a "worst case" and it varies between about 9 seconds and 15 with an average around 11. I'll be honest, I have my suspicions on this. While I have not yet been able to do much testing on it, something in the back of my head is telling me the more programs that use the 'Status of X is Y' conditionals, the slower this seems to have gotten. That could easily be a incorrect suspicion and I know the 'Status' conditional isn't polling the devices (which, of course, would slow it down even more), but I have two ISYs that share a lot of common code (including the goodnight stuff) and one runs the same 4 programs a lot faster (still 3-5 seconds, but) and one difference is that the faster one has only 1 Status conditional (then again, the faster one has less devices and programs, so it could easily be a red herring). I was hoping a UDI person could step in with any insight about things that put extra burden on the program loop logic and such. I'm away today until next week, so won't get to test this further (i.e. disable all Status conditional programs) until then. Gerry

I'm fairly certain it's not my Insteon traffic -- at least the traffic I'm initiating. The 4 programs I run only set state variables (each handling different areas of state setting). Only the last one I have actually runs an Insteon command and that one single command is to execute an Insteon scene that turns all the lights off. Again -- if I paste all the combined 4 programs logic directly into a single program, the whole thing executes in about 1 second. The only difference between the whole "all pasted together" and 4 seperate programs is that they are 4 seperate programs with RUN program commands to execute. It appears the delay is creeping in between each RUN program and thats what makes me think that perhaps some sorts of conditionals in a program (likely not even the programs I'm running in my 4-program chain) slow down whatever main "loop" the ISY has over these things. Gerry

Well, mentioned that if I copy and pasted everything into a single program, it works very quickly (about 1 second from event to all actions complete). Other than the program that monitors the keypad, all the others have no "if" conditional and they aren't enabled, so doubt that it's really the 4 programs themselves. Nor is it a comms issue -- there are no comms until the very last program and no delays. The program is absolutely started within 1 second of the button press (you can see it start running in the admin console). Its the fact (or related to) that I have to run multiple programs that seems to have some sort of overhead.

Howdy, Are there certain type of conditionals on programs that can lead to slowing down the time it takes the ISY to execute/respond to events? I have an ISY with about 70 Insteon devices and about 90+ programs. Most of the programs are not enabled as they are used as routines called by other events. Probably about 40 enabled. I've found that my "good night" action, it seems to take 10-15 seconds between when I press the Good night button on my keypad and when the lights go out. I've manually executed every one of the few items in the goodnight program and they are all pretty much instantaneous in execution. Because I bottle up the logic for "goodnight" separate from what invokes it, actually doing a "goodnight" involves about 4 programs to be called -- only the last one doing the actual initiating the "goodnight" insteon scene that shuts most lights off. Manually executing any one of these programs from the console is very fast. So the problem appears to be the time to execute the programs, not the content of the programs. To test this, I copied and pasted all the logic from all 4 programs into a single program that is triggered by the keypad. The result is about 1 second between pressing the button and the lights going off. That seems to confirm it's not the actual logic for my "goodnight", but the chaining/running the 4 programs it's spread over. I can't imagine running a program takes too long for the ISY to find and run. So I got to thinking about whether certain conditions on programs were "slower" than other conditions and the ISY is just reacting slower because of those conditions. For example, could using a 'status' condition (vs a control condition) slow down program execution? Or anything else? Debugging this took a long time, but I'm certain that the actual logic runs fast, so it leaves me asking this question. Thanks! Gerryt

Where it's been making me think lately has been for a lot of the RF stuff. Granted, someone has to have an investment in Insteon to really make those worth deploying, but in addition to nearly 90 Insteon light switches/dimmers, I've been adding a lot of motion, door and leak sensors lately. They work well and collectively (in two homes) I have about 135 Insteon addresses in-use around now. ZWave has a lot going for it, but for lighting in particular, I feel Insteon still has an edge for whole home installs (between the fact that Insteon switches have direct/status reporting, directly supported scenes and seem to be, on average, noticeably less expensive than similarly equipped ZWave devices). For thermostats, locks and (to a lesser extent) motion and door sensors, ZWave has much better offerings. I have noticed that there are a lot of "WiFi" automation products in use by folks looking to automate one or two things (a few key light bulbs, a thermostat, etc). But everything has it's own app and/or is bound to some cloud service. It doesn't scale very well for "whole house" automation. I do think there is a place, especially for larger, more complete automation installs, for Insteon and someday, this issue will likely come up. It'll be interesting to see how it's handled (my guess/hope is a new generation of device that adds 8 or 16 more bits and is backward compatible with existing protocols/devices with an implied '00' or '00.00' prefix -- ideally "just" needing a new PLM and ISY firmware upgrade). Gerry

Howdy, Wasn't sure where to put this as it's not strictly an ISY question, but figured someone here might have thoughts/insight on the question. In particular, as I understand it, Insteon device addresses are 6 digit hex addresses. That suggests that there can be about 16 million devices before the device addresses "wrap around". Granted, that is a big number, but not so big it made me wonder what would happen in that case? Would you just have you double check to make sure you don't have an existing Insteon device with that address and return/replace it with another? Is it something the Insteon/SmartLabs people have ever commented on? It may be a hypothetical question, but not so far out of the realm of possibility that someone must have thought about it some. Gerry

Granted that slows things down. But if you find there is some common sequence of commands you are trying to issue, you can stick them in an ISY program and add that. The Connected home stuff works really well with programs and I've encapsulated nearly all my connected home commands in a program, even if it's just one line, so I can expand or extend the command. Just a thought. If you are issuing different commands in a row though, obviously this won't be of any use.

Connected Home is an "automation API" built into the Echo by Amazon. It provides a single, consistent interface for Echo geared toward controlling home automation devices. Vendors can then "plug in" "drivers" to the back of that which accept commands from the connected home interface and translate it to their hardware (wink, UDI/ISY, etc) So using connected home with several different technologies allows a single, consistent end-user interface. "Alexa turn on XYZ" would work for a device called XYZ whether your home automation hardware was an ISY, Wink, Insteon Hub, etc. On the other hand, the skill stuff is entirely up to the provider/vendor to create. So a skill can use any commands and words (within reason) to talk to devices, but each skill likely has it's own "syntax". Connected Home is just a way to "simplify" and harmonize the way you interface with your automation hardware through Echo. Hope that helps.

So if I have two homes each with their own Echo and each with their own ISY and I don't want to "cross connect" either (i.e. both independent), which of the following would I need to do: 1) Two different amazon accounts (each echo connected to a different account), one ISY Portal account (with both ISYs associated with that ISY Portal account and each ISY within associated with a different amazon account)? 2) Two different amazon accounts and two completely separate ISY portal accounts (one ISY per ISYPortal account)? I know the ISY portal can have multiple ISY's listed in it, but reading things over, it's unclear if I can link each separate amazon account to a different ISY if both ISYs are under the same ISY Portal login/account? In short, do I have to have 2 Amazon Accounts and 2 ISY Portal Accounts or can I just use one ISY Portal account and bind each ISY registered with the portal to a different Amazon account? Thanks, Gerry

ISY has given us two different ways to integrate Echo and ISY (based on what Echo offers for integration): ISY Skill: This lets you can generically control nearly any ISY device via the Echo. As such, the sequences of words to use the skill is slightly longer and doesn't seem (at this time) to be as accurate (voice recognition-wise). Pros: Nearly everything the ISY can do is immediately available from the echo (lamps, programs, thermostats, locks, etc). Cons: Voice recognition isn't as good as other Echo commands (possibly IMHO) and the number of words you have to speak (correctly) to accomplish something is longer Connected Home: A very specific Echo command set (like being able to play music) that Echo itself knows about regarding controlling typical home devices. Since it's more "native" to the Echo, there are less words you need to say to make something happen and the voice recognition is (seems) a lot better. Pros: Shorter commands, better voice recognition. Cons: You have to "define" each thing you want to command this way in the portal and the structure (way you address things), isn't as friendly to things like locks, thermostats, programs, etc. Examples: have echo turn on a dining room light: Skill version: Alexa - tell izzy to turn on Dining room light Connected Home Version: Alexa - Dining Room Light on It may not seem like much of a difference, but using it, the connected home approach is much more natural and easier for non-techie people to pick up. Fortunatly, you can use both -- at the same time. Almost no setup to make the skill work and very easy setup to make the connected home stuff work. I've used the skill about 3 times and it didn't work right all three times (voice recognition issues, not ISY). The connected home stuff has been used since I set it up and it works like you'd expect an Echo connected thing to work. The natural desire, when you first make this work, is to set everything up via connected home. I find that is overload and overwhelming. Too many commands and you'll never remember what the exact phrasing is for each. Instead, start with a half dozen frequently used commands and get them working and then as you live with it, add commands that strike you/your family as useful as you come across them. Final note: If you want to use connected home for things that aren't easily supported via connected home, you can create programs in the ISY and then use connected home commands to execute those programs. For example, if I want to have a command to turn the HVAC/Thermostat fan on continuously, I just create an ISY program that turns the fan on in the "then" section and back to auto in the "else" section. I can then setup a connected home command that goes like "alexa - furnace fan on" and viola!! Gerry

After just a few days of using both, I'm actually not in agreement on #2 & 3 . On #2 (connected home for devices) - it's easy to use connected home for programs and scenes as well as devices. Once you know that "xxxx on" runs the "then" portion, you can either use as is or write a "proxy" program that Alexa will run to in-turn do what you need. As for #3 (use both), I think the skill is (relatively) difficult to use and much less reliable (from s spoken word recognition standpoint). In this house, so far, there is absolute zero interest by anyone for using the skill once they see how easy the connected home stuff is. Even running programs is so much easier Connected Home: "Alexa, Evening Lights On" (success over 95% recognition) vs. Skill: "Alexa, tell izzy to run Evening Lights" (success: like 60% recognition) #1 works like 98% of the time and is shorter. #2 works about 60% of the time and takes longer to say. So while the skill obviously allows a lot more of ISY to be exposed, I'm finding that, for Echo so far, about a dozen connected home phrases hit most of what my family actually wants/needs. Other than my "two echos, two ISYs" issue on another thread (which I just do not think is going to play well with connected home), the connected home stuff is the more natural, "Echo-esque" solution. This also fits into my previous experience with house-based voice recognition. The idea of being able to control everything by voice sounds nice, but at some point, it either results in lengthy statements or, more often, non-working statements as most folks don't remember the exact name for every single thing in the house. I feel it's much better to focus on things that the family will really want to control via voice and then use a combination of ISY programs/scenes and connected home commands to make that work reliably and "as people expect" it to work. Then incrementally add more as there is actual demand. Gerry

Wow! Thanks for testing that. I'm only at one house so playing with this is difficult to do right now. The Echo app seems very "global" in nature. As such, consider this case: - at Echo "A" I select ISY "A" - at Echo "B" I select ISY "B" and then discover devices - Launch Echo app -- what connected house commands will list? (my guess both, with "A" commands disabled) - Will connected house commands to Echo "A" still work for ISY "A" or are connected house commands limited to one ISY (last one discovered)? - If there are duplicate spoken names between Echo/ISY "A" and Echo/ISY "B", what happens when that command is issued at Echo "A"? At Echo "B"? So far, from my ***very*** limited testing, it seems that if you have this case (2 Echos at two locations each talking to their own ISY), you really can't reliably use connected house commands and you'll need to use the skill only. I'll have to do some additional testing once I get to the other house. Gerry

How does the connected home part of this work? After I tell an echo which ISY to use, would I then fire up the Echo app ad "discover" devices associated with that ISY? Or in this case (two echo/ISY), would I only be able to use the ISY skill?

Howdy, That sounds great! Will each Echo remember what ISY it was "switched" to? Are there any conditions where it might "revert back" (power loss, etc)? Thanks!! Gerry

Howdy, Okay -- playing with this and being relatively new to Echo skills and add-ons, I'm curious about using the Connected Home vs the ISY skill. 1) It seems like I can use the skill and not enable connected home -- is that correct? 2) Other than syntax differences, are their any capability differences between the Connected Home and Skill method of controlling the ISY? 3) Any other pros/cons (better name recognition, etc)? Any reasons to use one over the other? Thanks!! Gerry

That hass been my impression too While it "works", it does not work well and is both confusing (which profile is active? Do you want to query Echo before every command?) and there is lots of stuff you can't share and/or requires excessive duplication of effort. Plus it works against the whole concept of Echo being easy to use and "just working". I'll be curious what UDI has to say on the topic. As the Echo takes off, you're going to get more and more cases where a person owns multiple echos. Several of my friends have them in their house and their office. You wouldn't want inadvertent commands at the office to do things like opening garage doors, unlocking locks, etc at home. They would need to be separate while being able to share the same Amazon account.

I actually am not looking to "cross the streams" -- I want the Echo in House A to command the ISY in house A and the Echo in House B to command the ISY in house B. But when I setup things in the Alexa/Echo ISY portal, there doesn't seem to be a way to connect commands heard at Echo A to ISY A and commands heard at Echo B to ISY B. Right now, what I think would happen is commands to Echo A or B would have the same commands from ISY A and likely command to either Echo would cause ISY A to respond and ISY B to do nothing. It might be easier if I had each Echo on it's own account and two separate ISYPortal accounts (not sure if I need that, but), but then I can do amazon ordering or share my music collection between the two, which sucks a lot of value out of the Echo