Non-triggering conditions for programs

[Vyrolan]

It'd be nice to be able to have conditions in a program which do not actually trigger program execution (kinda like the difference between integer and state variables). Specifically, the "Status" and "Time" are the ones I'd like to see have this feature.

 

We see lots of requests of people just wanting to do something different in certain times...they write a program like this:

If
    Control 'MySwitch' is switched On
    And Time is from Sunrise to Sunset (same day)
Then
    Set Scene 'Day Lights' On
Else
    Set Scene 'Night Lights' On

 

But then the "Time" condition triggers program execution and so the Else runs twice a day unnecessarily. It'd be nice to be able to have the Time condition there just as a conditional check without triggering execution.

 

Similarly with "Status"...you sometimes just want to check the status of something, but not have that thing's status actually trigger your program. Maybe a motion detector only turns on a light if another light is off:

If
    Control 'MyMotion' is switched On
    And Control 'MyMotion' is not switched Off
    And Status 'MyMainLight' is Off
Then
    Set 'MyOtherLight' On
Else
    Wait 5 Minutes
    Set 'MyOtherLight' Off

With this program, if someone toggles the status of 'MyMainLight', the program will run again in the Else and reset the 5 minute timer.

 

I know there are workaround to these things, but I also think they're sources of confusion. In my humble opinion, "Status" should never trigger program execution...if you want to trigger the program, use "Control" which is more clearly indicative of an action being taken. Similarly with time-based scheduling...there should be "Time is" and "Time is not" which trigger the Then and Else repsectively, and then a ranged Time which does not trigger execution. I think the fact that "Time from X to Y" runs the the Then at X and the Else at Y is confusing for beginners (we have to explain it on these forums often).

 

Just in general I think these changes could make it a lot easier to use the Else clause and have fewer programs...one of the more common reasons programs must be split up (or get to having complicated conditionals) is trying to prevent or cause the Else part to run.

[apostolakisl]

This had been a hot topic of discussion a couple years ago.

 

I agree, it would be nice to have a checkbox or something similar that would allow/disallow any individual line in an "if" section to be a trigger. But, for whatever reason UD hasn't taken action on this particular suggestion. If memory serves me there were concerns that it would require a major alteration to the way ISY processes info. The workaround of using 2 programs is totally functional so I suspect this is another reason it hasn't been top priority.

[Michel Kohanim]

Hi apostolakisl, you are 100% correct. We prioritize things based on severity, ROI, and resources.

 

If there's a workaround, it will have a low severity/priority with INSTEON device support having the highest.

 

With kind regards,

Michel

[bsobel]

Hi apostolakisl, you are 100% correct. We prioritize things based on severity, ROI, and resources.

If there's a workaround, it will have a low severity/priority with INSTEON device support having the highest.

With kind regards,

Michel

 

A different perspective if I could for a second; While I understand the rational this does not consider overall customer satisfaction which should be included along with severity, ROI, and resources. I now have quite a few friends using ISY's and most are software engineers or software architects. All have concerns (I've shared some of mine) with the very primitive level of programming capabilities and that is (I honestly believe) one of the biggest issues holding the product back from larger success. I know Michael you've stated that UDI would be looking at improving the programming model this year, and I honestly hope that is true. Things like rudimentary parameter passing (so I can write one motion sensor script and reuse it), expanded variables (let me use a variable in a network request, let me strong a string in a text variable, let me save the current dim level of a device to a variable), real date/time support, better integration between scenes and programs, and ability to at least ping and get an http status code back from a network request are (again IMHO) just the basics required to play in here. (Ok rant off, still love you guys ,))

 

To the request here, I could see this being implemented as a checkmark on each conditional or similar to how and() and or() is implemented with a new nontrigger() block you could add...

 

Cheers,

Bill

[Michel Kohanim]

Hi Bill,

 

Thank you for your feedback some of which I share with you. Please note that, depending on whom we speak with, our success is hinged upon their worldview. For instance:

1. Retailers: ISY is too complicated for regular users. You have to make it much easier to configure/program otherwise you will not be as successful

2. Integrators: You do not support DSC/HAI? How dare you? You are going to be killed by 2Gig and ADT

3. DIYers: What? You don't have ZWave support yet? Mi Casa Verde is going to take over the world and you'll be dead

4. Programmers: No nested ifs and no parameter passing? That's completely sacrilegious; how could you even call yourself an automation device? How are you going to compete with Arduino and RPi? I feel sorry for you ...

5. Utilities: You must support SEP 1.1, SEP 2.0, OpenADR 2.0 and XMPP, Cyber Security and, if not, don't even bother contacting us and you're toast

6. Energy Management/Monitoring: GreenEye and pulse counters (for gas/water) are not supported yet? How long do we have to wait. Forget it, you'll never amount to anything in the energy management market

 

This is just a short list .... so, back to your feedback: program enhancements are in our plan for this year.

 

With kind regards,

Michel

[MikeD]

I would like to see these programming enhancements too. However I'm new to the ISY world and having a great time doing things with its limitations so far. I know the 'newness' will eventually wear off but also know that UD and members of this forum are very committed to help the community create solutions to their needs. I'm still pleased with my decision to go with the ISY vs. the other offerings. Looking forward to an enhanced command set in 2013!

~Mike

[wwat]

I'd rather have the tools available. If folks can't or don't want to use them due to complexity then they don't have to use them. I've been waiting on a more fuller implementation of variables for some time now and to hear that these types of tools may not get implemented due to some groups finding ISY too complex is a disappointment. The more tools we have the better, the implementation is what can make or break the tools success.

[Michel Kohanim]

MikeD, thank you!

 

wwat, you are correct and, as you can see, we are committed in getting as much functionality as possible into ISY.

 

With kind regards,

Michel

[Xathros]

I too would love to see variables expanded to support strings, decimals, dates, the ability to assign values to and from devices, be able to use variables in network resources etc. All of those would make the ISY soooo much better than it is.

 

That said, even with the ISY's current limitations, it it an excellent system and over time has only gotten better. That coupled with the support offered by UDI and this community makes this the ONLY home automation controller I would recommend.

 

-Xathros

[wwat]

That said, even with the ISY's current limitations, it it an excellent system and over time has only gotten better. That coupled with the support offered by UDI and this community makes this the ONLY home automation controller I would recommend.

-Xathros

 

I'll second that, the support is second to none. W.

[ellesshoo]

If
    Control 'MyMotion' is switched On
    And Control 'MyMotion' is not switched Off
    And Status 'MyMainLight' is Off
Then
    Set 'MyOtherLight' On
Else
    Wait 5 Minutes
    Set 'MyOtherLight' Off

I'm curious about this code. I've seen something similar elsewhere but never asked. What is the purpose of having both control is switched on and control is not switched off? Seems that if we're talking about a motion sensor, that can only be on or off, they would be triggered by the same event and evaluate the same way, true or false. I'm sure there's some aspect that I don't understand, can someone explain?

[MikeD]

I had the same question and LeeG annswered it in this thread;

 

viewtopic.php?f=27&t=10631&start=15

 

Here is his explanation on the 'is not switched' part of the statement;

An If Control 'xxxxx' is not switched Off by itself does not trigger a Program when a On command is received. Independent of the not, If Control must match the command received, Off in the example, for the Program to be triggered. Easy enough to verify. Code up a test Program that contains an

 

If Control 'xxxxx' is not switched Off

 

as the only thing in the If section. Tap the On paddle. The Program does not trigger, True or False as the command received does not match that specified in the If Control. The only thing that triggers the test Program is an Off command and it always drives the Else because the 'not' results in False.

~Mike

[apostolakisl]

If
    Control 'MyMotion' is switched On
    And Control 'MyMotion' is not switched Off
    And Status 'MyMainLight' is Off
Then
    Set 'MyOtherLight' On
Else
    Wait 5 Minutes
    Set 'MyOtherLight' Off

I'm curious about this code. I've seen something similar elsewhere but never asked. What is the purpose of having both control is switched on and control is not switched off? Seems that if we're talking about a motion sensor, that can only be on or off, they would be triggered by the same event and evaluate the same way, true or false. I'm sure there's some aspect that I don't understand, can someone explain?

 

Pretty much I think of "control is not" (as compared to "control is") to simply mean, swap the "then" and "else".

 

Or in other words, figure out what the line would do under "control is", and then it does the opposite with "control is not" as far as then or else. The trigger on the other hand is the same regardless. i.e. "Control is switched on", and "control is not switched on" both trigger with "on" only, the difference is whether it executes to "then" or "else".

 

"control is" when acting as its own trigger only runs true, any other trigger and it is always false.

"control is not" when acting as its own trigger only runs false, any other trigger and it is always true.

 

The only purpose I find for using "control is not" is when you have other conditions in the "if" section which lend themselves to being true or false and you want the particular "control" line to match the true or false simultaneous state of the other lines. As a single line in the "if" section, you get the same exact result if you just swap the "then" and "else" contents, so there is no point in using "control is not" as a single "if" condition.

[ellesshoo]

If
    Control 'MyMotion' is switched On
    And Control 'MyMotion' is not switched Off
    And Status 'MyMainLight' is Off
Then
    Set 'MyOtherLight' On
Else
    Wait 5 Minutes
    Set 'MyOtherLight' Off

I'm curious about this code. I've seen something similar elsewhere but never asked. What is the purpose of having both control is switched on and control is not switched off? Seems that if we're talking about a motion sensor, that can only be on or off, they would be triggered by the same event and evaluate the same way, true or false. I'm sure there's some aspect that I don't understand, can someone explain?

 

Pretty much I think of "control is not" (as compared to "control is") to simply mean, swap the "then" and "else".

 

Or in other words, figure out what the line would do under "control is", and then it does the opposite with "control is not" as far as then or else. The trigger on the other hand is the same regardless. i.e. "Control is switched on", and "control is not switched on" both trigger with "on" only, the difference is whether it executes to "then" or "else".

 

"control is" when acting as its own trigger only runs true, any other trigger and it is always false.

"control is not" when acting as its own trigger only runs false, any other trigger and it is always true.

 

The only purpose I find for using "control is not" is when you have other conditions in the "if" section which lend themselves to being true or false and you want the particular "control" line to match the true or false simultaneous state of the other lines. As a single line in the "if" section, you get the same exact result if you just swap the "then" and "else" contents, so there is no point in using "control is not" as a single "if" condition.

Thanks, pretty sure I just got headache though.

[belanger]

I second the use of "ping and get an http status code", I was hoping I could reboot my server or router/modem automatically when something fails on the network. My remote management power switch failed this morning.

 

I purchase this product over the past weekend... and that was the first thing I needed to do. Now I wonder if I should have go with something more flexible. I went with your product not to have to run a mac mini 7/24 , I'm very surprised when I now read that basic functionality like a "ping" or "http get" isn't implemented yet.

 

Could we have at least the "ping" check added in very near future? It's a start to get the HTTP request after.

 

Would be great if we could have the roadmap of the "approved" features coming for the next few release. Maybe ask your customers to vote? If there's a NDA to sign, let me know I'll be first in line.

 

Pierre

[Michel Kohanim]

Hello pierre,

 

I am not sure what type of device were you thinking ISY was and thus when I read your comments such as "when something fails on the network" and "first thing I needed" and "basic functionality such as ping", I do wonder whether or not ISY is the right product for you.

 

ISY is not a router nor a network management device. ISY is an energy management and home automation controller and almost all functionality is focused for those purposes.

 

Ping functionality is already in ISY; this said, if ping fails, there could be very many different causes such as router, external gateway, DNS servers, proxies, etc. Just having a ping function return true/false is not a good solution and one which might cause other support/regression issues.

 

As such, I cannot guarantee we would be implementing something half-baked just because it's deemed "basic functionality".

 

With kind regards,

Michel

[belanger]

Considering the fact that everyday we hear of new devices coming by default with a network interface (refrigerator, oven, laundry machine, cameras, NAS, pvr, TVs, etc) I think those will soon or later integrate with home automation. I see the day we can remotely turn on the oven at 400F in advance so when I get home I can right away put the kitchen in the oven. If my NAS hangs hard, I'd like to reboot it automatically... specially if it often hangs I'd want to automated that. If there's a REST API on the device, all I need is the proper HTTP request to send to the device and then do something with the response code.

 

All those cheap to very expensive servers can fail. It can be a buggy firmware or perhaps not properly handling a "power glitch". I don't know if the ISY has a hardware watchdog or not, if not I wouldn't be surprised if it could hang just like most of the devices out there in the wild due to a power glitch or bad firmware.

 

As long as my home is connected to the Internet, true I can access my home automation network and go there myself do a power off / on. Some devices with a HTTP request would tell me if all is good or if something needs to be done. I think HTTP is something to consider soon or later since all those devices will someday be part of home automation.

 

Back a the "ping"... What I'm trying to do here is simple. If you don't want to add HTTP request fair enough, I can work out something with a ping. All I want is to make sure that I can always access my home automation network, i.e. make sure the Internet is always up. I think Internet is indeed part of home automation, isn't it? If I couldn't control my devices from my smartphone, I wouldn't be here.

 

Here's the ping workaround to the HTTP request , as you know I don't even have the device yet. ping is over UDP so we do need to be able to specify how many pings are sent. Here's how I would do it, in my words :

 

Variables :

- X = 5 (I want to send 5 pings)

- Y = 15 (I want to reboot the devices 15 minutes later if ping kept failing, just in case I'm doing a firmware upgrade!)

- HOST = 208.1.1.1 (or a fqdn)

Logic:

- ping HOST $X times

- If ping fails $X times $nFAILURE += 1

- sleep 1 minute ... try again

- When nFAILURE reaches 15 , i.e. 15 minutes later, I'd want to power off and power back on the modem.

 

I think many of the people in home automation are computer savvy, such functionality would definitely be welcome. Maybe it's already in there, I'm hoping it goes that far. In all respect of your choice to support or not "HTTP network check functionality" or HTTP requests and be able to process the response, with more devices getting an IP address it's definitely something to consider. I'm definitely glad to hear you have ping functionality now, I don't know how flexible it is... but HTTP requests and response parsing is definitely something many us of want today or in the coming few years. Maybe keep that in mind now so that whatever is currently added in the code could support that in the future.

 

My 2 cents.

 

Now when I get the device this ping is definitely the first thing I'll look at because I'm mad each time my home looses Internet and that I need to wait until I return. Considering I'm sometimes not there for a week to ~2-3 months, now I'm sure you get why it's important for me!

 

Sincerely,

Pierre

[johnnyt]

Pierre,

I'm sure I was reading some posts not long ago about checking internet and rebooting routers. I suggest doing a search for that and browsing the Network Resources forum (sub forum?), not to mention coming back often to read what others are posting. Also search REST. The REST stuff is a bit piecemeal here and there, and I think there's an expectation one knows about it already so I had to google the internet too.

 

I'll echo the comment that ISY is a home automation device, not a network monitoring/management device. Also, if your network equipment, whether it be router, NAS, whatever, keeps failing, I think a replacement is in order. That said I did have a need to reboot my router to reset my VPN's daily so I understand. While in the end I got a better router at my end that has an option to drop/reconnect my ISP at a configurable time each day, so it handles that work but I did have an HA workaround (using HomeSeer) to do the reboot. That was temporary and not the reason nor the basic functionality for which I got HomeSeer or ISY.

 

You'll find the ISY is rock solid. Hanging is very uncommon. It hung on me after a beta firmware upgrade recently but never in "production". I may have manually rebooted it in the early days thinking it had to be done, but it doesn't. Also the tech support and help from other users is head and shoulders above all other support out there. So post what you'd like to do and you'll likely get an answer.

[Xathros]

Pierre-

 

A while back, another forum member, Pounce, pointed me at Digital Loggers Web Relay: http://www.digital-loggers.com/http.html

 

I picked one up and am using it as you describe to reset my network shelf. I am also using one of the outputs to simulate a thermostat on my pellet stove. Once my new PLM arrives later this week, I will be reconfiguring the ISY's power to run through the web relay and adding a ping monitor on that as well.

 

-Xathros

[bigdog]

Hi Michel,

 

I must admit I got a little chuckle out of your post here:

 

Thank you for your feedback some of which I share with you. Please note that, depending on whom we speak with, our success is hinged upon their worldview. For instance:

1. Retailers: ISY is too complicated for regular users. You have to make it much easier to configure/program otherwise you will not be as successful

2. Integrators: You do not support DSC/HAI? How dare you? You are going to be killed by 2Gig and ADT

3. DIYers: What? You don't have ZWave support yet? Mi Casa Verde is going to take over the world and you'll be dead

4. Programmers: No nested ifs and no parameter passing? That's completely sacrilegious; how could you even call yourself an automation device? How are you going to compete with Arduino and RPi? I feel sorry for you ...

5. Utilities: You must support SEP 1.1, SEP 2.0, OpenADR 2.0 and XMPP, Cyber Security and, if not, don't even bother contacting us and you're toast

6. Energy Management/Monitoring: GreenEye and pulse counters (for gas/water) are not supported yet? How long do we have to wait. Forget it, you'll never amount to anything in the energy management market

 

This is just a short list .... so, back to your feedback: program enhancements are in our plan for this year.

It is clear you get it from all directions. I probably fall more into the Programmers category, although I also have many years of experience in the construction industry as well. I have restrained myself and only submitted 2 ideas for consideration in the past, nested ifs (else if or case selection constructs) and a wait modifier. I resist the urge to fire off a post for every little thing I would like

 

I would really like to relate a couple of things that might be worthy of consideration when you are balancing the value of development expense and ROI.

 

First, I love my ISY and Insteon stuff. With the exception of the occasional transient communication issue, everything always works as designed. I demonstrate my system all the time to friends, contractors, electricians, and even building inspectors. Almost everyone shows considerable interest. I even demonstrated it for our city's chief electrical inspector to demonstrate how it was better at energy saving that CA's title 24 codes, and he gave me an exemption from the Title 24 requirements based on the ISY/Insteon capabilities. That was a pretty big deal.

 

I would like to say I recommend ISY all the time, but I can't. As you detailed above, you can't please everyone. I think you have excluded a really important category though. It is those who have no idea what capabilities exist until they see someone else's setup. This includes contractors, electricians and building inspectors.

 

In setting up my own house, my electrician offered to trade his time in exchange for me teaching him how to install all the various Insteon modules and explain the theory. He is a sharp guy, and fairly quickly picked up on the "Insteon way" of doing things. He spent several Saturdays with me and we probably installed 90+ modules, irrigation, pool equipment controls, etc. I think I got the better part of the deal

 

He was so impressed with the whole thing, he convinced his boss that they needed to offer ISY/Insteon installation as part of their business. There was one big problem though, they just couldn't grasp the ISY programming. Believe it or not, there are NO independent integrators in my town. Even the city electrical inspector was not aware of any contractors in the area offering home automation services. There is a clearly definable market here and no one to fill it.

 

So anyway, the reason I am explaining this is that maybe this will help open up a different perspective when you are evaluating where to expend resources. These guys asked me if I would be interested in doing the programming for them. They could sell the jobs and install the various components, and I would consult and do the ISY programming. Well, I am getting close to retirement, and this would be a easy way to make good extra money and have some fun. But I had to decline the offer. The reason is that I have been a professional programmer too long. I need code I am responsible for the be easily maintainable. I think the biggest gotcha for me is the lack of some form of "nested if" construct. For my own house, it is sort of a pain and makes things more difficult to debug, but it isn't really a show-stopper. As others have pointed out, there are "work-arounds". But if I were to do this "professionally" and the best work I can do involves work-arounds right out of the gate, that is probably something I would want to avoid. Programs need to be clearly written, easy to understand, and maintainable by someone else if necessary. The idea of daisy chaining multiple sub-routine programs and having to try to document each work-around in each system is more of a headache than I want deal with.

 

Please don't get me wrong... I am not complaining. I am very happy with my own system and, in fact, just bought the 994 last week. I would not use anything else. I am hoping that by passing this example along, it might help somewhat in your decision making process. I don't see a lot of value in many of the highly targeted suggestions I see posted here, but I do think that a few programming enhancements that will make program creation and maintenance a little more manageable would be universally appreciated, might pay off good dividends for you in the long run.

 

Thanks for a great product!

 

Brian

[Michel Kohanim]

Hello Brian,

 

Thanks so very much for your detailed post and your most valuable insight. Of course we have had Nested Ifs as a requirement for the longest time. The main issue has always been time/resources.

 

Hopefully when Z-Wave is a little more stable, our next batch of functionality is in/around programs.

 

Thanks again and with kind regards,

Michel

[jwagner010]

Sorry to be a PIA but if there are program enhancements this year it would be great if we could have a check box next to wait commands determining whether they retrigger the evaluation of the if statement. If not a check box then having two wait statements to select from, one that retriggers if statement evaluation and one that doesn't.

[Michel Kohanim]

Hi jwagner010,

 

I am sorry but I do not understand. Are you requesting an atomic wait? i.e. regardless of the condition of the program during/after, statements following Wait are executed? If not, please elaborate.

 

 

With kind regards,

Michel

[jwagner010]

Hi jwagner010,

 

I am sorry but I do not understand. Are you requesting an atomic wait? i.e. regardless of the condition of the program during/after, statements following Wait are executed? If not, please elaborate.

 

 

With kind regards,

Michel

 

Today when a program gets to to a Wait statement within the Then or Else section of the program the IF condition is re-evaluated and if it has changed the program may terminate. What I am suggesting is to have an option where the IF statement is not re-evaluated. I hope that makes sense.

[apostolakisl]

This is all part of the same problem with programs that re-trigger.

 

The solution probably lies not in protecting the "wait" command, but rather protecting the "if" section from re-eval. In other words, nested if conditions, or if conditions with a check box next to them allowing or disallowing them as triggers.

 

You may or may not realize that at present you can do a workaround on this problem by splitting your program. Your first program contains only the "if" conditions that you want to trigger/retrigger the wait, and this calls the second program "if" section. Here you put your conditions that must be met for the wait to execute, but you don't want as triggers. You disable the second program which prevents it from self triggering.

 

for example,

 

If

time is 10am

Then

run program 2 if clause

 

program 2 (disabled)

If

status of light a is on

Then

set light b on

wait 10 minutes

set light b off

 

So now light a can turn on/off without affecting the wait. Only the time being 10am can be a trigger.

 

 

Also if you want the timer to run without interuption no matter what.

 

If

whatever conditions you want

Then

set state variable x to 1

 

If

state variable x is 1

Then

turn light on

wait 10 minutes

turn light off

set variable x to 0