I would stand on @dceejay's side also. 
1 Like
I was wondering why you might ask for that - since each fires with its own topic (and a whole bunch of identifiable other properties in msg.cronplus) but I think you mean to simplify the setup of the switch node to basic numbers.
Its not an unreasonable request but not certain its a good thing to rely on numbers (one change to the cron node screws up your switch)
I agree with this also - but i will play devils advocate.
You are right. It is a very valid option 
I very rarely have multiple entries in one cron node.
But, as @dceejay wrote, it is maybe more messy than useful !!
GV
1 Like
No no, I just didn't realise each have their own topic. This was just a suggestion on how to simply solve multiple outputs need. But doesn't this mean it's already solved?
It is the primary reason i added a topic per crontab - to be able to identify the events.
so what @bakman2 suggested would simply negate the need for a switch after the cron node.
My strong preference is hook up a multiple schedule cron node to a switch & let it do what its good at (directing flow).
This keeps it slightly more atomic & a bit more in line with other nodes that rely on topic (like MQTT etc)
2 Likes
Your CSS doesn't seem to play well with my custom theme. 
I'll probably need to add node specific overrides if I'm going to use this with my sensitive eyes. 
As i dont use any themes - can you confirm its merely the schedule row containers color?
or is that being pushed off under the side bar too?
Can you provide your these file? (and instructions on use 
)
It's still a bit WIP, to be released on the same repo as node-red-contrib-theme-midnight-red but the current version with quick instructions is here: https://github.com/ristomatti/node-red-contrib-theme-solarized-dark-grey/tree/theme-builder (note the branch, master branch only works with 0.20.x)
The base colors are done using the theme builder script. There's yet only little custom CSS overrides.
If by sidebar you're referring to the node help - it looks fine.
Hi all, i woulnd mind your thoughts on this issue "Make cronjob persistent".
I have already on a separate branch added persistence
It works - but...
It is already possible (via the dynamic commands "export-all-dynamic" and "add") to do this in the node-red runtime (but it takes a number of nodes and is not terribly simple for new users)
So do I go ahead and put it in master?
Operational notes:
- If the box is checked, when ever a dynamic schedule is added / removed / modified, all dynamic tasks are exported to
userdir/cronplusdata/node.id.json - If the box is checked, when the cron node is initialised (deploy / restart) AND a file named
userdir/cronplusdata/node.id.jsonexists, it restores the dynamic schedules
Thanks for looking.
1 Like
No need - i had a hard coded value on the list row div.
Sorted (hopfully).
Does this look consistent?
2 Likes
The white border is not something I've got with other nodes but it definitely looks good enough and might as well be a color variable I've missed. Great job and thank you for taking the time to support theming!
Last update before publish to NPM 
(beta.2 now in github)
Please see the readme for an overview of functionality & animated screenshots...
Whats changed since Beta 1...
- All basic dynamic commands (like stop, start, list, remove, export etc) can now be easily operated by just setting the topic of the incoming msg. - greatly simplifies automation
- Dynamic schedules can now be persisted
- Layout and CSS improvements to play nice with custom themes
- Next status now more descriptive
- indicator for dynamic schedules are a
ring, static schedules show a soliddot
- indicator for dynamic schedules are a
- documentation updated on readme and built in
- improved setup validation (duplicate names etc)
- bug fixes
Been running now for 48h - I have checked every dynamic operation & monitored solar events for 5 areas to ensure correct data is sent at the right time.
Fingers crossed for imminent publish
I would appreciated it if one or more would be kind enough to install and check it out?
Cheers, Steve.
3 Likes
V1.0.0 (minus the beta tag) in github now 
Not yet on npm so anyone willing to test it out before i hit the button - I would greatly appreciate some feedback.
Please see the readme for installation instructions.
Last minute changes...
- separated out date sequence expressions from cron mode to its own mode (i have my reasons - but i forget now why)
- switched popup map tile source to openstreetmap (looks way nicer)
- jiggled the help about
- removed most (& improved some) console logging
- src tidy up
Thanks for all your feedback over the months.
Steve.
3 Likes
Looks great! I noticed two small things on a quick test:
- loading dynamic schedules keeps spinning if node hasn't been deployed at least once
- "+ option" button name is not obvious - change to "+ add" to be consistent with for example switch node?
2 Likes
Done and done.
2 Likes
That was fast! I only just now noticed my NR debug console got this when opening the dynamic schedules (when it just spinned):
TypeError: Cannot read property 'tasks' of null
at /home/pi/.node-red/node_modules/node-red-contrib-cron-plus/cronplus.js:1615:37 at Layer.handle [as handle_request] (/usr/lib/node_modules/node-red/node_modules/express/lib/router/layer.js:95:5)
at next (/usr/lib/node_modules/node-red/node_modules/express/lib/router/route.js:137:13)
at /usr/lib/node_modules/node-red/node_modules/@node-red/editor-api/lib/auth/index.js:75:13
at Layer.handle [as handle_request] (/usr/lib/node_modules/node-red/node_modules/express/lib/router/layer.js:95:5)
at next (/usr/lib/node_modules/node-red/node_modules/express/lib/router/route.js:137:13)
I assume this got fixed already when you looked at the issue?
Edit: maybe I'll just test 
Yep.
The http endpoint couldnt get tasks that hadnt yets been created (good catch by you) so couldnt return list of dynamic tasks.
Simple fix - but thank you for checking this out.
anything more - please let me know, I am keen to get this out.
Thanks.
