Woo! Excellent stuff. Thank you @MichMich - I’ll give it a test-drive over the weekend and feed anything constructive back

Thanks @Mitchfarino - it was user-error. I visited the developer page rather than clicking on the link you provided :) I deleted my previous post in shame after I realised my error.

All sorted now. It’s fabulous. Thanks for sharing your code with the community by the way!

Fabulous! Thanks for the heads-up @MichMich - it’s the rate of development of your mirror by everyone, that makes it so awesome.

I’ll stay tuned to the announcements

Ooo! Good thinking @yawns - that’d possibly reduce a bunch of coding down to a bit of tweaking. I’ll investigate this option first. Thank you.

Thanks for the suggestions @mochman - I didn’t even think about a crontab and restart approach - it’s a sledgehammer but would get the job done whilst I figure out how to implement one of the other options (or plead for someone to do it) :)

The separate co-ordinator module approach using a payload notification feels like a really good solution - that could be fed the results of the calendar refresh, generate the destination payload and push it to the traffic module - in effect, negating the need for the traffic module updateinterval.

To my non-developer brain this requirement seems like a small step, however common sense tells me that’s unlikely to be the case.

If I already use a Google maps API (or Bing for that matter) to display my commute time to work which is calculated from the start and end points provided in my config.js, how could I go about making the destination point dynamic, based on the date?

My thinking is along the lines of;
if = weekend, destination = town
if = week, destination = work

this would need to be a variable that’s injected or more likely, logic hard-coded into the travel helper I guess?