@bhepler Thanks! Switching away from the fake driver seems to fix it.

Two commits I’ve worked on for the testing.

1. Check keys in the translation files. Produces errors currently, so I’ve added .skip.
   https://github.com/qistoph/MagicMirror/commit/123392c54934e49a397d586c1fb8dbcc4cc5d12b

2. To prevent loading app.js from corrupting the Mocha test environment, I suggest to execute the app.js in a virtual environment. This can also serve as an example for future test cases where code needs to be executed in the global namespace.
   https://github.com/qistoph/MagicMirror/commit/cd8bee1371ffc6cce7b7bf44f85cd03705e4c1bd

Any thoughts before I submit a PR?

Does anyone know what happend to @bugsounet and his MMM-Pir module?

He seems to have been banned from this forum and his module is no longer available on Github.

Would’ve been nice if there were (at least a couple) basic libs with long time support. Security fixes, maybe some added functionality now and then, but no breaking changes…

The actual risk of almost all vulnerabilities is quite low indeed because of the way our systems are setup. It’s just the earie feeling of seeing all these critical issues while installing my modules that doesn’t feel right.

Hi everyone,

As a developer/maintainer of a couple of MM modules I’m really wondering how everyone is keeping their modules’ dependencies up to date.

An easy thing to do would be to run npm audit fix on my repos and/or merge all PRs from dependabot, but I’m too worried about breaking changes in dependencies. I wouldn’t know how to find the time to extensively test and fix all functionality in the modules. Especially if it would break functionality that someone else is using, that I’m not myself.

How do other developer handle this?

Chris

Hi @3squaremirror,

At the time it’s not configurable.

If you’re able to work out a fix and create a pull request, I’d be happy to include it in my version.

If you’re using my fork, there’s a detailed description of the some what complex setup. Did you follow those steps?

https://github.com/qistoph/MMM-MyCommute#installation

@bhepler Thanks! Switching away from the fake driver seems to fix it.

Hi all,

Finally got to building my own MagicMirror and am quite pleased with the result. I am however running into an issue I can’t get fixed on my own. I’m hoping someone out here might have a good suggestion that will fix the issue.

When my mirror’s been on for a couple of minutes the screen starts flashing and shows green lines about every other line on the display.

I have been searching for solutions and tried some stuff to fix it, including:

• replacing the power supply to rule out low voltage issues,
• replace the hdmi cable, to rule out issues with that,
• configure hdmi_boost=6 in config.txt, seems to have helped people with similar issues,
• simplyfy MagicMirror config, to rule out issue is due to my modules

The weird this is, if I disable MagicMirror (pm2 stop mm) before it starts flashing, it won’t flash even after an hour. If it has started flashing nothing seems to help, except turning off and on power or a full reboot of the pi.

I’m using a Raspberry pi 3B+

Edit: here’s a short video of what I see:
https://youtu.be/_qaLOZ1Pj7E

@roramirez
Except for one of the errors I think all can still be explained by my last post.

@roramirez sorry, haven’t had much time to spend on MagicMirror lately.

My guess is that some of the tests take too long. Especially the ones actually starting MM and not just load a module.

I imagine Travis runs the tests in some sort of container with multiple containers running on the same system. If there is some heavy load at the same time as the MM test is run this might slow down our test with a certain factor. Seeing the difference in the usual runtime between tests (couple of ms vs multiple seconds) makes me think some of our tests are on the heavier end. Having a multiple second test delayed by a factor, say, 2 makes it easily run 5 seconds. Hitting the 5 sec maximum (see log).

Two possibilities I see to fix this:

1. Reduce the runtime of long running tests
2. Increase the allowed runtime before timeout

Hopefully this helps.

Best regards and thanks for keeping this thread alive!

@roramirez my tests ran on Ubuntu.

The failed build you’re linking has timeouts. That’s the issue I added to the Trello board. We could increase the timeout a bit and see if it happens again in the next days.

Ask Mich to re-run the failed build, he should be able to click that option in Travis, being the owner of the project. See if that fails again. That resolved it for me before.