Big Timer

tmp17DBBig Timer is probably the best timer for Node-Red, providing a general purpose timer as well as  handling summer/winter correctly as well as (importantly) lighting up time (for which it needs longitude and latitude). After all you probably don’t turn the outside lights on at 6pm!! You turn them on when it gets DARK.

Updated to v 1.5 – February 18, 2017

BigTimers

Why: Existing timers didn’t do what I wanted – also – I have a watering system – I want it to run at dusk and dawn every day – but not in December through February (ice)!  I had to have control over both days of the week and months. Existing timers didn’t do that either. Many seemed to be based on the old mechanical timers but without moving parts. That won’t do.

Firstly: the name. It’s a timer – but it’s a BIG one – so I’ve called it BigTimer. (note: the original scheduler is no longer developed – BigTimer does everything Scheduler does and much, much more).

Secondly: it has an input. You can inject various words into BigTimer – and get instant over-ride action. "1" or “on”, "0" or “off”. "auto" or  “default” etc. 

Does that need explaining? “on” for manual override to on, “off” for manual override to  off (both of which reset on the next auto state change), “default” or “auto” to return the timer to normal operation.

If you set the timer to come on, say at dusk and off at midnight, you can override the setting during the day by sending “on” to the input. This override will reset at the next auto change of state.

If you inject "manual" in conjunction with  “on” and “off”, the state will change until the set timeout (in minutes) times out - so if you turn the lights on in manual and forget you did it? The unit will return to default operation in X minutes (which you can set - defaulting to 24 hours - 1440 minutes) after any manual change you make. You can also send a "sync" command which simply outputs the current state with a side effect of decrementing the timeout counter - handy for testing.

Here is a test setup for BigTimer, just using simply injection nodes:

BigTimer test setup

And here’s what happens if you press ON (a simple inject – you can send that message in the payload by any means you like)…

Bigtimer test setup[6]

But what are those other two outputs?

Output 1: is a message – you control the topic and payload – so I use it, for example, as I do, to send a message to MQTT to control something. You can have this message go out once – or every minute. There are other components to the msg object on the first output, there for information only.

Object

In this example (version 1.5.0 of Bigtimer onwards) you see various items in the output -also note that this view is in Node-Red 0.16.2 which is different to older versions – I strongly recommend you upgrade if using an earlier version.

You can see msg.payload which is whatever you put in there to go off to, some other node to make something happen. In addition and for information only we have msg.state, msg.value, msg.AutoState, msg.manualState and others. You can ignore them but handy for checking. msg.state shows “on”, “off” or “none” and in the case of the first two (on/off) msg.time shows the time for the next change (version 1.2.86 and above)

Output 2: outputs a 1 or 0 every minute when checking (in msg.payload) – you can use that to light up something.

Output 3: puts out another text message in msg.payload which you can set – I point it to a speech synth so it might say “external lighting coming on”. There is one message for the ON state, another for the OFF state. Ignore it if you don’t have a use for it.

And to get this node?

Make sure you are in your Node-Red installation folder (for example /home/pi/.node-red) and type:

npm install node-red-contrib-bigtimer

So in my case, I keep all my nodes under /home/pi/.node-red/node-modules.  So I do the install from /home/pi/.node-red

Restart Node-red and Bob’s your uncle – it should appear on the left with the other Nodes. If you happen to have the ADMIN node in Node-red you don’t even need to do any of that – you can install node-red-contrib-bigtimer straight from the admin tab.

In addition, I have recently,  as a response to a sensible request from one of our blog readers, changed the code so that if either the ON payload or OFF payload is blank – then no message will be sent at that time – this means you can now easily OR timers together. So if you need several time intervals in a day or other complicated setup you can simply use a number of timers and feel the first output to one common destination!

Here’s an example of TWO timers simply sending stuff to a debug node for testing…

two BIGTIMERS

Backtrack for Newbies: Node-Red is a simple-to-use but very powerful visual tool for wiring the Internet of Things and a tool for connecting together hardware devices, APIs and online services in new and interesting ways. I control a range of Arduino and ESP-8266 devices using a Raspberry Pi2 (RPi3 would be even better but I’ve not yet noticed a slow down despite having many, many nodes in Node-Red) as my central controller using the Jessie operating system as of late May 2016 as it now has an excellent backup system. You can of course run Node-Red and the other tools I use on a wide range of machines – Orange Pi, Roseapple Pi, Odroid C2 etc using Debian, DietPi, Xenial etc. I even have my normal installation script running on a laptop using Mint Linux.

tmp871On this particular Pi I run MQTT (Mosquito with Websockets), SQLITE, APACHE and Node-Red. I started using Blynk as my mobile remote controller then went on to using ImperiHome but today I concentrate on using Node-Red Dashboard which has so very much potential.  I also use Nextion touch-LCD display devices for local displays. All of this can be managed within Node-Red. If you find this interesting you might like my  home control 2016 post here or the Nextion Wi-Fi Touch Display article.

Here (as requested): to the right is a screenshot of a typical setup… click on the image to enlarge.

So in total you have a timer you can set to go on and off at specific times of the day, or dusk and dawn, on certain days, certain months, you can even set it to run on specific days of the month (Christmas day?) or even certain weekdays of every month (second Tuesday).

You can tick a box to have it output on power-up or not, you can tick a box to have it auto-repeat the message every minute or not. You can add positive and negative offsets to the times (including dusk and dawn etc.), you can optionally add your OWN offset to the UTC time of the host computer and you even select a random value within the limits of the offsets (security lighting etc.) You can temporarily suspend the schedule via a tick box or a message.

And here are the words the node will accept at the input to override automatic operations. The input is not case-sensitive.

on (or 1)

off (or 0)

manual

auto (or default)

stop

sync

In the drop-down boxes for on and off times you can select times or words like dusk,dawn, sunrise, sunset, night etc. All are dependent on the longitude and latitude you put into the relevant boxes and will adjust every day as necessary.

The best way to learn is to put a debug node on the top output – and inject text payloads (using the INJECT node) to the inputs as demonstrated above.  Have fun. I could not manage without this node.

Out of the first output as well as the normal msg.payload, you can extract msg.state which might be “on”, “off”, or “auto” – and msg.value which might be 1 or 0.  This is so that if you are using say, ImperiHome and store states in global vars, if the time reverts back to auto, you can let ImperiHome know what is happening.

If you make good use of this node – please put a link to this blog entry somewhere in your writings so people will come back here. Or if proves REALLY useful you could feed my Ebay habit – there’s a link on the right of the blog.

Enjoy and please do report any issues back here.

Facebooktwittergoogle_pluspinterestlinkedin

206 thoughts on “Big Timer

  1. Hi Pete I have installed several nodes now on my raspberry pi. Including Big Timer

    I'm typing

    cd $HOME/.node-red
    npm install

    They all appear to install correctly but none appear in the left hand pallet on the web page.

    The Npm has loaded them all into a directory in my home directory called nodemodules (from memory) anyone else had issues like this ?

    Much appreciated.

    1. If you are in the .node-red directory and you type for example

      npm install node-red-contrib-scheduler

      They SHOULD end up downloading and installing themselves in .node-red/node-modules

      If that is exactly what you have done - and they're still not there - try asking the guys at the Google+ Node-Red forum.

      Another way is to move the directories to under .node-red/node-modules - that might do it and if not - having done that go into EACH directory and type npm install
      The latter on it's own with no arguments assumes you already have the stuff in place.

  2. Just moved the modules to node-red/node-modules & most have appeared in the pallet now. Npm still puts files into my home/pi/nodemodules folder but for now it's not an issue moving afterwards. Thanks for your support and interesting blog Peter.

    1. And thank you for taking an interest. Latest update I've moved all my nodes into my own section - again move to .node-red dir and do npm install node-red-contrib-XXXXX where xxxx is bigtimer, scheduler, grove, thermostat, esplogin. Bigtimer the most useful. That command also does for updates...

  3. Just to follow up on this I found if I installed packages like this CD into directory

    cd $HOME/.node-red

    And then

    sudo npm install -g package-name

    The packages were then installed in the correct directory
    I followed the official install procedure for the raspberry pi when installing nose red and installed it as a global user so the -g switch puts the nodes in the correct directory

  4. After install bigtimer, as soon as I open a new node red page and before click on anything, I can see the small bigtimer icons and checkboxes aligned in the left side and bottom of the page. And when I select the bigtimer icon it only shows a box with the option to change it´s name and nothing else... Any ideia of what is wrong?

      1. Ah, excellent - well I'm glad someone is having a good day. Once again my limited knowledge of Linux is getting in the way. I've spent the afternoon getting Java 9 running on my diskstation so I can run BLYNK on it - works a TREAT - but can I HELL figure out how to make it run on startup - the Synology Diskstation is VERY different to the PI!

  5. Just an idea you can fire up a terminal on the synology I guess that's how you installed your software. What about adding a cron task to run your BLYNK at startup. I'm sure I have read you can access Cron from the terminal on synology . Cron can also be used to run items on a schedule node-red uses it on the inject. On the pi you type sudo crontab -e should be something similar on synology put an entry in Cron "@reboot" then the path and program you want to run. miss the quotes. Have a google above might help J

    1. Thanks for that but no... as I've come to expect from the Diskstation... "ash: crontab not found".

      It doesn't have GIT or APT-GET ... it's quite difficult to do anything - but I'm so near with being able to run the thing in the terminal.... (yes I have SSH access).

  6. Hello - I'm playing around with NodeRed since a while for home automation - today I found this promising module - I installed it to my global space with "-g" same as node-red. I can us it in the graphical editor - setup all the parameter - but I'll never get a message in first or 2nd output -> I only get a "-2" on the last one. I'm using latest node-red version 12.0. Any know issues with that? I also tried you scheduler module - same result- Any idea?

    1. Yeah, I'm seeing the same thing here. Second output gives me this every minute:
      { "payload": "-2", "topic": "status", "_msgid": "f7338f4b.08cc7" }

      The other ones gives me nothing.

      Any suggestions where to start looking? I tried npm update to make sure I'm on the latest version.

      Thanks
      Michael

      1. I just tried BIGTIMER on a brand new installation which got all of it's nodes from NPM. And this time it's not even a Raspberry Pi, it's an Orange Pi.

        I pulled in bigtimer (it asked if it could use my current position - I said yes) - I set the on time to 5 minutes from now and the off time to 35 minutes from now. I tied outputs 1 and 2 to a debug.

        I set the ON message to "hello" and the OFF message to "Goodbye"

        I started it - immediatgely in the debug window it said "Goodbye". A minute later a 0 appeared in the debug - another minute later another 0 appeared in the debug.

        That is absolutely the correct behaviour.

        1. Hi and thanks for your reply,

          Did some more tests... I uninstalled using npm, cleared the cache and reinstalled.
          I then made sure I had all fields populated in the node, however I still got the same results.

          I then tried removing the node completely from my tab and readded it. I'm now seeing messages looking much better every minute from the second output!

          2016-02-06 10:20:12dc2586e1.23da78
          /test : msg : Object
          { "payload": "0", "topic": "/test", "_msgid": "601a85b.f9fe57c" }

          2016-02-06 10:20:12dc2586e1.23da78
          status : msg : Object
          { "payload": "0", "topic": "status", "_msgid": "601a85b.f9fe57c" }

          2016-02-06 10:21:10dc2586e1.23da78
          status : msg : Object
          { "payload": "0", "topic": "status", "_msgid": "570a3aab.a8f5c4" }

          So today I learned that readding nodes to a project is a good thing to do before contacting the developer! 🙂

          Thanks for an inspiring blog!

  7. Dear Peter,

    I have a suggestion for improvement. I do not know if you know, since years I have developed a number of so called plugins for EventGhost. One of those is named SunTracker and is in some way comparable with your BigTimer.
    However, there are two features I really think would be valuable to have also in the BigTimer, two more day types. We can call them 'Vacation' and 'Away' (or 'Empty house').
    In SunTracker I can have different settings for those two day types. During 'Vacation' I personally have completely different settings for lights and other stuff then during normal weekends (so Saturday and Sunday settings will not work). Also when 'Away', I have again different needs.
    Let's assume you would have settings for those additional day types. To activate them you could have an additional input accepting the values 0, 1, 2 (0 = Don't bother, 1 = Vacation, 2 = Away).
    In this way you could externally set the mode of your system/house very easily using whatever node signals (like external calendars or home alarm system). You would also be able to manage special holidays (like we just had with Christmas and New Year)

    As I said, just a suggestion,

    Best regards, Walter

  8. Hi.

    Thanks for providing Bigtimer. I like it but have stumbled upon a problem or perhaps I am misunderstanding something....?

    At 11pm, if the humidity is above 70% in my lounge, Bigtimer turns on a de-humidifier until either the humidity has dropped or it is 6am. This works well but i also have another Bigtimer session that turns on the de-humidifier between 9am and 3pm as long as no-one is at home (global context variables set by ping).

    I need both instances set to "repeat" because they must check different variables throughout their active time BUT they seem to continue checking even when they should not be active (i.e outside of their ON / OFF cycle). This means that the night time Bigtimers spends all day spewing out a 0 because it's not night time. The 0 triggers an RF433 signal which sends the off code to the plug socket. BUT then the daytime Bigtimer sees that noone is home and turns it back on etc etc...

    Is there a way to make Bigtimer completely inactive outside of the ON / OFF times but repeat during active duty?

    I hope that makes sense. Regards, Don

    1. Hi there

      Ok the reason I did this - some devices remember their state after a crash or power failure (mine do) but some don't.. hence I put that in so that they would continue to get a reminder of the state they are supposed to be in - regardless of whether it is on or off.

      Now, I'll grant you - those devices that are being controlled directly are likely to default to OFF if they don't have a memory.

      I could therefore change bigtimer - but there is a better way.... and one you can implement immediately.

      So stick a function after bigtimer - if it gets a 1 - pass it on... if it gets 0, only pass it on once then set a flag not to send 0 again until there has been at least one 1.

      If you get my meaning. Simples.

        1. hmmmn. i said simples forgetting that I'm new to this,,,, I have been trying to write a function as you suggested.
          injecting a 1 works fine but injecting a 0 afterwards gives me the "nothing to see here" even though the var "count" should be at 1. do you have a minute to tell me what I've done wrong please Peter?

          var count;
          if (msg.payload ==1){
          count =1;
          return {payload:16738315};
          }
          else if ((msg.payload ===0) && count ==1) {
          count ===0;
          return {payload:16738314};
          }
          else {
          return {payload:"nothing to see here"};
          }

          1. I assume you meant count=0; not count===0; which is merely a comparison.

            Hence

            var count;
            if (msg.payload ==1){
            count =1;
            return {payload:16738315};
            }
            else if ((msg.payload ===0) && count ==1) {
            count =0;
            return {payload:16738314};
            }
            else {
            return {payload:"nothing to see here"};
            }

  9. Hi Pete,

    Do you have an example of using "bigtimer" to schedule more than one on/off event for a device per day? I have an aquarium lamp I'd like to run from 7am to noon, and 5pm to 10pm. I tried creating two bigtimers, one for the morning and one of the evening, but they fight each other, one constantly sends an ON event, the other an OFF event.

    1. Erm untick the box so they don't send stuff constantly.... the first output will then only send info when due to turn on - and when due to turn off - that way they won't conflict.

      Alternatively if you really HAVE to have the message repeated, use different messages for each of them (ie for example bt1_on, bt1_off, bt2_on, bt2_off) - feed those into a function and do a little logic on that before firing out the right message out of the other end.

    2. It would not be THAT big a deal to add another on-off time set to bigtimer - but then someone would want 3 on-off times etc...

      So I think the function is the answer.. will be a little messy set of ifs but do-able.

  10. Thank you for the fast reply! As suggested I whipped up a function, which eliminated bigtimer from the equation.

    Here;s the function:
    http://pastebin.com/UKVaARUV

    It's fed by 4 injectors, the first calls the function every minute, without a payload, just so it will check the time and override states, and send mqtt as directed. The other three injectors are default, on and off like your bigtimer. on/off set override, default clears the override

    A little clunky, but hey nobody's gotta see it 🙂

  11. This a great node Peter.

    Would you consider adding other sun events? I use sunset, goldenHour, night etc. Supporting these would allow me to tidy up my flows nicely.

    Luke

        1. I'm not sure how many people realise this - but when you npm install these node - well mine anyway - you have full access to the source - on a Pi, in home/pi/.node-red/node-modules/node-red-contrib-bigtimer there is an html, .js files ... that's it!

          1. Of course, I was only asking in case the actual project was lurking in github or bitbucket and I could do it via more formal means.

          2. Having taken a look at the code, I think I only need to use dusk offset correctly. For golden hour, -90 minutes for the dusk offset should do the trick.

  12. Hi!
    Thanks for BigTimer!
    But, I have some problems using it. I have the scenario that I want two timers, one in the morning, one in the afternoon. I have configured two BigTimers, sending only the changes, but only one is set to "at startup", since I got a race condition (one sending "on" and the other "off" at the same time with both checked to "at startup").
    But, with this configuration, only one timer (the one with "at startup" checked) will actually send an update. The other one will update the node, but not sent any topic.
    This is easy to reproduce by just connecting two BigTimers to debug output, uncheck "at startup" on one of them and set some turn on time in the near future and deploy. One will send an initial state, but the other one will be quiet even when the timer goes on (the node is updated correctly (green dot with text "On for xx hours") but that's it).

    1. It is at times like this Thomas that I wish I'd done a huge dropdown with per minute timing.. Sitting polishing my nails waiting nearly 15 minutes for the next trip to prove or disprove your theory.

      However as the 2 timers sit there with OFF status - both of them are showing the TOPIC... so I cannot think of any reason why that would change when they turn to on. I'll go get coffee while I wait...

      Ok, I've started again with REPEAT off... so in 8 minutes I should see both of them come on - the first one (with the startup flag) has already of course sent a message which included the topic.

    2. Thank you Thomas for that - I've done some tests - you are absolutely right - and I've fixed the issue.

      If you would care to npm install again.... you will find you are on version 1.1.3 which should solve the problem. I'm updating the blog accordingly.

  13. Hi Peter,

    Excellent work.
    I have discovered an odd issue and welcome your opinion.
    I'm in the Eastern time zone (UTC-5). I was having trouble with evening triggers (7pm-11:45pm).

    From looking at the code I believe there is potential corner case in the formula to calculate "today". The issue I believe is that during time between midnight UTC and midnight in the "negative UTC" timezones. the "midnight" calculated is actually the next day, the result is a negative "today". For example if it's 9pm (UTC-5) - actually 2a UTC next day. the Midnight calculation is for the next day so "today" ends up as -180 instead of 1260.

    My quick and dirty solution to resolve my setup was inserting this line right under the today calculation:-
    if (today < 0) today += 1440;

    There are several other ways to solve, including winding back the original midnight calculation a day since the today formula is % 1440 it doesn't matter which midnight as long as it before "now".

    Let me know what you think?

    Cheers,
    Peter C.

    1. Peter - would you like to do me a little favour - try your mod out on a couple of other time zones and let me know if it is fine - and I'll update the file accordingly..... I've only ever tried it in Spain and the UK.

  14. Hi Peter

    I want to ask a question. If I want to do something15 minutes before dawn, how can I accomplish this task with your bigtimer?

  15. Hello,
    Thanks for all the work you've done on BigTimer. I've recently started using it and was wondering if there was any way to either change the current on/off times over mqtt. I use OpenHAB as my front end and am 'trying' to use node red as a rules engine(among many other things). Ideally, it would have two more inputs, the first being for the 'on' time and the second for the 'off' time. I've gotten a few projects up and running (i love my sous vide machine) but am still fairly new to all of this. If you could point me in the right direction to accomplish this or have any advice for me i would be grateful.

    1. Not only will I have to think about that one Stuart - I'll have to ask the guys at Node-Red - I can't get my head around whether or not I can programmatically alter a setting set up in the web page... hmmm

  16. Pete, good work on Bigtimer. A suggestion: it would be helpful if you included a screenshot of the Bigtimer configuration form (web page) in your write up above so new users can see what the controls look like.

  17. Pete, I haven't been able to get BigTimer working on my Raspberry. I installed the node around three days ago. I followed the suggestion of Micheal on 02/06 and removed the node from the flow and then replaced it but so far no good. At present all fields are populated and Repeat and At Startup are NOT checked. I have repeated this test multiple times but the results are the same. Last test the On Time was 20:00 and the Off Time was 20:15. All outputs are connected to Debug and the results for the On Timer can be seen here from the Debug column:

    4/25/2016, 7:59:34 PMe695a194.d8cbd8status : msg.payload : string [1]0
    4/25/2016, 8:00:34 PMe695a194.d8cbd8status : msg.payload : string [1]0
    4/25/2016, 8:01:34 PMe695a194.d8cbd8status : msg.payload : string [1]0
    4/25/2016, 8:02:35 PMe695a194.d8cbd8status : msg.payload : string [1]0

    Suggestions?

    1. Pete, update on 04/26 post, Bigtimer is working big time. I can't explain why, but it appears that Bigtimer was using UTC time and I am -7 hours US/MST. As you can see in the prior post, Node-Red posted the times in the Debug column as MST thus compounding the confusion. I am still in the process of setting this system up and I did not have the proper configuration for the ntp update, although I did set it as advised in at least one Linux How-to article. Once I reconfigured the ntp server settings and rebooted, Bigtimer was on the same page as the rest of us. Again, I can't say why exactly, but I can say this appears to be the problem as it has been running a few days now and I can set and verify actions in real time whereas before the 7 hour time delay would not let me see when it fired. Good work and I apologize that I misunderstood the real issue before.

  18. Hey Pete,

    Been following your blog for a year now,... many thanks!

    ...for the life of me I can't get bigtimer to work correctly. timeswitch works fine for me, however I'm interested in the offsets between each on/off time selection.

    Are the offsets valid +or- only between each selection? What is valid input in the offsets. e.g "-20" , "+30", "2", "+2", "-3" ?

    Also, I can't make any sense of the subscript "On for 03hrs 21mins". It doesn't match-up to what I selected. Have you seen this too?

    Thanks

    1. Hi Dan - the offsets are in minutes and can be applied to both start and end times. Yes, +4, -5 etc. If you have a specific example of an issue, give me details and I'll try it here.

      To test for an issue, at 7.22 in the morning I set a new bigtimer with on time at 8am and offtime at 9am. It comes up with "Off for 00hrs 38 mins" which is correct. I add 10 mins to the offset and... the display changes to "Off for 00hrs 48 mins". Changing that "on" offset to -10 does as you'd expect and changes the display to "Off for 00hrs 28 mins".

      It is now 7.26am - I change the ON time to 7am - leaving the OFF time at 9am. It now says "On for 01hrs 36 mins" which again is correct. Setting the OFF offset to 15 mins adds 15 mins to that time.

      All seems perfectly correct to me.

    2. I guess it is worth asking - have you actually checked to ensure the time on your Pi is CORRECT?? Are you also setting correct longitude and latitude in the dialog box (though that should really only affect things like dawn and dusk etc).

      1. Pete,

        I took a look at the code there seems to be an issue with the code for negative GMT (I'm in -5):
        I changed this:
        //var nowOff = -now.getTimezoneOffset() * 60000; // local offset
        to:
        var nowOff = now.getTimezoneOffset() * 60000; // local offset

        ...and results look better. Should be an easy fix for the "negative " folks. Thanks again!

        1. Dan

          I'm wondering if just perhaps you started with an earlier version of BIGTIMER - because the version I'm using which is the one which SHOULD be available from:

          npm install node-red-contrib-bigtimer

          ALREADY has that line un-commented. Want to check? In my Javascript, line 101 of he JS file has that line active - NOT commented out.

          Indeed here is everything from line 99 and you'll see I threw away an older version of the code....

          function(inmsg) {
          var now = new Date(); // UTC time - not local time
          var nowOff = -now.getTimezoneOffset() * 60000; // local offset
          var times = SunCalc.getTimes(now, node.lat,node.lon); // get this from UTC, not local time

          var dawn=(times.dawn.getHours()*60) + times.dawn.getMinutes();
          var dusk=(times.dusk.getHours()*60) + times.dusk.getMinutes();

          var solarNoon=(times.solarNoon.getHours()*60) + times.solarNoon.getMinutes();

          var sunrise=(times.sunrise.getHours()*60) + times.sunrise.getMinutes();
          var sunset=(times.sunset.getHours()*60) + times.sunset.getMinutes();

          var night=(times.night.getHours()*60) + times.night.getMinutes();
          var nightEnd=(times.nightEnd.getHours()*60) + times.nightEnd.getMinutes();

          now=new Date(now+nowOff); // from now on we're working on local time
          var today=(now.getHours()*60) + now.getMinutes();

          /* var nowMillis = Date.UTC(now.getUTCFullYear(), now
          .getUTCMonth(), now.getUTCDate(), now
          .getUTCHours(), now.getUTCMinutes(), 1);
          var midnightMillis = Date.UTC(now.getUTCFullYear(),
          now.getUTCMonth(), now.getUTCDate(), 0, 1);
          var startMillis = Date.UTC(times[node.start]
          .getUTCFullYear(), times[node.start]
          .getUTCMonth(), times[node.start]
          .getUTCDate(), times[node.start]
          .getUTCHours(), times[node.start]
          .getUTCMinutes());
          var endMillis = Date.UTC(times[node.end]
          .getUTCFullYear(), times[node.end]
          .getUTCMonth(), times[node.end]
          .getUTCDate(), times[node.end]
          .getUTCHours(), times[node.end]
          .getUTCMinutes());

          nowMillis += nowOff;
          startMillis += nowOff;
          endMillis += nowOff;

          var dawn = (((startMillis - midnightMillis) / 60000)) % 1440;
          var dusk = (((endMillis - midnightMillis) / 60000)) % 1440;
          var today = (Math
          .round((nowMillis - midnightMillis) / 60000)) % 1440;

          */

          var startTime = parseInt(node.startT, 10);
          var endTime = parseInt(node.endT, 10);

          1. I'm using "_id": "node-red-contrib-bigtimer@1.2.5",
            "_shasum": "309b79e400099880275a3ea47138d7f327d90efc"

            In the code you posted. I removed the minus sign:

            I changed this:
            var nowOff = -now.getTimezoneOffset() * 60000; // local offset
            to:
            var nowOff = now.getTimezoneOffset() * 60000; // local offset

            I hope that clears up the change I made; It works perfectly now in GMT-5.

  19. Dan - you are of course absolutely right - don't know how that crept in - but I've now updated the repository with that amendment and a higher version number. Anyone using Bigtimer can update in the normal way. Thanks.

  20. Hi - Avid follower of all the stuff you publish. Not sure if this is linked to the recent discussion re negative GMT etc. But I have today installed latest version of BigTimer on a Pi2 which is correctly set to correct time on BST. Any alerts I set incorrectly calculate time. For example at 15:10 BST if I set a timer to come on at 15:15 and go off at 15:30 under the node the message says "Off for 23 hours 5 minutes". If I change that to on at !5:15 off at 16:30 the message changes to "On for 20 minutes" even though it still has 5 minutes to go. If I advance all times by 1 hour i.e if I want to turn on at 15:15 and go off at 15:30 the I have to set the timer to on at 16:15, off at 16:30 and then all works as expected. Hope this is clear and correct. Latest versions of node-red, raspbian jessie and your timer installed and all clock times set correctly.

    1. It is a long time since I pieced together that code... removing the minus seemed obvious - yet in fact on test it is wrong - so we'll need to find another solution for those in negative time zones - I have re-introduced the negative offset and at least here in Spain - the timer works perfectly.

      Version 1.27 - you can get this by simply using npm install node-red-contrib-bigtimer from wherever you did it in the first place, then stop and start node-red (or reboot whichever is easier).

      Looks like a different solution is needed for those in negative timezones - the code is in the bigtimer.js file - if anyone in a negative timezone can test this - would be appreciated - i.e. did the MINUS actually make it right??

      1. Hi - Just to confirm that it is all working fine on BST now - although the randomised offsets had me going for a minute or two. Thanks

  21. Hi,

    Thank you very much for all your contributions to the iot community. I must say is have used many of your contributions as is and/or modified.

    My purpose for writing today is either a miss understanding of the use of the input side of bigtimer or a bug. My apologies in advance for the long message, I just hope I can explain it so you understand. I have been using bigtimer for quite sometime now and only this weekend I have started to use the input input portion of the node. I also saw you posted an update today, which I downloaded. My understanding is there are 4 possible inputs, which are as follows:

    1/on --> to send the ON msg to the output until the node is set back to auto or at the next timed even.
    0/off --> to send to o OFF msg to the output until the node is set back to auto or at the next timed even.
    auto --> to return the node to is originally intended purpose/state/schedule
    manual --> to over ride the schedule and leave the node in its current state until auto is injected.

    This leads me to an issue or misunderstanding I am having with the "manual" command. I placed a bigtimer node on the work flow and I added two inject nodes, one with the string set to "auto" and the other "manual" and I put a debug node on the first output of the timer node. If the timer is in the ON state and I press the "manual" input node I would have expected the timer status to stay ON, but it changes to OFF and goes to manual mode. I found that the only way to have the timer stay on when pressing "manual" was to first sent ON/1 to the input then press "manual". when I do that the timer stays ON and goes into manual mode. The issue does not stop here, as expected, after I press the "auto" input node the timer state changes to OFF and goes back to normal scheduled state, however, now if I press "manual" I would expect the timer to go into manual mode an stay off, but it does not, it goes into manual mode and goes on. Much like the other way around this, I have to sent OFF/0 before pressing manual if I want the timer to stay off and go into manual mode.

    The question is, do I in fact have to sent the desired state ON or OFF before sending manual? If that is the case then I will work it into my flows.

    Thank you,

    Mike

    1. Hi - manual means manual - it will NOT allow the schedule to continue. WAY too late at night - but I will study your example in the morning and see if I can replicate what you are suggesting - if I can replicate a problem chances are I can fix it. HOWEVER my understanding is that if the unit is ON (manually) and you switch to MANUAL - it will firstly scrap any ON/OFF and then STOP the automatic features... I'll check this out and we can ultimately agree on what the various options should be doing...

    2. Ok, no way will I be able to tackle this until the effects of our party tonight wears off but on re-reading it - assuming what you've said is correct there has to be an issue there - if it was on auto - and ON - and you switch to manual... bigtimer really should stay ON.

      Meanwhile if anyone wants to look at the .JS file, happy to let someone else spot the "deliberate mistake".

      1. Hi Peter,

        Oddly though if you inject ON before you inject "manual" it will remain on and go into manual mode.

        WRT the time zone, I had noticed an odd problem with time zones a few months back. If I put my time zone to ET (-5) and say the timer has less than one hour until the next scheduled state, rather than show ON for <59 minutes, it would show ON for 24+ hours. I'm not sure if that is the time zone problem you are referring to.

        Thank you again

        Mike

  22. Ok, BIGTIMER version 1.28 - should now have that auto-manual combo issue eliminated.

    If you are ON in auto - then switching to manual should STAY on. If you are OFF in auto, manual should STAY off.

    If you have set a 1 or 0 manually - then the manual button should respect that - whereas auto will reset to whatever auto was doing before you messed with it.

    Any testing on this version would be appreciated..

    My normal way to install - might be different for others is to go into the .node-red folder and..

    npm install node-red-contrib-bigtimer

    Then restart Node-Red and you're off.

    Right- I'm out for the day - any feedback welcome.

  23. Hey Pete,

    On the negative timezone issue, can you (anyone) test this. I made this change and it still works for me in GMT -5.

    var nowOff = (now.getTime() - now.getTimezoneOffset()) * 60000;

    Thanks,
    Dan

  24. See updates (end of article) - I've just realised that when using ImperiHome to override auto - when that override timed out - there was no way to let ImperiHome know that we'd returned to auto. Sorted.

  25. Hi Peter,
    I wondered if you could consider a couple of new features?
    1. If there had been a power cut, or the program was just started It would be useful to stagger devices being turned on because of the load. So a delay xx before the timer starts from Pi start or program start would be good.
    2. A time off and a time on perpetually. E.g. xx minutes on then xx minutes off.

    Both would operate within the normal on off times as already defined.
    This is for my fish tank.
    Thanks.
    Paul.

    1. On 2 - I can do {out0:6,3} which is turn on for 3 minutes then turn off.... I do anything more complex than that in Node-Red - which has proven so reliably on the Pi I've not seen a need to put that on the actual ESP - but no reason at all why not.

  26. Hi Peter, I'm usign a lot you node so thank you as it smplifies my setup for home automation!
    I small feature I'd like to have is possibility to send to my GUI (actually a mix of contribu-ui and thml webpage) the message that you have in "node status" (so to know when the timer will go ON, OFF or it's current status).
    I know already the status but only because I trigger it and same time I sent message to my MQTT but would be nice to show in my dashboard something like "Garned lights will go on in 45minutes" or "Garder water system will turn off in 20 minutes" and so on 🙂

    1. Good evening Giovanni

      In this case that's so useful that your wish is my command.

      http://flows.nodered.org/node/node-red-contrib-bigtimer

      Update to version 1.2.86. In the object sent out by the centre output every minute, you will now find msg.state and msg.time

      The description explains this. The state - on, off or none and the time in hours and minutes as lifted from the node status,

      You'll note I've also updated this blog if you refresh your browser.

  27. Hello Peter,
    It's me again 😉 Hope you are doing fine!
    As you might remember we discussed some topics earlier regarding your nice Big Timer node.
    Looking at your new version, I can see that you are now also supporting additional input words like 'manual'.
    I do have some questions related again due to the specific use cases I am running in my home automation.
    My flows need to be able to switch the big timer modes from manual off -> auto -> manual off again. This is getting a bit complicated since I cannot send just one message when switching mode.
    If possible, it would be very useful if you also could have support for the full input strings 'manual on' and 'manual off' (the function should be the same as if you would send those words as two separate messages to the input)

    Myself, not very experienced in javascript, I found a very useful on-line tool for checking the syntax of javascripts. It helped me a lot. If you copy & paste bigtimer.js code and run the tool, you will see some warnings coming up.

    http://www.javascriptlint.com/online_lint.php

    Kind regards, Walter

  28. I think the following code could do it:

    case "manual off" :
    case "MANUAL OFF" : if ((temporaryManual==0) && permanentManual==0) manualState=autoState;
    change=1; manualState=0; temporaryManual=0; permanentManual=1; break;

    case "manual on" :
    case "MANUAL ON" : if ((temporaryManual==0) && permanentManual==0) manualState=autoState;
    change=1; manualState=1; temporaryManual=0; permanentManual=1; break;

  29. Hi Pete,
    firstly thanks very much for your always insightful, very intersting blog; I eagerly await new 'episodes' daily!

    I 've been working with Node-RED for a while now and was excited to learn about your BigTimer node which I've finally been able to use but I couldn't get the dawn and dusk events to fire at the correct times.
    After reading this long series of Qs and As and a bit of verification using the TryIt Editor from w3schools.com, I found the problem. A new Date() object is already in local time so there is no need to calculate the timezone offset and apply it to var now in lines 100 & 114 - which I have commented-out.
    I validated this change by using a debug node on output 2 and dumping the whole msg object where you've helpfully inserted the current local time in minutes.
    e.g. at 21:54MST GMT-6 where the timer is set to turn the bookcase lights off at 23:00:

    { "payload": "1", "reference": ":Bookcase Lights On:Bookcase Lights Off:1314", "topic": "status", "state": "on", "time": "01hrs 06mins", "name": "Bookcase Lights Timer", "_msgid": "d5d50b60.2a2af8" }

    Or my dawn/dusk timer that feeds a function to set a global day/night indicator:

    { "payload": "0", "reference": ":dawn:dusk:1314", "topic": "status", "state": "off", "time": "07hrs 22mins", "name": "Dawn And Dusk Events", "_msgid": "e39d7c14.1c628" }

    Platform: Pi3, Jesse, timezone set to Americas/Denver (MST/MDT)

    I'd like to hear if this works for those in other timezones and on other OSes like Windows.

    All the best, Simon.

  30. Hi Pete,

    I've been playing with Big Timer for a few days and was wondering about the source of sunrise/sunset/dawn/dusk/night/night-end information.

    Firstly sunrise/sunset - I entered latitude/longitude of a location nearest to me from the Met Office web site. The times Big Timer switches on and off are close enough for what I need but actually a minute or two different from what the Met Office show on their website - curious.

    Secondly dawn/dusk/night/night-end - to be honest I was intrigued by these options as it had never occurred to me what dawn/dusk actually were (they were just terms I'd heard used) or even the actual definition of night. I've since looked it up and things got even more confusing - it seems there are several stages. From sunset we then enter a period of civil twilight ending at civil dusk...then nautical twilight ending at nautical dusk...then astronomical twilight ending at astronomical dusk (start of night). Then, of course, we have the reverse for night-end through to sunrise....

    So if I use dusk/dawn, which ones does Big Timer use (civil, nautical, astronomical)? Also night/night-end get a bit tricky for latitudes above 48 degrees (or thereabouts), e.g., the whole of the UK - around the summer solstice the UK never enters night (technically speaking) as the sun is never more than 18 degrees below the horizon, i.e, we only get astronomical twilight. Consequentially we don't have astronomical dusk/night or night-end/astronomical dawn. Fun isn't it? 🙂

    I've had Big Timer running on my Pi Zero for a few days and set for a dawn switch off - I happened to be up at 4:45am when it triggered (about 45 minutes before sunrise) and there was a reasonable amount of light despite being overcast but I can't quite work out which dawn it was (astronomical, nautical, civil).

    Anyway, that was a bit of a ramble. It's for a home lighting project and there'll be a luminosity sensor connected to an ESP-12F module in the mix as well but I'm curious to know if you can explain further about the various data for sunset/dusk/night etc.

    Cheers,
    Brian

    1. Hi Brian

      The one thing I cannot explain - is the dusk dawn stuff as that's a library that I found already in use in a node in Node-Red and grabbed accordingly - I'm not aware of a better library for use with Node-Red - the lights here in Spain seem to come on at a reasonable time - and also when I'm in the UK - of course I have no doubt this could be improved. When I compare the times with those in the various online charts they seem near enough.

      1. Hi Pete,

        Well I did what should've seemed blinking obvious in the first place and set up a test Node-RED flow with 3 Big Timers (one for sunset/sunrise on/off, another for dusk/dawn on/off and of course finally one for night/night-end on/off). DOH! Why didn't I think of that before?

        Results...

        Sunset - 20:58 - two minutes later than Met Office but close enough.
        Sunrise - 05:32 - again, two minutes later than Met Office but close enough.

        Dusk - 21:42 - this was 44 minutes after the sunset timer kicked in and during that period there was enough light to carry on 'outdoor activities' without artificial light. I'd conclude (in my observation) that in this case, the Big Timer 'dusk' setting corresponds to 'civil dusk'.
        Dawn - 04:50 - as with my previous post there was a good bit of light and I could have gone outside without artificial lighting so I suspect it is 'civil dawn'.

        Night - 00:11 - this surprised me from an observational point of view. Two and a half hours after the dusk timer kicked in and, in my observation, it had been quite dark since dusk and that was with only a partially cloudy sky.
        Night End - 02:26 - so only 2hrs 15 mins of what was considered night. This tallies with my previous post where I said latitudes above 48 degrees don't get night at all around the solstice. It's 6 weeks or so after the solstice now so that period of 'night' makes sense. I'll override the Pi Zero's clock to set it to June 21st and see what happens just out of curiosity.

        In conclusion, I'm not sure what use I could find for Night/Night-end (who knows, maybe I'll come up with something). Dusk/Dawn seem to be good trigger points for outdoor security lighting. Sunset/Sunrise possibly best for indoor lighting.

        Just some observations.

        Cheers,
        Brian

  31. Hi Pete,

    Thanks for BigTimer - much appreciated.

    I installed the node (npm install) with no problems on my Pi2 but when I tried installing it on my test box running Ubuntu 16.04 (32-bit as the processor is an Atom N270), I received a few warnings:

    +-- node-red-contrib-bigtimer@1.2.95
    +-- suncalc@1.7.0

    npm WARN enoent ENOENT: no such file or directory, open '/root/.node-red/package.json'
    npm WARN .node-red No description
    npm WARN .node-red No repository field.
    npm WARN .node-red No README data
    npm WARN .node-red No license field.

    I restarted and checked Node-Red, but BigTimer wasn't listed. The version number of Node-Red on both systems is the same.

    Long story short, I had to do the following to move suncalc into the right place:

    cd node_modules/node-red-contrib-bigtimer/
    mkdir node_modules
    mv ../suncalc/ node_modules/

    After a restart, BigTimer appeared in Node-Red.

    I have only just started working with Node-Red so maybe I missed out something, but I thought I'd mention it in case my fumblings help others.

  32. Pete,
    I have configured the Bigtimer to turn off 7:15 PM but it is actually turning off at 7:16:36
    More than a minute late. The same for turning on.

    Could you check if there is something to tune in the code?

    Best regards, Walter

  33. So here is additional logged info

    Date & time is from inside the same rpi where node-red runs on. 'State' is what bigtimer delivers on 2nd output (0 or 1). Configured to turn on at 7:30 am and off at 7:45 am

    When State === 0 and then turning ON
    2016-09-12 07:28:11 State: 0
    2016-09-12 07:29:11 State: 0
    2016-09-12 07:30:11 State: 1

    When State === 1 and then turning OFF
    2016-09-12 07:44:12 State: 1
    2016-09-12 07:45:12 State: 1
    2016-09-12 07:46:12 State: 0

    You can see that when turning on, it is within the correct minute but 11 sec late. When turning off, there is a whole minute late plus those seconds.

    So I think you are one minute late when turning off. Also, instead of synchronizing the timer with the clock, could it be that you are starting things on deployment? That could eventually explain those seconds...

    Best regards, Walter

    1. Good morning Walter

      Well, you are right - I was checking >=start or <=end. That is now fixed and within an hour or so you should be an updated version available. As for ultimate accuracy - to keep overheads down the code is checked every minute - hence there will always be some inaccuracy in terms of start and end seconds. The only way around that would be to poll every second and given lots of timers I think the overhead might be a bit much.

  34. I am learning node red and feel I am missing something about timers and triggers. It seems that most timers only allow me to set the time in 15 minute increments. Is it strictly because the widget would get too long if every minute in the day was listed?

    Secondly, I have noticed this in many node-red nodes, why can't I pass settings either in the payload or as some other attribute? For instance, I wish I could send in a variable delay time or variable start time to bigtimer.

    1. Possobly because not enough people want this to warrant the extra overhead. Node-Red nodes are simply HTML but more importantly in this case - Javascript - if the nodes are not what you want - go to the Javascript and improve them.

      1. Hi Pete

        Tx for all the great work, have been lurking and playing with your stuff for a while now and am looking at making some additions / changes relating to making settings changes to bigtimer externally aka a user and admin mode like blynk has. Basically a scenario where a regular user can make settings changes (start stop times etc) from a UI and/or app.

        I have had an initial look at this and was thinking of modifying bigtimer to add additional inputs to accomplish this.

        Any thoughts on this approach and/or any other ideas to achieve this from your experience are appreciated.

        1. Hi well you can add additional commands - but nodes can only have one input - there's been plenty of discussions about that and it's not about to change - but sure - just add more input commands.

  35. Hello Pete,
    Your new version is now working fine (as always!) and is now turning off within the minute.
    Just one input from me regarding the thing with offset of seconds. I think it looks like you are starting the timer on deployment, right? If you would be unlucky, like I was, it was started when 58 sec elapsed. So then I was 58 sec late both for on and off actions. My idea was not that you should check every second, the check should only happen right at startup. Myself, I made a similar implementation once in Python and the principle was that I checked the system time at start, calculating number of seconds to next minute change, then waited and finally fired exactly at the minute.

    Kind regards, Walter

  36. Hi Pete!

    I've been doing home controllers with Raspberry Pi's and my own electronics for a few years now, writing my own apps in Python, learning as I went along. I recently got interested in Node-Red, but before I got around to trying it, I discovered TheThingBox, which runs on top of Node-Red.

    Your Big Timer is exactly what I need - but I can't see it in TheThingBox - I did npm install node-red-contrib-bigtimer and it returned:

    node-red-contrib-bigtimer@1.2.96 node_modules/node-red-contrib-bigtimer
    └── suncalc@1.7.0

    But after restarting Node-Red, and after rebooting, I still don't see it. Would you know if it has a problem with TheThingBox? Should I drop TheThingBox and go to pure Node-Red?

    1. I would say there is likely something very wrong with Tbingbix if it will not let you I stall Big-time or other nodes. I use a normal Mode Red and when I do installs I go to the Node Red directory... in my case /home/pi/.node-red

      Once in there I install nodes. I.e

      npm install node-red-contribute-big-time

      And that works every time on pi and other devices.

      1. Hi, Thanks for the fast reply!

        TheThingBox puts nodes in /root/thethingbox/node_modules. When I found it, I did the import again. BigTimer did not appear for a while, but eventually did. I am running on an old Raspberry Pi 1A, so it is probably slower than using a Pi2 or 3, or even a Pi1B, which has more RAM.

        BigTimer is great - exactly what is needed for all those things that need to happen at dawn and dusk. And it is very flexible. Thanks for it!

  37. Hi
    just re-installed "the works" on another sd card using your script, as my old one was in a bit of a state from all the playing (but worked). main reason being after seeing your echo dot, i bought one immedietly, and everyone i have shown it to has done the same. anyway wanted a clear canvas to try and tackle https/ssl (really struggling at moment!). So with clean install i put all the esplogon nodes in place then the very important one, Big timer to switch on my electric blanket!
    i have the on time set to 21:00 and off for 22:30 but It switches on at 22:00. It is now 21:56 and at the bottom of the node it says "off for 00hrs 4mins".
    It is now 22:00 and it has just switched on, it says on for 01hrs 30mins. An hour wrong.
    if i set the off time to 90mins (on time still 21:00), it says on for 3hrs 10mins..... all gone wierd! have you any ideas, or has anyone else had similar problems?
    my old version is about 5-6 months old and always worked flawlessly.
    i have Lat & long set correctly. offsets at 0.
    also, an unrelated problem on my laptop big timer won't scroll so i cant get to any of the radio buttons below Jun. i have to use ipad in portrait to get to them
    Many Thanks for all your great work.
    Chris

  38. Funny enough - everyone WE'VE talked to has gone out and bought a DOT. I do hope Amazon stay on the ball and keep improving it - this thing about accepting words outside of a selection you make it pants - and we've not found a way when talking to it by Node-Red to do multi-part commands without having to keep saying "Alexa - tell computer".... but other than that - it is marvelous - right now I've just told it to alert me in 30 minutes when my chicken pie is ready... it is quiet clear I'm going to need one in every room 🙂

  39. Bug or misconfiguration?

    I've got several timers in a flow. Whenever they're defined over an absolute interval, say, 1pm to 3pm, everything works as expected. However if I define start time to sunrise (or sunset) and end time to a relative duration like 60 minutes, the node seems to _always_ evaluate the condition to be TRUE on deploy and come up with some strange duration to wait before turning off again. A clearer example:

    1) I define a BigTimer to run from sunrise for 60 minutes. Let's say sunrise is at 5am for the sake of simplicity;
    2) I deploy at 10:30am (you'll see why I'm so specific later); BigTimer fires TRUE (which is contrary to my expectation that it would only fire if within the interval 5am + 60 minutes);
    3) I see beneath the node in the flow "On for 12hrs, 20mins" or something along those lines.

    However, if I change end time from 60 minutes to, for instance, 10:00am (remember the current clock time is 10:30), then BigTimer figures out that endTime < currentTime and the state is FALSE. So it seems to definitely be linked to the relative time offset "60 minutes." Or have I simply misunderstood how this sort of event is supposed to be defined?

    Version according to package.json is node-red-contrib-bigtimer@1.4.1, which I believe is the latest.

    Otherwise it works great. Cheers for the elbow grease

  40. Hi Peter,

    I've need using Bigtimer since the first release, in fact I was even using your original scheduler node before that, and must say bigtimer is the most useful node in my tool box. I do have a request. Is it possible to add a feature that will set the start and stop times based on say msg.starttime and msg.stoptime passed in from the input? This would permit setting start and stop times from a web dash board and saved in a database. They can then be passed to bigtimer either at startup or when the setting on the dash board is changed.

    Thank you for everything.

    Mike

      1. Thank you for the quick reply.

        I'm not very familiar with creating nodes, maybe I should learn in order to help contribute. In any case, how would feeding a start/stop time on the input be different that say feeding a topic to the MQTT node as opposed to putting the topic directly in the node? Sorry for my ignorance, and with that in mind, where can I find more information on creating nodes? I looked at the node-red website a while back and it is not very helpful.

        Thank you,

        Mike

        1. After thinking about this a little more I understand what you mean. With the MQTT node you are not setting the topic but instead simply passing the topic through the node. Where as the big timer node the time has to be set as opposed to passed through the node.

          Correct?

  41. Hello Peter,
    Thanks for your bigtimer. However, I’m wondering, why does the timer on an inactive day still produce output when I send an “auto” (or default) to the input. I can imagen it will override the output when you send an “on” or “off”.

    Is this the behaviour as you designed it or can we expect an update for this? So an inactive day won’t produce an output if it receives an auto.

    The problem is that I will use different time schedules on weekday’s and weekend’s. (I will override them for the same input.)

    1. I'm having difficulty understanding the problem. If this is an inactive day and you turn the unit on manually, then turn back to auto - then you would surely expect the unit, having turned on manually, to go back to the auto state which of course would be off as it's an inactive day... or am I missing something here.

      1. The problem is that I uses two bigtimers parallel. One timer is for the weekday’s and one is for the weekends. Both has the same input and same output (MQTT). Because of the different time schedules it is posable that the light is on till 10pm on weekday’s and till 11pm in weekend’s. Only one is active based on the day of the week. Sometimes you wish to override the timer. So I send an “on” or “off” which is great. However if you wish to continue the timer schedule function I send an “auto”. The active timer needs to respond. I found that the inactive timer also respond to that event.
        If that is between 10 and 11pm, one timer send a “poweron” and the other a “poweroff”. I any case the light will flash. I didn’t expect that an inactive timer for a day send an event when it falls back to is original state - which is in this case no activity-.

  42. We have been using your Bigtimer for about a month now. After the latest update, the node seems to have an error while calculating the position of the sun based on our longitude and latitude. For example, we have it set to turn on at Dusk and off at 21:00, but it is showing that it will be on for the next 20 hours. Any help would be greatly appreciated.

    Cheers.

    1. Hi Julian

      I added authentication - something I've not used before so it was odds-on I'd get something wrong, somewhere. Sure enough - lower case letters only... fixed in version 1.4.7 to allow upper, lower and numbers as well as underscores - give it half an hour. Also fixed an issue in the name which can now be uppercase, lowercase, numbers, underscores and spaces.

    1. I've not yet tried this version (tonight). However, one small point that would make life a lot easier with any future parameter changes. I've noticed that when you add parameters and I update an existing flow, often I get errors because the new parameters are not pre-filled with defaults.

      Thanks again for the work put into this node.

      Regards, Julian

          1. Well, it may be that someone can help me there - I'm no great whizz at programming nodejs etc.... I'm ok at it - but when it was suggested I add in error checking - the payback for that seems to be that defaults don't work - which is incredibly annoying as you can SEE the defaults - but unless you put something in, it objects. Anyone want to put me right on that I'll fix that right away (it's in the HTML)

    2. Hey Pete, I just found Bigtimer and wanted to use it in my node red setup. However, my mqtt topics have "@" and "." in them. As soon as I put one of those characters in my topic, it goes red. I believe I can work around this with a function node, but if there is any chance of fixing this in the build, that would be fantastic. I see above that you were able to add underscores and digits, so I figured I would ask 🙂 Thanks!

  43. For me Bigtimer works great to turn on lights 30 minutes before dusk. However, regardless of configured off time it turns the lights off around 1:15 AM the next morning. I'm located in the eastern US timezone.

    I noticed my Bigtimer configuration dialog doesn't look anything like the one shown in this post. It looks like the one in the earlier Bigtimer post so I thought I must have an old version. I have updated node.js, node-red and all nodes (v7.2.1, v0.15.2). Bigtimer still looks the same and still turns off ~1:15AM. As I started working on home control years before discovering this excellent blog I'm running on an Intel Atom miniITX board using Ubuntu 14.04. Yes I know you are not an Ubuntu fan but that where I am.

    Can anyone point me in the right direction to get Bigtimer working?

    John

    1. Hi John

      Well, Ununtu I cannot even begin to help with - it's taken me all my willpower to persevere with Debian as a lifelong Windows user. Let's see what I'm running here... on my main machine - I ahve node v 4.6.1, npm 2.15.9 and node-red 0.15.2

      On another I have node 7.2.0 and npm 4.0.3 - all work well with Node-Red-Contrib-Bigtimer which is currently running at version 1.4.7

      And as far as I can tell all is working.

      1. Ubuntu IS Debian - with loads of goodies added and repo's that move a heck of a lot faster than the risk averse folks maintaining Debian like. But the base is Debian pretty much I think - certainly it used to be anyway.

        1. You may SAY that and you probably have more knowledge on the subject than I do - but as someone coming in fresh to Debian - and being familiar with the PI - and using Debian on other devices as you'll see in the blog - I've come across several commands that seem to be standard in Debian that are simply not there for Ubuntu and there is no way my script runs under Ubuntu - one reason I'm sticking with Debian. I think you may find they've diverged a little.

        2. no, it WAS debian... they forked it way long time ago... the filesystem organization, the tools, are the same, but they differ a lot in management and many other things... ubuntu forces you to have good "systemistic" behaviour, as NOT do everything as root, but becoming it only when needed, using sudo... but many pure "penguins" thinks this "stinks", and want full control...

          1. Fair enough. Though I'd say that Rasbian isn't Debian either 😉

            In my own limited experience I've not found that much difference between Debian and Ubuntu Minimal when managing VPS's for example. Not that I do a lot of that which may explain it. Perhaps I'm just used to Debian now but I don't find any great problems with secure configurations on it vs Ubuntu.

            Anyway most of the scripts I've written work on both. But that certainly wouldn't be true of a Rasbian script vs a VPS script. Rasbian is designed to be used by students and makers for IoT and not necessarily for anything secure. Of course, it also has to operate in a very constrained environment. So it is stripped down and simplified in many cases.

            Anyway, we are well off-topic now and should probably get off the airwaves.

    2. Recall you need to be in your .node-red directory - not PI or whatever - and it is npm install node-red-contrib-bigtimer

      That should net you the latest version. Stop Node-Red and restart it

      1. I have installed Bigtimer from my .node-red directory. I have also run "npm update" from within the .node-red directory. It found the mysql node was out of date but nothing else. I deleted all instances of Bigtimer and deleted it from nod-red using the admin node. I reinstalled it using admin. Then I added a new Bigtimer node. It still looks like the old version. The package.json file in the node-red-contrib-bigtimer directory show the version is 1.4.6. I restarted node-red after each change and have rebooted for other reasons as well.

        Meanwhile I have a workaround to turn the lights off.

        Didn't mean to start a Debian vs Ubuntu vs ??? discussion. I started with Ubuntu before Raspian came to be and have just stuck with it out of habit I guess. I do have a couple Raspberry Pies but none running node-red (yet).

        John

        1. Hi John - leave bigtimer for tonight - conversation going on in SLACK - I added something for someone else -and it's taking a couple of revisions - all should be great by the morning. Anyway there's a new feature to come out of it all and possibly a bug-fix.

  44. hi Pete, after many months of working flawlessy of your BigTimer to control my garden lights I decide to upgrade it to the latest version...
    as a results the nodes I was using before become not working no matter what I tried 🙁 (wife was upset as all lights in the garden were off in the evening...!)
    I had to remove all of them and recreate all in NodeRed with same settings and they all seems to work now even thou every time I deploy I get an error for all of them "Node is not configured properly" and if I open any the field "topic" is red-highlighted...
    I never used topic and I have no needs of it, so is it normal this behaviour?

    1. It seems one can't please everyone. Someone had the bright idea of insulting me because I don't use proper verification on node inputs (probably someone who insists on CE marking).

      So, being a helpful type I added verification - and the red boxes you see are objecting to the lack of input.

      Clearly however this has opened up a can of worms. As you quite rightly say, for SOME requirements, topic may not actually be needed.

      My thinking for insisting on topic, of course, was based on the assumption of MQTT output which requires both topic and payload. So from that perspective, that is indeed "normal behaviour".

      If you would care to check in about an hour, version 1.4.8 should be available - and you can now leave the topic blank.

      This however has left me with a discovery - that my knowledge of REGEX which was never startling, may be worse than I thought.

      outtopic: {value:"",validate:RED.validators.regex(/[a-zA-Z123_]*/) },

      What you see above should allow zero or more occurrences of any letter, upper or lower case, any number and optional underscores. In fact, I added an exclamation mark and it lets that through as well - hence kind of defeating the idea of having verification. If any bright REGEX spark looking in would care to tell me what is wrong there, I'll update the next version with a corrected regex. But the short answer is - you have what you need - blank topics!

      1. Make that 1.4.81 - just had a word with the guys from Node-Red and my Regex was nonsense. Now it accepts A-Z, a-z, 0-9, slashes and underscores - or nothing. Give it an hour max to filter through.

  45. Oh dear, the life of an open source programmer is never easy Peter!

    Thanks for the continuing efforts.

    I sense that my next requests for enhancements should maybe wait until after Christmas 🙂

  46. Doh!

    I've updated but this time you've put some validation on the Name field that breaks things!

    I have names like: "F Hall (03) Jun-Aug On Sunset-1hrs -> 01:00" and I now get a not properly configured error that I can't get rid of.

      1. Yes, well it all makes sense when you see them all lined up on a page 🙂

        I like to give things descriptive names and since Node-RED doesn't allow descriptive text in its nodes, the Name field is the only place you can consistently do that.

        Point is that the name doesn't really need any restrictions on it as it is only used by the Node-RED admin UI and the debug output.

  47. Hi Pete! (or anyone else reading this)

    I'm controlling a device using OpenHAB2. There's a switch type item that sends a msg to a given topic (0 or 1) to turn it off or on. Now, since I have a couple of devices running using Bigtimer schedules, and if the device is already on, there's no problem sending ON (1) from OH2, but if I send OFF (0), the device turns off (ESP subscribed to that topic) but it should return to "Bigtimer control" (scheduled). Any idea on how to implement this? TIA

  48. Hi Peter

    I've installed bigtimer on a new nodejs setup. I have one problem with it. seems to be not running properly when you set the off time to a 'minutes' value. for example: set start time to 19:00 and stop time to +10 minutes then deploy. you then get on for around 3h and 45 minutes. the system time is 19:00.

    all parameters have been left to their default original values.

    Any advice would be highly appreciated.

    Thanks

    1. Well, it looks like no-one including me actually has used that up to now - I'd never noticed it but I didn't put the support code in for that. All fixed, give it maybe an hour and grab the updated version - you can just install as normal.

      1. Got the update. Thanks a lot

        What would it take to increase the resolution of the 'start' and 'end time' from a 15 minutes interval up to one minute? I presume it may be avoiding to load 1440 values into the combo boxes? if that it the case, may I suggest adding 2 text boxes just below he combo boxes. These 2 new text boxes will get their values from the combo boxes once the user makes a selection. The user may then edit the values in the text boxes to adjust the minute resolution.

        I have started to use the timer to automate things in three locations ( 2 town houses and an apartment)

        Many thanks for the hard work and the quick response... & Merry Xmas!

  49. I am in the UK and running big timer on node red on top of a DiskStation. I have what looks like a time zone problem.

    Basically the only way I can get to send the on/off messages at the correct times is to specify a UTC offset of 3 (three).
    Background: I only started playing with big timer yesterday and started with version V1.4.85. I just updated to V1.4.86 which also seems to have the same issue. The DiskStation kernel time is correct (UTC) and the DiskStation admin screen shows the correct time.
    I have tried deleting and recreate the big timer node after performing the upgrade since I am pretty sure that is required to load the new code.

    Anyway from what I have seen changing the UTC offset does not have the effect I would expect but perhaps I am miss-understanding the function.

    Also as a feature request could we specify the time offset as time zone name i.e. “BST” rather than a number since to cater for automatic daylight savings time.

    The attached image taken around 9:15pm shows the off time set for 11pm, the time left before the trigger (~1h 45m) and the UTC offset being set to 3 (when it should currently be set to 0)

      1. Don't worry about this I did a simple "input->timestamp" to "debug output" and converted the epoch result manually.

        The result was node-red thinks the time is off by three hours.

        I probably should have undertaken a manual installation of node-red instead of using the synology package manager.

        1. Update:
          This must have been a synology problem. It was resolved when I re-enabled automatic NTP updates.

          I have no Idea why that feature was not enabled by default but I noticed the manual setting for the synology time was showing with the three hour offest (even thought it was set for the correct timezone).

          I guess the system control panel time was corrected by my browser correcting for its local timezone.

          Anyway resyncing with NTP fixed the issue.

          Sorry for the confusion.

  50. Hi Peter,

    Love your work. This is perfect for what I want to do. My only question is can we send text strings into BigTimer so we can adjust parameters, ie change start times, on days etc? Can we also have a setting to calculate the finish time based on a duration field? so we want to turn the timer on for 45 mins, on mon-wed at 8pm. Idead behind this is to setup drop down menus/buttons etc in a gui.

    Thanks for all your hard work!

    Ryan

    1. Hi - this is an old question - you can turn the unit into manual - and other features with an injected string - but not set the start and stop times as they would not survive power cycling. There is a duration field - I just updated that yesterday as there was a bug.

  51. Hi Peter!

    I've just started out with node red and big-timer is one of the first modules I've installed, I really appreciate your work behind this module.

    I'm trying to build a DIY irrigation controller, normally this is a very straightforward configuration and a direct use case for the bigtimer module where irrigation zones can be started and stopped at specific times. But I have a different set of requirement. I have a mqtt topic to inform about the water pump running status. Here in India irrigation pumps run erratic time schedules due to state electricity supply schedules, maintenance downtimes and breakdowns which is further complicated by water availability issues. We have dry run protection systems for times when the water runs out. Thus the pump only runs when both electric supply and water are available.

    As discussed in your previous posts, setting start times and stop times via an input is not possible for various reasons. So is it possible that a countdown timer functionality be added and the countdown timer be started, paused and resumed from an input? (just like on, off, auto and manual presently available) Thus making it possible to start countdown timers once the pump is up and running and pause them when the pump stops, resume again when the pump runs again and then automatically stop when countdown ends.

    In short i'm looking at running my irrigation zones 1 and 2 for 2 and 4 hours respectively one after the another per day. The pump usually runs a cumulative total of 8 hrs per day split into multiple unpredictable shifts throughout the day.

    The timers also need to reset at
    1. the end of the day (00.00 am) if they are paused/completed/not started at 00.00 am
    or
    2. the first paused or completed event after the end of the day(00.00 am) (because pump can come on at 10 pm and run till 4 am the next morning. we don't want the timer to reset in between)

    Countdown timers could be a generic requirement also IMO.

    Regards,
    Indrajit.

  52. so If I'm wiring the 1st output into a function node where I want to check the value of that first output...what am I telling it to check for?

    msg.state==="on" or "off" OR msg.state===1 or 0 ?

  53. Hello Peter,
    First of all, thanks for ytour hard work, that makes our professional lives much easier.
    I was trying to install bigtimer node on my node-red installation. I followed all the different advices that you give in order to install it (under windows 8.1 and node-red v 0.15.2) The thing is that the module´s directory is actually created in /.node-red/node_modules; and when you go to "manage palette " section you can see it as installed too. But whenever I run node-red I can see this message on the console:

    [bigtimer] SyntaxError: Invalid or unexpected token

    And Bigtimer is then nowhere to be found.
    Can you give me any hint on this issue?

    This happened with other modules like "Biglib". By the way, I did manage to install scheduler and it worked ok.

    Best regards,

    Javier

    1. There is indeed an illegal token in there and I have NO IDEA right now how that crept in. The "debugging" doesn't exactly help as there is no more info. Working on it - but don't expect miracles today - dentist appointment coming up soon. Anyone out there who wants to take a look - it has to be in one of the files bigtimer.js, bigtimer.hrml or package.json in the /home/pi/.node-red/node_modules/node-red-contrib-bigtimer folder...

      Annoying - the one time I wish I was doing versioning.

      1. GIT!

        Not you that is 😉 rather the git source control system, the heart also of GitHub.

        That does versioning for you and lets you do easy rollbacks and so on, integration with GitHub means much easier contributions from other people, issue tracking, documentation, etc. There are GUI clients for Windows and Linux if, like me, you can't get your head around the arcane commands.

        1. arcane commands are nerd's food 🙂
          ever seen a SINGLE hacker using a mouse in movies and tv shows? 🙂
          BTW, Peter uses bitbucket for his sources, so i think it should have github equivalent tools...

          p.s.: git was invented by Linus Torvalds, "inventor" of that other cool little thing called Linux 😉

  54. Hi Peter great work!
    I'd just like to get a sanity check opinion on the use of a couple of timers in a flow that sort of follows your 'OR' example. I have a heating system setup with a timer for the morning schedule and another timer for the evening schedule. What I'm doing is merging the output of the timer schedules into a single function which merges the state of both timers into a single output. I then shove this through a delay node to rate limit outbound mqtt messages.

    The innards of the merge function looks like this:

    context.earlystate = context.earlystate || "0";
    context.latestate = context.latestate || "0";

    if (msg.topic === 'EarlySchedule') {
    context.earlystate = msg.payload;
    }
    else
    if (msg.topic === 'LateSchedule') {
    context.latestate = msg.payload;
    }

    var on = (context.earlystate == "1" || context.latestate == "1");
    return {"topic": "heatingState", "payload": on ? "1" : "0"};

    I've attached a screenshot of the flow.

    This seems to work fine but I'd like to ask if you think this is this the right way to go or am I completely mad with this arrangement?

    Cheers
    Joe

    1. Looks great, I'm at a loss as to why so complicated however.. you seem to be checking the input basically for 1 and 0 - and accordingly returning one or 0 - why do you need anything in that function? I'm probably missing uses for that info elsewhere.

      1. Thanks, good question and well, that's exactly the thing I'm seeking the sanity check on 🙂

        It's probably not completely clear what's going here from what I said previously so I'll try and add a bit of clarity: the chunk of JS in my last post is the innards of the "StateMerge" function node that can be seen in the screenshot and what it's doing it taking the resulting output messages from both BigTimers and merging them into a single message so that this single message can be used to send a single and consistent 'one shot' rate limited ON or OFF mqtt outbound message to control my heating system.

        If I don't perform this post-timer "StateMerge" operation and attempt to feed the timer messages directly to mqtt (delay rate limited or not), I saw I can then potentially get two mqtt messages in very near proximity to each other when controlling/overriding the timers via the input on,off,auto override words..which I'll say is completely expected and by-design behaviour of BigTimer.

        The thing here is that during testing, I found this type of setup can start to go wrong especially when controlling the override input messages to the BigTimers (on, off, auto etc) because one of the 2 outbound messages leaving the BigTimers always "wins" and the outcome of that win depends on the state of timers at that point in time (1st timer ON, 2nd OFF or vice versa).

        This unexpected side effect meant that I either saw a heating ON mqtt signal (1) followed by a heating OFF mqtt signal (0) or vice versa and this behaviour was non-deterministic and totally undesirable.

        The problem is completely solved via introduction of the merge and rate limit mechanism so there's no problem at all really but I really just wanted to check if I was doing things right by handling/merging the output of 2 BigTimers in this way or if I'd missed a trick somewhere.

        Sorry for rambling on, I hope this makes sense

        Cheers
        Joe

  55. For the BigTimer, how do you specify latt/long correctly?

    My home is at 40.1304° N, 75.5149° W. How do I specify N/S or E/W in the properties of the BigTimer? 40.1304° N, 75.5149° W is different from 40.1304° N, 75.5149° E or 40.1304° S, 75.5149° W or 40.1304° S, 75.5149° E.

    1. As often the case - VASTLY insufficient data to answer the question. what do you mean by "configure. If you can inject into the input - yes, you can fire stuff in from any node - if you mean set the start and stop times - no - you do that in the normal node setup.

  56. Sorry for the question, but super new to this. I am trying to accomplish the following:

    Based on SunriseHour > trigger lights to come on at a certain offset to sunrise. Example IF SunriseHour >= 7, at Sunrise+60, turn on X lights.

    Figured I'd accomplish this by:

    Injecting the global SunriseHour at say 4 am each day > to a switch node checking for payload value > into one of several BigTimers that will fire on the specified sunrise offset.....but seems that would be injecting a value of say "7" into BigTimer...which I cannot do, correct?

    Do I need to place another function in between the switch and BigTimer to basically say if the switch output is "7", return "on"? Please let me know if I'm on the right track.

      1. well....if sunrisehour is 7 vs 5, I want to start my flow an hour prior to sunrise, otherwise if 5, I want it to start promptly at sunrise....the timer only gives me an output of 1 or 0 at the time specific in the timer...I thought?

  57. I was disappointed to find the big-timer node not available in FRED. So after I made a request to have it added, I got a reply from sensetecnic this afternoon that it has been added. Now time to play!

  58. Hey Pete,

    First off, hats off to you for Big Timer and all the support you've provided this community! I scrolled through a bunch of the messages and came up with a whole bunch more use cases for this...

    Curious, is there a way to set a separate Topic Msg for off events? It's not a show stopper as I think someone above used a function node to do something similar. But thought I'd throw this out to you.

    Thanks!
    Brad

    1. No but there's a simple way to do it - simply take the payload, ignore the topic - and put any topic and payload into the payload, separated by a comma - then split them apart in a function block. Simples!

  59. Hi Peter, ive been playing with your bigtimer for my terrarium automation. Quick question. I have some devices that cant stay in manual for more than a minute. So I figured id set the timeout to 1. But this doesnt seem to work. It remains in manual mode. Or at least, the status claims it's still in manual/off mode.

    Am I misunderstanding the timeout option?

    Thanks!

    1. Hi there Cor.

      So two things - let's say the timer is OFF all (auto) and you inject (ON) - the manual status will revert to auto on the next change of auto state - OR X minutes later if that X (timeout) is a sensible value. TWO things however, it was meant for longer periods - and 1 does not work at all well. Also the timing is based on real minutes, not a minute after you press the button - so for very short periods like 2 seconds - the actual period is highly variable - that is because I did not want the overhead of a timer checking every second. So consider the timeout valid for longer periods - 5 minutes or so.

      I could fix the "1" issue easily but would have to ponder what effect that might have on the many people using the timer right now.

      1. Hi Peter, I could probably work something out with a delay node or something and force it back into auto mode after 30s. These are things like misters which you dont want to run for very long.

        It's actually quite complicated to do this stuff well and not kill your terrarium by accident. I have failsafes for every scenario I can think of. Things like a node-red reload during a delay node, and not receiving the off signal.

        Little bit off topic, but I just want to say I love your site. Tons of overlap with stuff im working on so that saves lots of time. Going to be programming a bunch of sonoffs soon.

  60. Hi Peter, I do like the node, but I am having a problem with the timeout. I changed the timeout to 2, and manually injected On. Bigtimer actioned the On command, and in NodeRed the message under the node showed "On Temp Override". All good. After 2 mins, that status message changed to "Off Temp override", but the node didn't do anything else - it didn't go back to auto status, and it didn't execute the Off msg, nor the Off Text. This was before sunset, i.e during an Off period. I also tried it with a 10 minute timeout that did the same. Am I missing something in how the Timeout is supposed to work?

    1. Good afternoon Ian. I tried the timeout and you're right - it doesn't work correctly. Well spotted. Further, the SYNC function doesn't - but as I neglected to document that, no-one knows about it. I have fixed this and have released version 1.5.0 which will appear sometime this afternoon - with some additional status output available in the first output msg.

      Manual operations will affect the timeout - so now you can use "sync" to quickly get through the timeout for testing. In the first output - if you look at the whole message, you'll see msg.timeout so you can monitor it.

  61. Hi Peter,

    in combination with your (great!) BigTimer I needed something to determine whether if its business day at that moment, if its holiday, which weekday it is, regarding energy consumption if its lower or higher tariff etc. So I wrote a function and decided to share it so anyone could use it for its own purposes. The code naturally includes our national (Slovenian) holiday sets. Ofcourse modificaitions are needed for use in any other country which has its own set of holidays and energy consumption tariff rules.

    https://gist.github.com/mrizvic/f8c6b1db1bd815d49d76657cf6977e4a

    Im using it in combination with BigTimer to turn on the light in the morning when its time to get up but only if its business day 🙂 I also pass messages to it from energy meter and then calculate energy consumption in kWh for lower and higher tariff. And water heater is turned off in higher tariff at 20:00 so water is not heated during showering time but gets heated when lower tariff kicks in at 22:00.
    I hope anyone else could benefit using this stuff. Im also open for suggestions and improvements!

    The code is under beerware license 🙂

  62. Peter, wonder about using the Bg Timer with my Wemo Light Switch. I've tried the Wemo nodes available, but they don't recognize the switch. I can ping the switch without any problems and the switch does turn on and off as per the app on a cell phone. I'd like to try and get it under control with Node-RED, if possible.

    Big Timer looks to have everything covered as to how I'm looking after the switch now.

    Any suggestions?

    1. Hi - What you are trying to achieve is basically the opposite of what is covered in http://tech.scargill.net/fauxmo-alexa-delights/. Namely where that talks about imitating a wemo switch and then redirecting messages meant for that switch, you need to discover the address of a real switch and then send messages to it. Belkin have deprecated their API but it is still a uPnP device so either of the following should work. If you want to go the native uPnP approach then https://objectpartners.com/2014/03/25/a-groovy-time-with-upnp-and-wemo/ should work alternatively you should be able to adapt the following solution into a node-red "node compatibilty" node.

  63. Hi Peter,
    maybe it is something already discussed.... i was looking a way to configure Bigtimer via HMI, otherwise you always need to make changes at configuration level.

    have you already considered this?
    thx
    M

      1. yes, of course,
        however as a UI user you may not have access to configuration page, (unless i miss something...) and difficult to create a different node for each case....

        you can create one timer for each main mode of operation, but assuming you need to change some configuration data, such as sunset offset you need to go back to configuration mode.
        i think that an IoT system should be fully manageable from UI

        M

        1. Hi there. That is not what BigTimer is intended for. It is intended that you will set the times in the configuration page - and either leave it to run automatically or inject manual override commands.

          However as loading the timer also loads the source, you are welcome to make a different version.

          Making a simple ui controlled timers in a Node-Red function would let you do what you want.

Leave a Reply

Your email address will not be published. Required fields are marked *