Creating a Timer in ISY

[IT Solutions]

Hello.  We are new to ISY, but been working with ELK Products for over 12 years.  We are looking for some help to write a program in ISY to have a timer that counts how long a door is open, or an output is turned on in the ELK.  We have the ISY connected to the ELK and it is working.  The ISY logs shows when a door is opened, and when it closed.  We are looking for some help with determining the best way to count the number of minutes the door is open and saving that in an integer variable.

For those that have not done much in ELK and are curious, this is how we do it in ELK.  We set the counter to zero when the door opens or output turns on, then this code runs the timer.  When the door closers or the output turns off, the counting stops. 

We have it set at 61 seconds rather than 60 seconds because we don't need it to be that accurate, and if too many things are set to run once a minute, then add things set to run once an hour, too much load is put on the CPU on the ELK at the top of each hour.  We have another time we put at 59 seconds to spread out the load. The Whenever Every rule in ELK is based on starting at midnight, so 60 seconds would be the top of every minute.

 

I think I can do with with the ISY with a few different programs, but I was hoping to get it done in one program.  We only have 1024 programs available, and we do a lot of automation.  We have two ELK systems that we can't add any more programming to because they are full.  We will be transferring some of the programming from the ELK to the ISY to free up space in the ELK, and lighten the load on the ELK CPU.

[larryllix]

Do it exactly the same way in ISY. Use the system functions to get and save the current second since midnight and when the door closes get and save the system seconds since midnight and subtract the former variable value. Massage as necessary in to minutes or hours etc..

Here is a system I used to analyse heating cyles and caught a few problems for me.

 

[IT Solutions]

@larryllixthank you for that information.  Tracking total run time in a day is something else we are looking to do. 

For this solution I was looking for something simpler like set counter to zero and start counting when the door opens, and stop when the door closes.  Maybe using a WAIT 1 MINUTE then add one to the counter and repeat until the door closes.  Again, I can do that with multiple programs, but was hoping to get it done with one program.  Thank you to anyone that can assist.

[apostolakisl]

This is the way I would do it.

tes - [ID 008E][Parent 0093][Not Enabled]

If
        Elk Zone 'zone' is Violated
    And Elk Zone 'zone' is not Normal
 
Then
        $i.door.open.timer  = 0
        Repeat Every  1 minute 
           $i.door.open.timer += 1
 
Else
   - No Actions - (To add one, press 'Action')
 

If you want the resolution to be in 1 minute blocks.  You could do seconds and divide by 60.  

[DennisC]

You may want to take a look at the ISY Cookbook. It has examples of many different concepts and programs.

https://wiki.universal-devices.com/index.php?title=Main_Page#ISY_Cookbook

 

[IT Solutions]

@apostolakislThanks for the post.  I tried that with an output and it counted to 3, then stopped counting.  Here is my program:

I have verified that the Floor Heat Output is still on and refreshed the State Variable Values and it is stuck on 3. Time lasted changed was almost half an hour ago.  The program is showing as green so I assume that means it is running, so it should be counting.  Is that correct?  Thank you.

[larryllix]

10 hours ago, IT Solutions said:

@apostolakislThanks for the post.  I tried that with an output and it counted to 3, then stopped counting.  Here is my program:

I have verified that the Floor Heat Output is still on and refreshed the State Variable Values and it is stuck on 3. Time lasted changed was almost half an hour ago.  The program is showing as green so I assume that means it is running, so it should be counting.  Is that correct?  Thank you.

Move the line "...Run.Timer = 0" to the last line in Else.

BTW: Use the "copy to clipboad" option in admin console, and past it here using the '<>' posting feature.

[IT Solutions]

@larryllix  Thank you for the ideas.  It appears to be working correctly as is now.  Not sure why we had the one-time glitch.

Why do you suggest moving the "Run.Timer = 0"?

[larryllix]

23 hours ago, IT Solutions said:

@larryllix  Thank you for the ideas.  It appears to be working correctly as is now.  Not sure why we had the one-time glitch.

Why do you suggest moving the "Run.Timer = 0"?

I am not familiar of the style of the Elk NS inputs. If the Elk inputs are ISY triggers (at all) the input can retrigger your program and clear the counter every time and nullify your counting.

I would only clear the counter once the Elk signal indicates Off and after you reported or transferred the counter value elsewhere.

[IT Solutions]

@larryllix  Not sure what you mean by "Elk NS inputs".   What does the NS stand for?

This code triggers on an ELK output change which is triggered by an ISY program.  When the output turns ON, we want the THEN to run. When the output turns OFF, we want the ELSE to run.  The ISY variable $S.Floor.Heat.Timer does trigger a rule after it is over 60.  The timer value is in the emails so moving the zero reset will make the value in the email wrong. 

The timer is supposed to time how long the output is ON, and is working correctly.

Appreciate your help with this.

[apostolakisl]

Your timer sticking at 3 is really not possible.  If the program shows solid green colored icon (not half green) it is currently running the repeat and will be counting once per minute.  My best guess is that your admin console lost its connection and that the actual value was still counting.

NS stands for node server.  With a raspberry pi, Polisy, or other linux device running the node server software, you can create nodes on your isy for a whole slew of things.  There are like 50 or 60 NS's now including everything from your roomba, ip cameras, tesla, pool equipment, etc to isy.

If you move the reset to 0 into the else clause, it will change the counter reset from happening when the heater turns on, to when the heater turns off.  One or the other may be best for you, or it may make no difference.  I don't fully understand what you are using that number for.  But if the point is to trigger a different program if and only if the number hits 60, it won't matter.  If the point is to email the finished value when the heater has turned off, you would want to leave it as is.  In that case, I would put the email notification trigger in the else of the program.

[IT Solutions]

@apostolakisl  Admin console was connected as other variable were changing and I was adding more programs. Thank you for your ideas, but I am not going to waste time troubleshooting a one-off event that we can't reproduce.

Thank you for the explanation on NS.  We have an RPi node server for sending emails from the ELK, but the ELK communicates directly with the ISY, not through an NS.  I suppose one could consider the ELK a NS itself.  Where is a goo place to get a list of NS available that are compatible with ISY? 

The counter is for tracking how long the output was turned on.  The value is sent via email when the output turns off, and again when the output turns on, indicating how long it was on last time.  This is why we zero it after we send the email notifying of the output turning on.  Both emails include details on what zones are on, and key temperatures. 

There is also a status email sent each time a zone turns on or off.  This creates A LOT of emails, but for now, until I know the program is doing what I need it to do, it will stay as is.  I am working towards queueing up the data and emails once every 5 minutes (if there is information to send).

I am also going to be adding run times for each zone, and off times for each zone.  Next will be summary stats for each zone for each day.  The ELK used to control this, but yesterday I moved that code to the ISY.  The ELK was at 98% of code space used so I had no space left to do much more.  Taking this code out freed up 14%.  There is a lot more code to more from the ELK to the ISY.  We can't move anything that controls lighting because the lighting in not compatible with ISY.  ISY will export lighting to the ELK, but it does not support importing lighting from the ELK.  Is there an NS for ISY to communicate with CentraLite Elegance through RS232?

I know the ISY stores the data and time a variable was last changed.  Is there a way to show that in an email?

Still learning ISY and appreciate all the help form everyone.

[apostolakisl]

There is a partial list of node servers on this forum under "polyglot node servers".   To see the full list you need to install polyglot (the node server host software) onto your raspberry pi (or similar) and browse the list.  FYI, Elk is no longer going to be supported on ISY when it moves over to the new polisy hardware (polisy is the in-develpment isy next gen device).  At that point you will need to use the Elk NS instead (which is currently in beta but working pretty well).  Node Servers have the advantage of being able put all the nodes (for Elk a node would be any zone, output, armed status, or similar) into scenes.  With the Elk node server (not the Elk module you currently have), you can put Elk zones/outputs/etc directly into scenes and skip the programs.  So you might have an Elk zone that when violates turns a light on directly, no program needed.  All of the nodes work that way.  Like I could put an Elk armed status into a scene with Roomba.  When I arm away, it would vacuum.  Or I can directly link a light switch to an Elk output by putting them into the same scene (turn on light and output turns on).  And so on with any of the nodes.

[IT Solutions]

@apostolakisl Thank you for the information.

New technology with more features is always nice, but adding another device in the mix adds another point of failure, which is a bad idea.  When looking for reliability, one needs to minimize the single points of failure.  We will not be moving to the Polisy hardware.  Too many points of failure.

BTW, we created our own "Node Server" for ELK that enhances the email capabilities of the ELK (they are very limited) using an RPi.  We  also configured the ELK to monitor the RPi and the RPi to monitor the ELK using a dead man/heart beat system. If either one fails to send the heart beat signal, the other one notifies of the failure.  Redundancy and active monitoring are the keys to reliability. 

[DennisC]

Here is a link to the Polyglot Nodeserver Store to see all of the Nodeserver a that have been created.:

https://polyglot.universal-devices.com/

Currently, you can run these Nodeserver via a Raspberry Pi or a Polisy. Soon however, Nodeserver will only be supported on Polisy. This is expected to happen when Polyglot v3 comes out. 

In addition, some Nodeserver can run from a cloud version of Polyglot available thru the ISY Portal.

At some point in the future, the software running on the ISY will be moving over to Polisy, and the ISY will be phased out.

[apostolakisl]

As mentioned by @DennisC, the end point is that everything will co-exist on the Polisy hardware platform.  Based on the push to get the Elk NS finished, I suspect they are pretty close to releasing the all in one Polisy solution.

[IT Solutions]

@apostolakisl @DennisC Thanks for all the information.

Having it part of the Policy box is much better than having it run on a different box.  Hopefully it will support control for ELK lighting and give us access to ELK Counters and Custom Values.

What does Policy have that ISY does not that will make one want to switch?  Is there a way to load ISY programming into Policy, or does one need to start over?

[apostolakisl]

I'm quite sure you will just back up your ISY and then restore it to polisy.  @Jimbo is writing the Elk node.  You would have to ask him about Elk counters and custom values, at present that is not on his todo list.  He pretty much has everything covered that is currently in the Elk ISY module plus he is going to add "last user".  Access to tasks, custom values, and counters is not on the list.  Jimbo seems to be pretty good at writing the node, however, and perhaps you can get him to add those things. 

[DennisC]

I'm not sure I see the need to add Elk Counters to the Nodeserver. If you are programing in the Elk you use the Elk Counters. If you program in the ISY, you use an ISY variable, which works in the same fashion but is easier to work with.

[Jimbo.Automates]

Yes, counters and lighting are on the list https://github.com/jimboca/udi-poly-elk/issues

 

[IT Solutions]

@Jimbo Thank you for that information.  What about Custom Settings?  Are we going to have access to them?  They are a little more complicated because each one can be a number, a timer, or a time of day.

Being able to tell the ELK to run a Task would also be helpful, like Run Task #XX.  Syncing the Task names would also help, but it not needed.

We have been installing and programming ELK M1s for over a dozen years.  If you have any ELK questions, we would be happy to help in any way we can.  I personally know the top two Tech Support people at ELK.  Odie (see picture) and I visited their corporate offices about 10 years ago.  It is quite a big operation.

ISY is the ONLY product ELK is currently recommending for ZWave integration with the ELK, but they know little to nothing about it.  ISY really adds a lot more to the ELK M1 than just ZWave.

 

[IT Solutions]

@apostolakisl

On 2/14/2021 at 6:26 PM, apostolakisl said:

  Your timer sticking at 3 is really not possible.

Well, we have done the impossible, again.  This time it stopped counting at 511.  Other than displaying the value in an email, the there are only two references to the counter variable in the programs:

Floor Heat ON/OFF Actions - [ID 0011][Parent 0015]

If
        Elk Output 'Floor Heat Contr' is On
    And Elk Output 'Floor Heat Contr' is not Off
 
Then
        Send Notification to 'ELk Logs' content 'Floor Heat ON'
        $S.Floor.Heat.Run.Timer  = 0
        Repeat Every  1 minute 
           $S.Floor.Heat.Run.Timer += 1
 
Else
        Send Notification to 'ELk Logs' content 'Floor Heat OFF'
 

and:

Master Bath Time Limit - [ID 0016][Parent 0010]

If
        $S.Floor.Heat.Run.Timer >= 60
    And $S.FH.Zone.Count <= 1
    And Elk Zone 'FlHeatZ7-MBath' is Violated
 
Then
        Set Elk Output 'Floor Heat Contr' Off
 
Else
   - No Actions - (To add one, press 'Action')
 

The ISY programs continue to run and we continue to get emails showing other variables changing, but the counter sticks at 511 until it reset to 0, and then it starts counting again.  It was stuck for almost 14 hours.

[MrBill]

Does the folder that the program is in, OR A FOLDER ABOVE in the tree, have any folder conditions?   That was your problem in another thread.

[apostolakisl]

@IT Solutions  If the program in the program tree shows a solid green icon, then it is currently executing a "then" (solid red for "else"), or in your case, counting once per minute.  Please note, this is different than a green strip at the left side of the icon which means that the last time it ran, it ran "then", but is currently not running anything.  In my example below, "Elk Temp" is running a "then" loop (this posts the current outdoor temp to my Elk keypads once every 5 minutes), while "Disarm" is not currently running, but last time it did run it ran "true".

 

Anyway, if it is is solid green, and the counter is not moving, then this is basically impossible unless your system has hung.  ISY isn't like windows, it pretty much never "hangs", but I suppose it is possible.

I don't think folder conditions or anything else matters here.  If the icon is solid green, the "then" clause is running.  

The only other, and unlikely possibility, is you have some other program that keeps putting the variable back to whatever it is "stuck" on every time the counter tries to increase it.

[IT Solutions]

@MrBill Thank you for that idea, but I had already checked that and have no conditions on folders.