@infamoustiggr, thanks!
Just make sure sure to pay it forward if you have the opportuniy to help someone else here in the forums.

Description:

MMM-ResRobot is a module that displays departure times for one or more public transport stops in Sweden. It uses the ResRobot API which is a collaboration between a number of public transport providers.

Screenshots:

Download:

Version 1

Initial release

Version 1.1

One minor change: transportation type icons are now displayed (to the left of the linenumber). All rail-bound types are displayed as trains (fa-train), all buses are displayed as bus (fa-bus) and all waterborne transportation is displayed as ship (fa-ship).

Version 1.2

Added config option skipMinutes. Allows for skipping of departures within skipMinutes minutes from now. Default is 0 (zero).

Version 1.3

Reworked the updating logic. For some reason the module stopped updating in some cases. This version also reduces the number of API calls to Resrobot.
NOTE! The configuration has been changed in this version. Added new array “Routes” consisting of pairs of “from” and “to” (“to” can be empty but must be present). This is a breaking change.
Previous configuration:

from: "from1,from2,from3",
to: "to1,,to3"

New configuration:

routes: [
  from: "from1", to: "to1",
  from: "from2", to: "",
  from: "from3", to: "to3",
]

Hi all,
I’m running my mirror on an original Pi B 256MB with no issues at all!

The Raspbian version I use is DietPi which is really great on a 256MB Pi. Note that the standard user in DietPi is “root” rather than “pi”. If you use standard Raspbian just replace all occurences of “root” with “pi” in the scripts below.

As the documentation states you start off with installing the Server Only option. If I remember correctly I had to manually install many of the node module dependencies as they weren’t installed correctly otherwise

I use matchbox as the window manager because it suited my needs best. It uses less resources which again is great for a 256MB Pi.

I’m using systemd scripts rather than pm2 as I think they work better. My scripts:

magicmirror.service:

[Unit]
Description=Node.js Magic Mirror Server

[Service]
ExecStart=/usr/bin/node /root/MagicMirror/serveronly/index.js
WorkingDirectory=/root/MagicMirror
Restart=always
RestartSec=20
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=nodejs-magicmirror
Environment=NODE_ENV=production PORT=1337

[Install]
WantedBy=multi-user.target

matchbox.service:

[Unit]
Description=X11
After=X.service

[Service]
Environment=DISPLAY=:0.0
ExecStart=/usr/bin/matchbox-window-manager -use_titlebar no -use_cursor no
User=root
Restart=on-failure

[Install]
WantedBy=multi-user.target

Kioskbrowser.service:

[Unit]
Description=Kiosk Browser
After=matchbox.service magicmirror.service
Requires=magicmirror.service

[Service]
WorkingDirectory=/root/MagicMirror
User=root

Environment=DISPLAY=:0.0

# Don't activate screensaver
ExecStartPre=/usr/bin/xset s off

# Disable DPMS (Energy Star) features
ExecStartPre=/usr/bin/xset -dpms

# Don't blank the video device
ExecStartPre=/usr/bin/xset s noblank

ExecStart=/root/kioskbrowser http://localhost
Restart=on-failure

[Install]
WantedBy=multi-user.target

Note that the kioskbrowser service relies on a user script called /root/kioskbrowser. This script has some extra logic to avoid the initial white screen when midori has loaded but not fetched any magic mirror content. The script perform a curl call to see if the magic mirror module is responding. If not it waits for a few seconds and then tries again. Once the magic mirror responds it starts midori in fullscreen mode.

/root/kioskbrowser:

#!/bin/bash
status=1
url="$1"
wait="10s"
tries=0

# URL must be first argument
if [ -z "$url" ]; then
  exit 1
fi

# Make sure that the url is reachable
while [ $status -ne 0 ]; do
  let tries++
  curl --fail --progress-bar -o /dev/null --url "$url"
  status=$?
  if (($tries > 10)); then
    wait="30s"
  fi
  if (($tries > 20)); then
  wait="5m"
  fi
  if (($tries > 30)); then
  echo "$0: Can't load URL $url"
    exit 2
  fi
  sleep "$wait"
done

# Start browser in fullscreen mode
/usr/bin/midori -e Fullscreen -a "$url"

Hope this helps.

@ajomannen sorry, the curly braces got lost in my copying. I have updated my previous post.

Hi,
you need to specify a station id in “from” as well. “from” is used to find the station’s departures, “to” is used to differentiate between destinations going from the “from” station.

Change “from” to ‘from: “740000950,740000950”’ to make it work as you want.

@infamoustiggr,

Installed packages
If you are running dietpi or Raspbian Jessie systemd should already be installed. Otherwise you need to install and enable it. Google is your friend.

Midori should also be installed but Matchbox most likely isn’t. Install it with:

sudo apt-get install matchbox-window-manager

Systemd
The systemd scripts are all located in /etc/systemd/system. To create magicmirror.service enter the following command (I’m using the editor nano):

sudo nano /etc/systemd/system/magicmirror.service

Paste script from above and edit to suit your needs.

Make the script executable with the following command:

sudo chmod +x /etc/systemd/system/magicmirror.service

Repeat these steps for the other scripts by replacing magicmirror.service with the appropriate name.

Custom script
For DietPi the scripts are located in /root and for Raspbian they are located in /home/pi. Change to the appropriate directory with cd.

nano kioskbrowser

Paste the code from above and save/exit
Make the script executable by running:

chmod +x kioskbrowser

MagicMirror config
Make sure that MagicMirror has the correct port set in config.js. (Look for “port”: in config/config.js and make sure it is set to 80. Otherwise modify kioskbrowser.service and change the url http://localhost to http://localhost:port where port is the port number of MagicMirror.)

Scheduled on/off times
If you’re like me and do not want your mirror active during the night you can either use a module such as MMM-ModuleScheduler or a cron script that turns the monitor power on/off at set times. I use the latter. To do that you enter the command:

crontab -e

and paste the following lines

59 05 * * *     /usr/bin/vcgencmd display_power 1
09 23 * * *     /usr/bin/vcgencmd display_power 0

Exit and save.
The first line turns the monitor ON at 05:59 and the second line turns if OFF at 23:09. Modify according to needs.

Reboot your pi and enjoy!

@ianperrin
It works! It was probably the code update that fixed even though I also simplified the cron expression.

All my other schedules (which hides, not dims, modules) worked before even with arrays having double quotes and leading zeroes. And they still work.

Great work @ianperrin, and thank you for a must-have module!

@broberg @FallandeGubbe

One thing popped into my mind: the Pi 1 is much slower than a Pi 3 and loading all the modules takes quite some time. Could it be that you are trying to open midori before MagicMirror has loaded all the modules and therefore is refusing connections? That in itself was the reason I had to go with a script that checked that midori was listening before launching MagicMirror.

Have you checked with journalctl that magicmiror is ready for action?

@johnnyboy
That’s technology development for you. Of course, in this case @infamoustiggr has the luxury of having someone with the exact same equipment already having the solution running.

As to the speed issue, apart from taking a few extra seconds on boot, I have no issues whatsoever with speed for functionality on my Pi 1. But I must admit it took me a number of tries to get there! Doing it with little to no experience with Linux is really tough.

@ianperrin @Jopyth: sorry, wasn’t aware that MMM-Remote-Control had that ability. I would recommend MMM-Remote-Control instead of MMM-tvservice to the general user as it covers all functionality needed.

MMM-tvservice is more for the linux enthusiast who wants a program to do one thing and one thing only. I am not running MagicMirror through PM2 but rather directly via systemd so I cannot use all functionality of MMM-Remote-Control without editing the source. Also, as I am running through systemd I do not need to prefix the commands with sudo as the service already runs as root.

@ankonaskiff17 In most cases the default values are set so that you do not need to change more than a few values to adjust to your needs. It makes no sense copying the entire config just to set the values to the default ones. That said, yes, you can copy the default block and change it to “config”, just remember to set the other module options appropriately.

@sdetweil has put significant effort into the calendar module and done a great job of fixing all the quirks so expect the default calendar module to be really great in the next MM version! Just be sure to move all your config stuff to config.js so you can upgrade without issues.

@ankonaskiff17 you can always use the Google holidays calendars. They have country-specific calendars for most countries.
google holidays

@sdetweil Aah, missed that one. But you still have to address the issue with calendarfetcher returning “only” maximumEntries even if broadcastPastEvents is set.

@sdetweil It fixes the result while also retaining backward compatibility. From my viewpoint the cause is that calendarfetcher.js not only fetches but also filters. It should just fetch and let calendar.js do the filtering. But that would require substantial changes to both files. My “fix” is just a few lines of code.
But I am all for fixing the cause!

@wuermchen I think your original problem was in /boot/config.txt where you had spaces around the equal sign for display_rotate.

@sdetweil I ran @BigSky 's calendar through my latest fix and it showed up correctly.

I don’t really see any relevant use case for broadcastPastEvents. It should just be left at default (false) and forgotten.

I do see a need for broadcastEvents.

@BigSky I know, recurring events is not where the calendar module really shines…

There is work ongoing to address as many issues as possible. Could you provide an ICS-file that can be used for testing the above?

@BigSky You can limit the number of days in the future by setting the parameter maximumNumberOfDays to something like 30 which will fetch events occuring within the next month.

There have been a lot of work done by @sdetweil on the calendar module. Try the develop branch which handles recurring events much better.