v3.1.23 in Beta ; Three new "timer relay" devices

[sjenkins]

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 5 hours ago by sjenkins

[Guy Lavoie]

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!

 

 

[sjenkins]

@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 yesterday at 05:35 PM by sjenkins

[Guy Lavoie]

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 23 hours ago by Guy Lavoie

[hart2hart]

@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?

[sjenkins]

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 19 hours ago by sjenkins

[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. 

[hart2hart]

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

[Guy Lavoie]

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.

[hart2hart]

@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?

[sjenkins]

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. 
 

[hart2hart]

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.

[Guy Lavoie]

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)

[hart2hart]

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"}