Super awesome work on the remote App!

Not sure if you already noticed it, but there is a change in the hide/show mechanism which might be very helpful for you:
https://forum.magicmirror.builders/topic/241/revising-the-show-hide-mechanism/9

Keep up the good work.

For what it’s worth: I’ll be working on a change to the default calendar module this week to broadcast the events to other modules, including any location data. This way any module that want’s to show data based on the calendar can use the calendar data.

Keep an eye on the forum about any announcements. And check out the develop branch for new features like this.

Nice! Time to connect a microphone to my Mirror! ;)

In version 2.1.0 (the current develop branche) the module and nodeHelper API both feature the requiresVersion variable. This allows you to set the minimum version number of the MagicMirror framework that is necessary for your module to run correctly. This is important, because version 2.1.0 will contain some API changes that might prevent your module from running in older versions.

More information about this feature can be found here: https://github.com/MichMich/MagicMirror/tree/develop/modules#requiresversion

Example code:

Module.register("testModule", {

    requiresVersion: "2.1.0",

    start: function() {
       // do something
    }
});

Of course, this feature would be way more powerfull if it was available starting from version 2.0.0. Unfortunately I did not have the time yet to invent a time machine. Therefor you can use a workaround if you really must do some manual checking. Starting from version 2.1.0, the frontend javascript will have a global variable called version. This is a string that represents the current version of the MagicMirror. In the node helper, this string is available via global.version.

So, if absolutely necessary, you can use the following code in your module:

// main module
if (!version) {
    // this is an old version, give the user a warning and don't perform any other new API calls.
}

// node helper
if (!gobal.version) {
    // this is an old version, give the user a warning and don't perform any other new API calls.
}

Since this feature is still in the develop branch, it’s not final and might change. Suggestions are welcome.

Method is implemented. See documentation:
https://github.com/MichMich/MagicMirror/tree/develop/modules#thishidespeed-callback-options
https://github.com/MichMich/MagicMirror/tree/develop/modules#thisshowspeed-callback-options
https://github.com/MichMich/MagicMirror/tree/develop/modules#visibility-locking

@bangee: Check your node log. It should tell you which IP is trying to access the server. Good idea to add it to the “access denied” message. Will put it on my todo list. (PR is welcome!)

Agee! I’ll make sure to add that to the documentation.

Yeah, but I think that is the exact reason why this method should be implemented. One can argue what the desired result is. But by implementing the force option, both scenarios will be possible. Implementing a force function isn’t really a big deal.

Thanks for your input!

Awesome work!

Would be great if you could configure keywords which show/hide certain modules and configure notifications … something like this:

keywords: {
    'HIDE WEATHER': {
        hide: ['weather']
    }
    'SHOW WEATHER': {
        show: ['weather']
    },
    'SIMPLE MODE': {
        hide: ['default','foo','bar'],
        show: ['simple'] 
    },
    'RESTART': {
        notification: 'RESTART'
    }
}

It might be good to know that I’ll probably be implementing this in the coming weeks: https://forum.magicmirror.builders/topic/241/revising-the-show-hide-mechanism

Maybe. I just created a new agenda with a new URL and that solved the issue.

In that case only the server will be restarted, so that doesn’t make sense.

@shgmongohh Could you post the newsfeed part of your config?

It seems there is an error in your config. Could you post the MMM-Nest part of your config, without any access codes? Also, did you follow the MMM-Nest installation guide?

Its just a js file. So you can use /* */. That’s what I do! :)

In most cases this module should not be necessary and probably only causes confusion. I built it for a mirror running on macOS which gives some issues due to an webGL module which causes a buffer overflow after a few days of running. (Bug in WebGL).

So this module is only there for edge cases. In most cases we just need to hunt down the bug causing the UI issue.

@yo-less lol. Missed that. 😂

@yo-less About that last part (getRelative). You might want to add info about it to the calendar readme.

Awesome work! My SO is very pleased with this idea. You might want to add a screenshot to the repo.

Never mind. I created a new calendar and use the new url. Problem solved.