Pre-amble:

When I started with my shiny new 994 over 10 years ago I was struck with
  something missing.  The environment was familiar, with a state machine
  controlling I/O.  As a young engineer almost 40 years ago I did my share
  of PLC programming.  Scenes were new, but made sense.  But the timers were
  missing.  From relay logic days or PLC ladder logic, I was missing my
  on / off timer relays. 
I use timers all over the place on my (994, Polisy, Eisy) and always
  considered them a bit of a PITA to set-up and maintain.  Turn-on a light
  group which I want to turn off in 10min takes a scene, static variable,
  set the init so you have persistence, then usually have a program for
  LightON, LightCountdown, LightOFF, depending on the trigger conditions.

So, sorry for the pre-amble but that is why these three new devices exist.

Virtual offDelay, onDelay, Toggle
Please try them out, see if the behaviour is how you would like ; try to break them!

EDIT: lots of profile changes here, so may require a reboot if your labels are not coming up right, especially with new AC and  EISY-UI.

 

From the github README: Link added here
(note, the README is not the plugin CONFIG file which contains config pointers)
let me know of any doc improvements. I tried to up the game a bit on them.

 

offDelay switch

Usage: 
    Replaces programs simulating timers used to switch scene off after delay time.
    For example you turn on a light scene which you want to turn off after x-seconds.
    The scene is switched on by a switch/program & fires offDelay, after
    x-seconds the scene is turned off. 

if Switched: 
    On (DON) when ST Off/On, ST status set to TIMER, CMD (DON), after DUR (DOF).
    On (DON) during ST TIMER, reset the time, CMD (DOF) sent AFTER DUR seconds. 
    Off during TIMER, ST status changes to Off, CMD DOF sent immediately. 
    Fast On / Off mirror On / Off

Set: 
  delay (DUR) to delay seconds for switch, after CMD DON wait to send DOF. 
  range 0 - 99999 seconds which gives you more than 24 hrs. 
  if 0, mostly acts like a regular switch. 

Status: 
  Off(0), On(1), TIMER(2) 
  When plugin is stopped, if ST is TIMER, ST will be set to On for persistence. 
  Using Thread timers to fire switch, so for now I am not showing a status of
  how long left in the timer. Trying to keep a low overhead. 

 

onDelay switch

Usage: 
    Replaces programs simulating timers and scene trigger for transition
    from one scene to another. For example you turn on a high level light
    scene which you want to transition to a normal level later. 
    Use two scenes, one High, one Normal/Low, switch on High for x-seconds,
    after delay then transition to Normal/Low. 
    High scene:  onDelay is Responder, set delay (DUR) to x-seconds 
    Normal/Low scene: on Delay is Controller in Normal scene, sending
    appropriate commands to each device. 

If switched: 
    On (DON) when ST Off/On, ST status set to TIMER, CMD (DON) after DUR delay. 
    On (DON) during ST TIMER, reset the time, no CMD sent until DUR complete. 
    Off (DOF) during TIMER, ignore until TIMER done. 
    Off (DOF) when ST Off/On,  ST status set to Off, send DOF immediately. 
    Fast On (DFON) behaviour is equivalent to on (DON). 
    Fast Off (DFOF) anytime to set ST status to off, CMD (DFOF) sent immediately;
    this method to cancel is used to allow use and control in a scene. 

Set: 
  delay (DUR) to seconds switch will, after receiving DON, wait to CMD DON. 
  range 0 - 99999 seconds which gives you more than 24 hrs. 
  if 0, mostly acts like a regular switch. 

Status: 
  Off(0), On(1), TIMER(2) 
  When plugin is stopped, if ST is TIMER, ST set to On for persistence. 
  Using Thread timers to fire switch, so for now I am not showing a status of
  how long left in the timer.  Trying to keep a low overhead. 

 

toggle oscillator

Usage: 
    Replaces anywhere you want a scene to oscillate On/OFF.  It does not need
    to be balanced, so allows you to be Off for long periods and On for a
    short one.  Can of course be used to trigger programs on a regular
    interval as well.  An obvious example is blinking Christmas lights.
    Another would be for attention getting or security flashing.
    Firing a program at regular intervals can be pretty useful.

If switched: 
    On (DON) when ST Off/On, ST status set to onTimer, CMD (DON) immediately. 
    On (DON) when ST onTimer/offTimer, timer reset,  CMD (DON) immediately. 
    Off (DOF) when ST onTimer/offTimer, no effect. 
    Off (DOF) when ST Off/On, ST status set to Off, CMD (DOF) immediately. 
    Fast On (DFON) same as On (DON). 
    Fast Off (DFOF) all ST, ST set to Off, CMD (DFOF), cancel further
    oscillations; this method to cancel is used to allow use and control in
    a scene. 

Set: 
  onDur (DUR) to seconds switch will, after sending DON, wait to CMD DOF. 
  offDur (GV0) to seconds switch will, after sending DOF, wait to send DON. 
  range 1 - 99999 seconds which gives you more than 24 hrs for each On / Off 
  if either timer <= 0, it will be reset to 1 

Status: 
  Off(0), On(1), onTimer(2), offTimer(3)  
  When plugin is stopped, if ST is onTimer, ST set to On for persistence. 
  When plugin is stopped, if ST is offTimer, ST set to Off for persistence. 
  Using Thread timers to fire switch, so for now I am not showing a status of
  how long left in the timers. Trying to keep a low overhead. 

Edited October 9Oct 9 by sjenkins

Interesting that you bring up timers. In fact this was one of the first subjects I posted about when I first got started with a ISY994i just over a year ago. Where are the timers? I also come from a PLC world with ladder logic, and my first home automation controller was the Applied Digital Ocelot, which has timers that can be treated just as variables. I found out that you can create timers in IoX with a variable that increments after waiting 1 second, but this isn't as clean, and the unpredictable order of execution of IoX programs (which is also contrary to proper PLC logic) makes that a bit less reliable for short intervals.

Forward about 6 months later (and much learning) I started learning about plugins and although the documentation is very sparse, I managed to create a simple plugin that I called Timers, that replicates the functionality of the Ocelot timers. Just as many of us name state variables with s_xxx and integer variables with i_xxx, I name my timers with t_xxx so that they're easily recognizable in programs, but are otherwise useable like variables. They certainly have been useful. Here is a screenshot of what they look like:

Just like with the Ocelot, I made mine increment once per second of they're set to a non-zero value. They're handy for stepping through time separated steps of macros, and aren't subject to early termination like Wait statements (because of the triggering event no longer being true). If I only want a simple time interval, I can set one to a negative value. For example set it to -5, and five seconds later it will roll over to 0 and stop automatically.

Here is an example of how I use one for the ubiquitous bathroom fan timer application:

If
        'Timers / t0_toilette' raw data 0 > '$i_toilette_temps Raw'
 
Then
        Set 'Timers / t0_toilette' Raw value 0
        $i_toilette_temps  = 0
        Set 'T2 Toilette Fan' Off
 
Else
   - No Actions - (To add one, press 'Action')
 

 

Now that we have an actual person who produces distributed plugins recognizing the need for timers...we're getting there! If you can make generic variable-like timers, that would be a great addition!

 

 

@Guy Lavoie, you made me smile ; good to have a kindred spirit out there.

( was once a controls engineer, from Canada, born in Montreal)

So these ones have the added advantage of being able to be part of a scene.

So your above program could be replaced by a scene.

=========

Toilette Fan Scene
  Toilet Fan (responder)
  Toilet Fan offDelay(control)
   {switch and/or motion device which starts the fan} (control) 

with Toilet Fan offDelay DUR set (either manually or with a program) to how many seconds to keep on (600 if you want to be conservative for a 10min clearing of the air)

===========

OR:

you can use it in a program like your example above but after you switch on the offDelay  the prog is:

if:

Toilet Fan offDelay is switched OFF

then is:

Set or Switch Toilet Fan OFF

==============

would need a simple program to fire the offDelay:

if:

{switch and/or motion device which starts the fan} switch ON

then:

Toilet Fan offDelay switch ON

=============

As I mention in the docs, I did not include a variable which tracks the countdown.  Much more overhead than the Threading Timer structure.   These three should cover 90% of use cases.  Open to talk about those 10% though.

Using these devices I have started replacing the variables and programs which simulate timers across my house.  I am about half way in and have wiped out dozens of them.  Helps with readability & maintainability. 

 

Edited October 8Oct 8 by sjenkins

I get that. The advantage with your approach is that it can all be done by creating a scene, avoiding programming. That's one thing I've learned from reading everything on the forum for over a year: not every UDI user is from a programming background, and there are often requests for a more "canned" approach, avoiding the need to program. In that regard, your latest addition is certainly filling a need. You're adding to the scene capability, just like with virtual switches. Keep it up!

(now back to my selfish little world)... I'm a geek, I like having basic building blocks that I can use to make up fancy stuff that's often more fun creating than actually using once finished. It's an incurable disease! There must be a support group out there somewhere... In the case of my bathroom fan program, you'll notice that it's comparing the timer value to an integer value, not to a fixed number. The reason for that is that there are a few other programs related to this be all, end all bathroom fan routine. Why make things simple when you can make them complicated? Hehe. It's because if I turn on the fan and the timer isn't running, then it sets an initial time value of 600 seconds (10 minutes) and starts the timer:

G2 toilette 1 fan debut - [ID 0010][Parent 0016]

If
        'T2 Toilette Fan' Status is On
    And 'Timers / t0_toilette' raw data 0 is 0
 
Then
        $i_toilette_temps  = 600
        Set 'Timers / t0_toilette' Raw value 1
 
 

-- If however a control event comes from the same switch and the timer is already running, it's because I want to add running time (let's just say that this particular trip to the bathroom was challenging..), so it adds another 240 seconds (4 minutes), and will allow time to be added up to two instances of 4 additional minutes:

G2 toilette 2 fan ajout temps - [ID 0007][Parent 0016]

If
        'T2 Toilette Fan' is switched On
    And 'Timers / t0_toilette' raw data 0 > 0
    And $i_toilette_temps < 1080
 
Then
        $i_toilette_temps += 240
 
 

-- When the timer value is reached:

G2 toilette 3 fan fin - [ID 0008][Parent 0016]

If
        'Timers / t0_toilette' raw data 0 > '$i_toilette_temps Raw'
 
Then
        Set 'Timers / t0_toilette' Raw value 0
        $i_toilette_temps  = 0
        Set 'T2 Toilette Fan' Off
 

-- And finally, if the switch is turned off manually:
 

G2 toilette 4 fan off manuel - [ID 0006][Parent 0016]

If
        'T2 Toilette Fan' Status is Off
 
Then
        $i_toilette_temps  = 0
        Set 'Timers / t0_toilette' Raw value 0
 

You can see why I like to treat the timer like a variable. This is how it would probably be done with a generic PLC. 

I also use a timer in my garage door programs, to create a lockout timer (to ignore additional commands) while a triggered open or close is underway.
 

Edited October 8Oct 8 by Guy Lavoie

@sjenkins great addition! I’m not clear how to configure and use.

I want to use an offDelay switch so I’d create the virtual switch and add it to a scene with water closet physical fan switch. When the physical fan switch in the bathroom is turned on that would start timer to turn it off. Is that right?

If that’s right, how would I define the virtual offDelay switch with a 15 minute delay to turn it off using json notation?

1 hour ago, hart2hart said:

@sjenkins great addition! I’m not clear how to configure and use.

I want to use an offDelay switch so I’d create the virtual switch and add it to a scene with water closet physical fan switch. When the physical fan switch in the bathroom is turned on that would start timer to turn it off. Is that right?

If that’s right, how would I define the virtual offDelay switch with a 15 minute delay to turn it off using json notation?

Hey @hart2hart,

You can create this node in any of the three config methods (I did update the config text manual) but right now I don’t have it where you set the delay there (I could add to my todo to have an initial value field; if that would be value add). You can pull the device up in the AC or eisy-ui and manually enter it. Or you can make a small program which runs on startup to load the device delay. You also can change the delay time when you like; the delay would be effective on the next On switch. 
so json:

82  {"type": "offdelay", "name": "office lt offDelay"}

would work. 
you are correct on your thoughts on scene usage, in the scene add the switch as a controller, the fan as a responder, the off delay as a controller. 
when the switch turns on, the fan comes on, onDelay receives DON and after delay seconds, sends DOF to the scene and shuts it off. Depending on the device or devices in the scene you may want to modify the command offDelay sends to each device in the scene. 
 

hope this helps. 
read the README in the GitHub (link in config file which you see on the config tab in the plugin. Ask any follow-up questions here, anytime. 

Edited October 8Oct 8 by sjenkins

@Guy Lavoie,

I completely get it, it’s my wife that doesn’t ;). (Actually she is very gracious).  I do similar things in my progs with the “bump” times. So take a look at my description of the onDelay, it can simplify the moving from one scene to another. Different paradigm but we can get to the result and simplify too. So in my example I go from a high level at my bar to the normal level after a period of time. Well if you wanted to “bump” the time you can either change the delay value and bump the timer or have a second timer. This would give you your initial and bump times. I guess my point is this is not just for non-programmers, I wrote it (like you did for timers) to clean up the non-value added countdown programs & leverage scenes. 
I am interested if there are features that would enable what you are doing more. 
good discussion, thanks. 

Hey @hart2hart,
You can create this node in any of the three config methods (I did update the config text manual) but right now I don’t have it where you set the delay there (I could add to my todo to have an initial value field; if that would be value add). You can pull the device up in the AC or eisy-ui and manually enter it. Or you can make a small program which runs on startup to load the device delay. You also can change the delay time when you like; the delay would be effective on the next On switch. 
so json:

82  {"type": "offdelay", "name": "office lt offDelay"}

would work. 
you are correct on your thoughts on scene usage, in the scene add the switch as a controller, the fan as a responder, the off delay as a controller. 
when the switch turns on, the fan comes on, onDelay receives DON and after delay seconds, sends DOF to the scene and shuts it off. Depending on the device or devices in the scene you may want to modify the command offDelay sends to each device in the scene. 
 
hope this helps. 
read the README in the GitHub (link in config file which you see on the config tab in the plugin. Ask any follow-up questions here, anytime. 

I typed that and then went out fur a run. Got about 2 miles from home when answer came to me. Define it like all my other virtual devices and the delay will show up on the created device. Oh well a dense moment passed.

Thanks ,

Paul

2 hours ago, sjenkins said:

good discussion, thanks. 

It certainly is. I like discussing nuts and bolts.

I'll certainly be giving your updated plugin a try soon, on my test controller.

@sjenkins I like the functionality a lot. When I do same with programs controlling something like an electrical motor fan, I typically put

Turn off
Wait 1-2 seconds
Turn off
Wait 1-2 seconds
Turn off

This ensures the switch and device being controlled will almost certainly be turned off even if electrical noise from fan motor occasionally gets through. Does that make any sense here?

1 hour ago, hart2hart said:

@sjenkins I like the functionality a lot. When I do same with programs controlling something like an electrical motor fan, I typically put

Turn off
Wait 1-2 seconds
Turn off
Wait 1-2 seconds
Turn off

This ensures the switch and device being controlled will almost certainly be turned off even if electrical noise from fan motor occasionally gets through. Does that make any sense here?

Well I don’t disagree, sometimes a scene just seems to work. Also the nice thing in a scene you can often set it to try more than once right in the command setting. 
 

10 hours ago, sjenkins said:

Well I don’t disagree, sometimes a scene just seems to work. Also the nice thing in a scene you can often set it to try more than once right in the command setting. 
 

Thanks.  In this case, Advanced / PLM Communications is not shown for the OffDelay virtual device, and it says "This device does not support PLM communication settings for the physical device in the scene.

 

Am I missing something deeper / simple?  As I recall, you can only set scene retries by device in a scene and I can't seem to do it for either device in this scene.

I'm trying this out, and not getting very far. I added one custom parameter to my updated Virtual plugin, but I get a "bad configuration" error when I restart it. Error log complains:

Controller:_handle_json_device: JSON parse error for key '95' with value 'ondelay': Expecting value: line 1 column 1 (char 0)

5 minutes ago, Guy Lavoie said:

I'm trying this out, and not getting very far. I added one custom parameter to my updated Virtual plugin, but I get a "bad configuration" error when I restart it. Error log complains:

Controller:_handle_json_device: JSON parse error for key '95' with value 'ondelay': Expecting value: line 1 column 1 (char 0)

I tried the simple form of the conf and got similar issue.  Switched to using json form of config and it worked.  @sjenkins , I declared it this way with colon and the colon was stripped in eISY created device but doesn't happen for standard dimmer and switch types. 

 

{"id": "98", "type": "ondelay", "name": "Office:Closet Timer On"}

Ok I figured out where the bug is. In the Controller.py file, the new options need to be added to the parameter validation routine:

I now have it all working. 😀

Nothing like having new options. Thanks for keeping this great plugin up to date with new features!

With the toggle option, we can now add turn signals to our eisy!

 

 

1 hour ago, Guy Lavoie said:

Ok I figured out where the bug is. In the Controller.py file, the new options need to be added to the parameter validation routine:

I now have it all working. 😀

Nothing like having new options. Thanks for keeping this great plugin up to date with new features!

With the toggle option, we can now add turn signals to our eisy!

 

 

Thanks, I’ll add that tonight. 
as well need to add more to my testing routine 🫢🙈

Edited October 9Oct 9 by sjenkins

4 hours ago, hart2hart said:

I tried the simple form of the conf and got similar issue.  Switched to using json form of config and it worked.  @sjenkins , I declared it this way with colon and the colon was stripped in eISY created device but doesn't happen for standard dimmer and switch types. 

 

{"id": "98", "type": "ondelay", "name": "Office:Closet Timer On"}

Sorry, I’ll fix the simple version tonight. My bad. 
the colon is being stripped by the polyglot device name function. 
its newish & must not like colons, I hadn’t back factored to the earlier devices. I’ll check with udi and see what they think on this. 

ok @Guy Lavoie, @hart2hart, 

fixed the simple issue. Please keep trying to break this.

I also, to @hart2hart, thought that it might be useful to be able to define in the json or yaml starting numbers.  I have not pushed the commit, but will test a bit and roll that as a minor change to the beta.

The docs are also being written as I go here.  Please take a look and give some feedback with the hat of a new user.

 

I'm checking out the various modes. This will be important for your documentation. Let me know if I have it figured out right so far:

ondelay switch: The virtual ondelay switch has three possible statuses: Off, Timer, or On.

The status of the switch will be updated to "On" after a set delay when it is first turned on by a On command (from a program or scene). During the set delay, the status will be "Timer". The delay in seconds is set by the onDelay parameter, and can be set as a fixed value, or from a variable value. The On trigger is control event based, and will retrigger the delay from zero if a new On control event is received while the timer delay is underway. So a series of On control events will delay the transition from Timer status to On, until the timer is allowed to run out without a new On control event.

A forced off (FOff) control event will immediately cancel a ondelay switch that is in the timer phase to Off, or turn it Off if it's On. A Off command will turn the ondelay switch to Off if it's On. An Off command during the timer phased will be ignored.

offdelay switch: has the same characteristics as ondelay, with the following differences: It has no On status. It will go from Off to Timer status if triggered with a On control event, and the timer can be retriggered just like the ondelay switch. Once the timer phase expires, it will go back to Off status. This is meant to be used to trigger the detection of it's status going to Off.

 

I'll have to experiment more with the toggle to see exactly how it works.

 

 

@Guy Lavoie,

You’ve got it. So my next question is, I documented that in the readme (above, first post), would you have gotten that from my text?  I basically did it as a list of if’s when you switch it, or change status. As opposed to your story method. 
 

No, I actually derived my explanation from trying it out, as a "black box" discovery process. That's what I figured would be a good independent verification, and part of trying to "break it" 😉 . I did see your initial description, though it's rather cryptic to someone not yet familiar with it:

(On (DON) when ST Off/On, ST status set to TIMER, CMD (DON), after DUR (DOF)...

I preferred to stick with a cookbook style explanation, using the familiar terms we see for IoX, which should help other people discover and use this meaningful addition to an already useful plugin! Thanks again!

But the essence is that it seems to be doing what you intend it to do, and will surely be appreciated. I've been mentioning the Virtual plugin many times as a solution to some user's questions.

11 minutes ago, Guy Lavoie said:

No, I actually derived my explanation from trying it out, as a "black box" discovery process. That's what I figured would be a good independent verification, and part of trying to "break it" 😉 . I did see your initial description, though it's rather cryptic to someone not yet familiar with it:

(On (DON) when ST Off/On, ST status set to TIMER, CMD (DON), after DUR (DOF)...

I preferred to stick with a cookbook style explanation, using the familiar terms we see for IoX, which should help other people discover and use this meaningful addition to an already useful plugin! Thanks again!

But the essence is that it seems to be doing what you intend it to do, and will surely be appreciated. I've been mentioning the Virtual plugin many times as a solution to some user's questions.

I tend to agree.  I understood what you had had written in readme after I used it in discovery mode. 

Now trying out the toggle mode. I'm not quite sure what the "Off" button is meant to do. I'd tend to see it as needing only 3 buttons: Start, On, Off. Start starts the timed toggles, while the other two set the status to On or Off, just like a regular switch. A fancier version could have two Start buttons: Start On to alternate starting with the timed On, and Start Off to start with the timed Off.

Just some thoughts.

 

Edited October 10Oct 10 by Guy Lavoie

1 hour ago, Guy Lavoie said:

Now trying out the toggle mode. I'm not quite sure what the "Off" button is meant to do. I'd tend to see it as needing only 3 buttons: Start, On, Off. Start starts the timed toggles, while the other two set the status to On or Off, just like a regular switch. A fancier version could have two Start buttons: Start On to alternate starting with the timed On, and Start Off to start with the timed Off.

Just some thoughts.

 

Appreciate the thoughts @Guy Lavoie

The Off button (documented in original post & README), you are right is of questionable usefulness.  It will turn the status from On to Off if the toggle is not in one of the two TIMER statuses.

The reason for not using a specialized Start button is scenes don't play well will that.  DON, DOF, DFON, DFOF, and sometimes OL, are really your only command options.  From what I have seen so far you are mainly a program guy, but @Diesel is mainly a scene guy.  So in the design of these devices I have tried to bridge the gap, make it useful for both, as well as keep fairly standard to how the Insteon devices operate.

I did think about another toggle to start off, but could not really think of a use case which I couldn't achieve with a wait statement or a thoughtful set of triggering.  I would like to keep this clean & not add complexity if it doesn't fill a defined gap.

Hope that helps.

Fair enough...you're wanting to keep it within the realm of scene commands. That's why we're brainstorming. Yes, I'm a program guy. If it weren't for the programmability, I probaby wouldn't be a UDI user! Nothing wrong with having the extra commands for programs either! 😆