@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.

@SvenT I think that if you just hide the module it will stop updating (but I’m not sure). Try it.

@SvenT I have experimented with a number of algorithms for minimizing updates but ended up with the one implemented. The current algorithm is:

• If initial request, get updates from Trafiklab

• If the first item in departure list (per routeId) is “old”, i.e. before cutoff time (now + skipMinutes), clear list (for routeId) and get updates from Trafiklab

What the above means is that updates only occur ON ACTUAL DEPARTURES, e.g. if a bus departs every 15 minutes the module will get updates from Trafiklab every 15 minutes (per routeId). In rush hour this often means that the module get updates every minute but at night it might only update once per 60 minutes or longer (per routeId). This behavior has the benefit of automatically adjusting to rush hour and slow hours without user intervention or tweaking.

If only one routeId is configured, the number of Trafiklab updates is usually way below the Trafiklab suggestions.

/j

@hango said in mess calendar module (solved for me):

with absolute time format you can play for relative dates on urgency, but for all time relative at line 366 in calendar.js instead

timeWrapper.innerHTML = this.capFirst(moment(event.startDate, "x").calendar());

must be

timeWrapper.innerHTML = this.capFirst(moment(event.startDate, "x").fromNow());

see the diference between first and third picture

Agreed, I spotted the same when I looked at your pictures. Changing calendar() to fromNow() will solve your issue. I will create a PR for this fix but will also try to improve other things that this discussion has brought on.

@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.