@MichMich - some great ideas, keep them coming.

I’ve created issues (or rather enhancements) for these on GitHub - https://github.com/ianperrin/MMM-ModuleScheduler/issues. Feel free to review, comment etc.

@KirAsh4 said in Can somebody with permissions rename my posting bc I have renamed my module...:

It’s confusing to readers when an original post gets changed later. It’s better to make an announcement in the thread. Keep the original for posterity.

Agreed, so would it be possible for creators of threads in the module showcase to have the permission to move comments to the module troubleshooting section and add tags. That way the original showcase remains navigable?

@MichMich said in MMM-ModuleScheduler:

One other feature request:

It would be nice if there is a way to schedule a hide show based on a classname. This way I can give all my modules a class like “day” and “night”, and make a schedule:

Great idea. I was planning on adding a global module_schedule functionality, i.e. the ability to hide all modules at 10pm, rather than having to configure multiple schedules on a per-module basis.

I think the idea of class-based module groups makes for an interesting extension of the idea.

So to take your config example, if the global schedule definition includes the classes property, only those modules with that class are affected. If the global schedule definition omits the classes field then all modules are affected.

One for next week I suspect!

@Alvinger interesting, I’ll check it out.

You may also be interested in taking a look at MMM-Remote-Control. It contains a heap of functions to control your mirror (including turning the monitor off and on, rebooting the pi, restarting the MM process etc) remotely.

I’ve been working with @Jopyth to expose this functionality via the use of sendNotification.

This should allow schedules like:

notification_schedule: [
    {notification: 'REMOTE_ACTION', schedule: '30 9 * * *', payload: {action: 'MONITOROFF'}},
    {notification: 'REMOTE_ACTION', schedule: '30 18 * * *', payload: {action: 'MONITORON'}}
]

Check out the repository on GitHub - the latest code includes this capability

@Jopyth - another great update. Thanks

I’ve added an issue (feature request really) on GitHub to explore whether the functionality of this module could be exposed to other modules so it could be triggered using sendNotification.

e.g. sendNotification('REMOTE_ACTION', {query: 'MONITOROFF'}

I’ve also drafted a pull request with an idea of how this could be done.

If this could be implemented, then things like turning the monitor on and off or restarting MM could be scheduled using a combination of this module and MMM-ModuleScheduler

Agreed.

And perhaps best practice should be that any module wishing to show/hide other modules should include a config option to toggle the use of the force flag.

Let the user decide!

@MichMich

Does this fit the use case?

ModuleA is configured to be hidden at 9am and shown at 6pm by ModuleB using a schedule.

At 9am ModuleB (the scheduler) hides ModuleA.

At 11am ModuleC (Remote Control) is used to show ModuleA.

At 11:30am ModuleC (Remote Control) is used to hide ModuleA.

At 6pm, ModuleB (the scheduler) shows ModuleA

Am I correct in thinking that without the force flag, neither ModuleB or ModuleC could show ModuleA at 11am or 6pm respectively?

An update to MMM-ModuleScheduler is now available which includes the ability to

• Send notifications using a schedule - thanks for the idea @cowboysdude
• Control how quickly modules are shown/hidden (animationSpeed option)
• Override the name of the class used to identify the modules which have a schedule (schedulerClass option)

Check out the updated documentation for more information.

@Alvinger, @cowboysdude

Having looked at the code, there may be certain circumstances where the module is initially hidden, even when the dimLevel option is defined. I believe this only relates to schedules are defined using arrays with a particular show > dim > show > dim sequence.

I’ve pushed an update to try an fix this, so feel free to update the module and give it a go.

Alternatively, (and also highly recommended) would be to minimise the number of cron jobs create by simplifying your schedule as follows

{
 module: "clock",
 position: "top_left",
 classes: "scheduler",
 config: {
  // Show at 06:00 and 16:00, then dim to 50% at 09:30 and 22:30 every day
  module_schedule: {from: '0 6,16 * * *', to: '30 9,22 * * *', dimLevel: '50'},
 }
},

@Alvinger:

A few quick observations,

Firstly I’d suggest removing the leading zeros from each field in the cron expression, i.e. changing 00 06 * * * to 0 6 * * * - some parsers may support this but I believe the cron tab specification states the valid values for the minute field is 0-59 and hour field is 0-23. If in doubt, try using http://crontab.guru/ to test your expressions.

Next up, make sure you updated to the latest version (git pull from the module directory and restart the mirror) to ensure the dim functionality is available to your mirror.

If after ensuring the cron expressions are correct and you have the latest version, you are still experiencing this problem, can you check the output of the log (pm2 logs mm). You should have something like this

MM-ModuleScheduler received CREATE_MODULE_SCHEDULE
MMM-ModuleScheduler is scheduling clock using '0 6 * * *' and '30 9 * * *'
MMM-ModuleScheduler is dimming clock
MMM-ModuleScheduler has scheduled clock
MMM-ModuleScheduler will next show clock at Wed Oct 15 2016 06:00:00 GMT+0000 (UTC)
MMM-ModuleScheduler will next dim clock at Wed Oct 15 2016 09:30:00 GMT+0000 (UTC)

Can you share the output of your log here so I can take a look?

@cowboysdude said in MMM-ModuleScheduler:

Okay I have another curve ball for you… how about … the ability to turn the mirror off and back on with this? :)

So I’m thinking there are a number of approaches here.

One approach might be to add a mechanism to schedule the sending of notifications e.g
notification_schedule: [{cronTime: '0 22 * * *', notification: 'MONITOR_OFF'}, {cronTime: '0 9 * * *', notification: 'MONITOR_ON'}]

Another module could then be built (or may already exist) to listen to the notifications and react accordingly, e.g. control the monitor.

What do you think?

@plumcraft

As @cowboysdude said, you need to configure the classes option to trigger the scheduler.

As you already have the classes option set up for what looks like @paviro 's MMM-FacialRecognition module I would suggest trying the following config.

{
  module: 'MMM-WunderGround',
  position: 'top_right',
  config: {
    module_schedule: {from: '0 14 * * *', to: '0 18 * * *' },
    apikey: 'ad100f1e35ae51d2', // private; don’t share!
    pws: 'pas:IBOULOGN39', //culemborg
    hourly: '1',
    fctext: '1',
    fcdaycount: '5',
    fcdaystart: '0',
    hourlyinterval: '3',
    hourlycount: '2',
    alerttime: 10000,
    alerttruncatestring: 'french:'
  },
  classes: 'for_all default scheduler'
},

Please do report back if you are successful because I haven’t tested the compatibility of the two modules :)

@strawberry-3-141 I encountered the same issue when trying to create a map the showing the route of the last Strava activity.

To continue using google maps, my solution was a little more complex, but if I recall correctly allowed me to specify a callback when loading the Google Maps API. Though I hadn’t thought about loading it in the start function :) :

    start: function() {
        this.mapId = this.identifier + "_gmap";
        Log.log(this.name + ' is started!');
    },

    // Override dom generator.
    getDom: function() {
        var self = this;
        var wrapper = document.createElement("div");
        var map = document.createElement("div");
        map.id = this.mapId;
        map.classList.add("map-canvas");
        map.style.height = "200px";
        map.style.width = "200px";
        wrapper.appendChild(map);

        this.getScript('https://www.google.com/jsapi', function() { 
            google.load('maps', '3', { other_params: 'key=' + self.config.google_maps_key, callback: function() {
                self.initMap();
            }});
        });
        
        return wrapper;
    },
    
    initMap: function() {
        if (typeof google === 'object' && typeof google.maps === 'object') {
            // Create map
            //var mapContainer = document.getElementById(this.mapId);
            var map = new google.maps.Map(document.getElementById(this.mapId), {
              backgroundColor: 'none',
            });
            map.setZoom(8);
            map.setCenter(new google.maps.LatLng(37.4419, -122.1419));
        }
    },
    
    getScript: function(source, callback) {
      var script = document.createElement('script');
      var prior = document.getElementsByTagName('script')[0];
      script.async = 1;
      prior.parentNode.insertBefore(script, prior);
  
      script.onload = script.onreadystatechange = function( _, isAbort ) {
          if(isAbort || !script.readyState || /loaded|complete/.test(script.readyState) ) {
              script.onload = script.onreadystatechange = null;
              script = undefined;
  
              if(!isAbort) { if(callback) callback(); }
          }
      };
  
      script.src = source;
    }

In the end I have currently settled on using Leaflet.js - which, depending on which tile layer you use, has the added benefit of not requiring API keys (one less thing for users to configure), can be loaded locally (and via the getScripts function) and there are existing black and white/grayscale map tiles available which compliment the Mirror.

    // Subclass getScripts method.
    getScripts: function() {
        return [
            this.file('js/leaflet.js'),
        ];
    },

Hope this helps a little

@cowboysdude said in MMM-ModuleScheduler:

Just curious would it be possible not to hide but to dim specific modules?

I’ve pushed an update which includes the ability to dim a module. Please feel free to update the module and use the example configuration to test it out.

@strawberry-3.141 said in MMM-ModuleScheduler:

@cowboysdude adding a css filter to the specific module could set the brightness down

Great idea - will give it a go ;)

@Squawk09 - it is not a requirement to log when receiving notifications, but it can be useful when debugging. To prove you are receiving the notification, change the line to Log.log('The current temperature is ' + this.temp); and look in the browsers console and you should see the temperature displayed when it is sent from the current weather module.

Once you have confirmed that your module is receiving the notifications, you can then move on to displaying the temperature.

The trick is to understand the sequence of events that occur and how they affect your module. In your case the functions in your modules are currently fired in the following order:

• start
• notificationReceived (ALL_MODULES_STARTED)
• getDom
• notificationReceived (DOM_OBJECTS_CREATED)
• notificationReceived (Temperature)

The result is that your getDom function is called before the Temperature notification is received, so this.temp hasn’t been set yet.

Since you cannot control the order in which the modules are loaded, or when the Temperature notification is sent by the current weather module, you need to tell your module to call the getDom function again, after the Temperature notification has been received.

To do this, change your notificationReceived function to

notificationReceived: function(notification, payload, sender) {
    if (notification === 'Temperature' && sender.name === 'currentweather') {
        var currentweather = payload;
        if ( currentweather && currentweather.hasOwnProperty('temperature') ) {
            this.temp = currentweather.temperature;
            this.updateDom();
            Log.log('The current temperature is ' + this.temp);
        }
    }
},

Check out the wiki for documentation, and of course keep asking questions here in these forums :)

@Squawk09

The first (sendNotification) step looks right, depending on where in the currentweather.js file you have added that line. To test it, I placed it the processWeather function just before the this.loaded = true; line, e.g

	processWeather: function(data) {

 		// EXISTING CODE REMOVED FOR BREVITY ON THIS FORUM     

		this.sendNotification('Temperature', {temperature:this.temperature});

		this.loaded = true;
		this.updateDom(this.config.animationSpeed);
	},

However, I think the second (notificationReceived) step needs a little tweaking. Try this

    notificationReceived(notification, payload, sender) {
        if (notification === 'Temperature' && sender.name === 'currentweather') {
            var currentweather = payload;
            if ( currentweather && currentweather.hasOwnProperty('temperature') ) {
                this.temp = currentweather.temperature;
                Log.log('The current temperature is ' + currentweather.temperature);
            }
        }
    },

This first checks whether a temperature notification has been received from the currentweather module and then checks that the payload has the temperature property before assigning it to the this.temp variable.

Do note however that any modifications to the core files and modules will need to be reapplied after upgrading the mirror. To get round this, you might want to consider creating a pull request for your modification in the hope that it will be incorporated within the central code

@cowboysdude Glad to hear it works!

@cowboysdude said in MMM-ModuleScheduler:

Awesome module!! The only thing I found it doesn’t work on is the clock…

The clock doesn’t have a config section and if you add it the config won’t load…

Can you post an example of your config for the clock with the scheduler options?

The following works for me to show the clock at 5 past each hour and hide in again at quarter past the hour…

{
	module: 'clock',
	position: 'top_left',
	classes: 'scheduler',
	config: {
		module_schedule: {from: '5 * * * *', to: '15 * * * *'},
	}
},

@Mitchfarino I’ve not tested the module on windows myself, so I can’t say for sure.

The module requires the cron package so make sure this has been installed by running npm install from the module folder.

You could then check whether cron works on windows by entering the following from the command prompt

cd MagicMirror/modules/MMM-ModuleScheduler
node

Once the node prompt appears, enter the following

var CronJob = require('cron').CronJob;
var testJob = new CronJob({cronTime: '* * * * * *', onTick: function() { console.log('Firing every second'); }, onComplete: function() { console.log('Stopping'); }, start: true});
console.log('Scheduled for ' + testJob.nextDate().toDate());

You should see a telling you when the module is next scheduled for and another message every second the expression is fired (pressCTRL-C twice to stop!)

If we’ve got this far cron is working successfully. What do the logs ( pm2 logs mm ) say? Could you post your config options?