Really nice mirror, indeed!

I’ve the same question as @barnosch. Can you share the name of the mirror supplier? You are in Hungary, right? Do they ship to other EU countries?

One syntax error I spot is in uptimeroot module. The curly bracket of config: is not matched. @Mykle1 writes there is even more which I don’t spot immediately.

  {
  	module: 'uptimerobot',
  	position: 'top_right',
        		config: {
  	useColors: true
  	api_key:'u505342-b40737465f0eada9bb8a',
  },

In such cases it is good to do a syntax check of the config. Please run npm check:config to do so. You’ll get a detailed statement of what is wrong where syntactically. The reference @Mykle1 gives above is a must read. It shows an example of what the syntax check provides you.

If a syntax check does not solve the issue, I’d comment out all modules but one and start the mirror. Use /* commented out module */ to make multi-line comments. If start-up works, you add the next module and restart. Repeat this until start-up fails which means you’ve found a(!) module that causes the issue. Please note that there might be more than one wrong module.

If you have the module, copy the desired config elsewhere and redo the module’s configuration with the simplest possible config, which you often find in the ReadMe file of the same module.

Good hunt.

What is an auto feeder machine? Can you please describe in more detail?

Hey @AxLed, sorry for the late reply. I’ve had a look at your code. It looks very good. Well done, man! Functionality is there. Certainly, you can do some cleanup as you say, but that is secondary. It is great that you have extended this module with such nice magic.

One suggestion I made earlier is putting the lookup at the online phone book (dasoertliche.de) & parsing into its own module. This would allow others to write phonebook lookup modules for their own country. I’m happy to do this change on your code base.

You did all the (sometimes confusing) Git stuff right: you forked from the original repository, checked out your repository, made changes, committed and pushed them back into your repository. There was just one step too much, which is the pull request. You typically make a pull request in the person’s repository that you have forked from to tell the original author ‘hey, here is cool new stuff that you may want to have in the original repository’. I would suggest that you accept or remove your own pull request.

If you want me to extract a module for the phonebook lookup & parsing, I can work on the latest version of your repository and either push directly to your repo (if you grant me write access) or I send my own pull request to you.

@zack949, could you report back after you got it solved? I think this is an interesting use case, which might be relevant for more people.

If you start your mirror with pm2 as suggested in documentation, then you can use commands like pm2 stop mm, pm2 restart mm, pm2 start mm to control your mirror.

I would make three different start scripts, e.g. mm1.sh, mm2.sh, and mm3.sh, where each one starts one specific instance. This is in line with @ninjabreadman’s suggestion to have three install directories.

A good starting point might be the module MMM-dht by @nebulx29. It executes a custom shell command to read data from a sensor. You’ll find the invocation of the script in file node_helper.js. NB: it makes three calls, because it needs three values from the sensor.

In your use case, you’d call Python with your script name instead.

Any updates on this? I have the same problems as @DocVooDoo and others, i.e. Adafruit code works like a charm, dht_var not.

Difference I noticed is that dht_var uses wiringpi library and Adafruit not?! I tried a reinstall of wiringpi package without success.

Next, I compared the implementations of dht_var and the Adafruit driver for DHT22.

The essence of the Adafruit code is in file Adafruit_Python_DHT/source/Raspberry_Pi_2/pi_2_dht_read.c. It is meant for Pi2 and Pi3, implemented in C, and defines a function int pi_2_dht_read(int type, int pin, float* humidity, float* temperature). It implements the communication with the sensor using a 1-wire bus. The rest of the Adafruit package is mostly (well-done) sugar-coating for Python usage and selecting the right driver for any given platform.

We could simply rewrite dht_var by using this driver code. What do you think?

Very nice. Well done!

I’m also thinking about controlling LED stripes, but wanted to do this more low-level like in this Adafruit project. What components are you using for controlling them via USB?

… and thanks to Gene Roddenberry (and others), who invented the Universal Translator. :-)

Yes, you are right about the spirit of this forum. And I fully agree that discussions should be in English, so that everybody can participate and benefit from them. In this thread, however, the user asked explicitly for setup instruction in German. As long as language-specific threads don’t become the norm, I think such request are totally OK, because we should also not exclude people who are not fluent in English.

PS: The EN-DE translation of your post is really good. I’m surprised.

Das ändert man im Stylesheet (*.css). Im Code des Compliments Moduls wird beim Aufbau des DOM drei Klassen thin xlarge bright gesetzt, siehe hier.

Viele Module bringen ihre eigene CSS Datei mit, doch Compliments verwendet das CSS main.css. Die Definition von xlarge ist für die Schriftgröße zuständig, siehe hier.

Du kannst jetzt beispielsweise so vorgehen:

• kopiere main.css nach mystyle.css im Verzeichnis MagicMirror/css
• benutze die Konfiguration customCss um dein mystyle.css anzuwenden, siehe README
• füge in mystyle.css eine eigene Größenklasse mysize ein, orientiere dich zunächst an xlarge
• ändere die Konfiguration von Compliments so, dass dort statt xlarge deine Klasse mysize benutzt wird. Dafür gibt es ein Setting namens classes, siehe README von Compliments.

Alternativ, d.h. ganz ohne eigenes CSS, kannst Du auch nur den letzten Punkt anwenden, wenn Du mit einer der in main.css bereits vorhandenen Größen-Klassen large, medium, small und xsmall zufrieden bist.

When there is an API there is a way! :-)

Have a look at this community approach to describe Max! Cube API.

Awesome idea!

And while we are at it, I think that @Mykle1’s excellent step-by-step guides should also have a home in the wiki. The forum is the right place to work them out, but once the instruction have matured they should become part of the project itself.

If I see it correctly, you are installing Magic Mirror in directory /123/MagicMirror. Usual place is in the home directory of user pi, i.e. /home/pi/MagicMirror or ~/MagicMirror.

In your startup logs you get many errors on loading resources such as CSS files. I’d assume the web server you are starting as user pi when starting MagicMirror is not allowed to access files in an arbitrary root directory, which your directory /123/MagicMirror actually is.

I totally like the idea that my mirror informs me about upcoming shipments. I was wondering if there is a convenient way so that I don’t have to put the tracking numbers into the config.js?

Some ideas:

• Manually add tracking numbers to a file on OneDrive or DropBox. The module reads it from there.
• Forward order confirmation mails containing the tracking number to an email address, which the tracking module polls from and extract the shipping number (do they have a standard encoding, at least per carrier?).
• Utilize voice command to dictate the shipping number.
• Hook up my mailbox for order confirmations to IFTTT or Microsoft Flow to process mal and feed the tracking number into a service which the tracking module consumes, e.g. file on OneDrive or DropBox.

I’d love to get your thoughts on this. Thanks!

Hmm, this is weird. The original MMM-FRITZ-Box-Callmonitor comes with a node_helper.js. Are you sure you did not delete it by accident resp. forgot to copy it to your dev environment? Moreover package.json and the README.md are missing.

Are you familiar with git? I’d advice that you fork the MMM-FRITZ-Box-Callmonitor into your own GitHub account and make all your changes there. This would also allow me to read your latest code after each git commit. From this forked repository there is an easy way to get your improvement back into the original repository once you are done.

One thing which does not look right is the custom in your path. Moreover your path is in the root and not under /home/pi. It should read /home/pi/MagicMirror/modules/MMM-EmbedYoutube or ~/MagicMirror/modules/MMM-EmbedYoutube, which is equivalent for user pi.

From your description I get the impression that you did not use the tool git to checkout the module into your modules directory. Is this possible? If so, please do the following:

• cd ~/MagicMirror/modules
• git clone https://github.com/nitpum/MMM-EmbedYoutube.git
• Leave the config.js as it is, it looks good
• Start your Magic Mirror

I think there is also a zoom factor setting in config.js. Would this help?

See documentation on zoom config setting:

This allows to scale the mirror contents with a given zoom factor. The default value is 1.0

Oh, one idea for your module. The calendar has a dedicated calendar fetcher as mentioned in my previous post. This may be interesting for your reverse lookup as well. Other people may want to use other online phone books, e.g. for different countries, and by configuring the right reverse lookup fetcher they could do so. Maybe have a look at the code of the calendar fetcher and the node helper where it is being called. However, IMHO you should first get your module working as it is. This is a suggestion for a future extension.

Hi @AxLed, great to see your progress!

There are a few remarks on testing that come to mind:

• I personally like to develop the module on my Windows PC using VisualStudio Code and additional tooling from the Internet as I need it. For this you have to install the MagicMirror on your PC. @Mykle1 has a nice walkthrough document for doing so.
• MM has a development mode. Start MM (with your to be tested module) with the command npm start dev. This starts a browser UI for MM and in addition shows you the loaded HTML, CSS, source code, etc. In the browser’s source window you can set breakpoints and once they get hit, the program execution pauses and you have time to inspect variables. Please note that you don’t have to stop and start MM all the time with the command above. Just change source code in your programming editor, save it, and reload the MM browser (F5). This works both on Raspberry Pi and Windows PC.
• If you want to test part of your code in isolation, then you can simply write a small helper program debug.js which calls your test subject’s methods the way you need it. You find this approach in the debug.js of calendar module to test the calendar fetcher component. In this case you do not start MM, but just execute your helper program with node debug.js.
• You can write a real (automated) test suite, but this may go a little beyond your current task. A test suite is helpful when you do test driven development and/or when you want to guarantee that a future change does not break expected behaviour.

Well, if you have created your config.js from the config.js.sample then you should already have a configuration sequence like below.

modules: [
...
{
    module: "clock",
    position: "top_left"
},
{
    module: "calendar",
    header: "US Holidays",
    position: "top_left",
    config: {
        calendars: [ {
	    symbol: "calendar-check-o ",
            url: "webcal://www.calendarlabs.com/templates/ical/US-Holidays.ics"
        } ]
    }
},
...
]

You have to put the fetchInterval setting into the config setting section of the calendar module. The result would look like this (just typing the calendar module’s part for simplicity):

{
    module: "calendar",
    header: "US Holidays",
    position: "top_left",
    config: {
        fetchInterval: 1000 * 60 * 1,
        calendars: [ {
	    symbol: "calendar-check-o ",
            url: "webcal://www.calendarlabs.com/templates/ical/US-Holidays.ics"
        } ]
    }
},

The value 60 * 1000 * 1 retrieves the calendar from the source (see parameter url) every minute. Please note that the interval time value is given in milliseconds according to the documentation. When you pick a value make sure that your fetching is not too aggressiv. Too frequent syncs take bandwidth on your network, increases CPU load on Raspberry Pi, and there might be limitation enforced by the calendar provider.