@Jopyth Thanks for your interest in my module. As it says in the license, all you have to do is include the copyright notice, should you decide to base your module on mine. Good luck with your module development :).

Also, feel free to play around with it and submit a pull request, should you add additional features.

Thanks as well for your ideas on improving the module. I had originally toyed with the idea of allowing custom module headers but then decided against it as the way it works right now, you automatically notice should you have entered the wrong stop id, which is something that happened to me from time to time when I was still developing the module. If some people feel the need to change the header, I could see myself revisiting the idea.

The update timestamp might be interesting for some people as well, so I’ll consider implementing it. I wanted to have the module as uncluttered as possible and the more info you show, the easier it is to lose sight of what’s relevant.

Thanks again for your thoughts :). It’s always nice to have some fresh ideas to include in further development stages.

@Jay Thanks for your kind words, I’m happy to hear somebody else is running the module on their mirror, I’ve been wondering whether someone else from our our region might eventually turn up here :). Should you run into any issues, feel free to report them here or over on the Github page.

Unfortunately, there is very little I can do to help you with your request. The data is pulled from the same dataset as the results you can see listed on http://live.kvv.de - try it for your stop and you will see that the maximum number of connections is 10 in your web browser as well. This is the way the service is designed, so if the KVV people decide to change their API at some stage to allow for more connections, the module should automatically pick that up and offer you more connections as well. If your stop is in the inner-city area, you are bound to end up with trams and trains that depart within the next few minutes. If your stop is only serviced by one line, you can normally see pretty well into the future :).

It would be possible to add a config option to only show trams that depart in, say, 5 minutes or later, but this would only shorten your list to the few of the 10 given trams that depart in 5 minutes or later. There is no way for me to add an option to extend the list of trams into the future by cutting the first few connections. This is something the API people would have to do.

I thought I had added this information to the readme, but I’ve just notice that I hadn’t, so thanks for that, will add this piece of information.

@MichMich I agree with you, which is why you have merged what I have done already :D
https://github.com/MichMich/MagicMirror/tree/develop/modules/default/calendar

@dr0pb0x Anything is possible, but I doubt it. Please have @kapsolas help you with this, as I don’t have any direct way of testing it. As far as I’m concerned my code adjustments should work.

@strawberry-3-141 is right, but if you generally like the clock module the way it is and just don’t like the way the date is being displayed, you can simply change it as has been pointed out and add

/modules/default/clock/clock.js

to the end of the file .gitignore you can find in the MagicMirror main folder (for example by using sudo nano .gitignore).

Not sure, if you’re new to the Linux environment as well, you won’t see the file using the dir command, as the dot at the beginning makes it a hidden file. Anything you add to .gitignore will not be updated when you perform a git pull, so be careful with adding files to the list, as you may break your installation when some parts of the mirror get updated but others don’t. I wouldn’t worry about adding the clock module, though.

I have found another detail that bothered me. If the calendar is set to ‘relative, 6 hours before an event occurs the calendar would start showing the time in relative terms (for example: “In 5 hours” - but then it would stay that way until it would switch to “In 4 hours” an hour later, which is pretty confusing as far as I’m concerned. If I’'m not mistaken, it stays pretty vague until 45 minutes before the event when the countdown truly starts).

I found this behavior rather counter-intuitive, as I might want to check the mirror to find out the exact time when an event starts. This is why I have introduced a tag getRelative, which can take any value between 0 and 48 hours. So if a user configures their calendar like this:

modules: [
...
    {
        module: 'calendar',
        position: 'top_left',   
        config: {
               getRelative: 0.5
          }
        }
    },
...

their events start getting relative half an hour before the event (“In 30 minutes”), if they decide they don’t like relative times at all, they can set it like this: getRelative: 0. This way, it is easier for users to customize the calendar’s relative behavior to their needs.

This is now included in my pull request.

On a related note: Can anybody tell me why there is a timeFormat: absolute option? I set my calendar to absolute but didn’t notice any difference.

@dr0pb0x I’ve tried it with my forked version after changing the module to simply retrieve any picture from the internet. It’s working fine.
The only limitation is that you can’t set the MaxHeight in relative terms (percentages), other than that, it works as intended as far as I can tell without actually using the API.

@dr0pb0x Have you tried using my forked version here:
https://github.com/yo-less/MMM-Instagram

@dr0pb0x , @kapsolas I had a quick look at your code (Not a fan of the bit.ly link) and if you go about displaying the Instagram image this way:

	var imageWrapper = document.createElement("img");
	imageWrapper.src = tempimpage.photolink;
	imageWrapper.style.maxWidth = this.config.instaMaxWidth;
	imageWrapper.style.maxHeight = this.config.instaMaxHeight;
	imageDisplay.appendChild(imageWrapper);

you should be able to specify two parameters instaMaxWidth and instaMaxHeight that the user can change in their config.file so the beginning of your MMM-Instagram.js file would look like this:

    defaults: {
        format: 'json',
        lang: 'en-us',
        id: '',
        animationSpeed: 1000,
        updateInterval: 60000, // 10 minutes
        access_token: '',
        count: 200,
        min_timestamp: 0,
        loadingText: 'Loading...',
        instaMaxWidth: '100%',
        instaMaxHeight: '100%'
    },

Now, any user of your module could define their own maximum image width and height, either by specifying an absolute figure like ‘300px’ or in relative terms using ‘20%’ or the like. I’ve created a pull request, but I suggest you test my code first as I don’t have an Instagram account or Instagram API key to test it.

You can use my fork to do so: https://github.com/yo-less/MMM-Instagram

@cowboysdude: You’re welcome :)

Also, have a look at this post:

dmcinnes said in PIR sensor behind glass?:

Another possibility: I ordered a couple of these $2 microwave radar motion detectors to see if they will work behind my glass. Still waiting to receive them though:

http://m.ebay.com/itm/1pc-5-8GHZ-Microwave-Radar-Sensor-6-9M-Smart-Switch-for-Home-Control-/131864712562?txnId=1245760396003

More details:
http://www.cnx-software.com/2016/04/04/tiny-microwave-radar-module-detects-movements-up-to-9-meters-away-for-2/amp/