@swvalenti one problem is that this module uses valid-url without having this dependency in the package.json.

You can look at this FAQ, you have to replace request with valid-url and omit the docker stuff (line docker exec ...).

But I don’t know if this is the only problem …

@KristjanESPERANTO

it would be better to reveal the last update date or the number of unresolved issues

as most modules are hosted on github: You can get such info’s over their api.

As example you can look at https://api.github.com/repos/MichMich/MagicMirror

you could use a proxy https://cors-anywhere.herokuapp.com/https://dd.weather.gc.ca/citypage_weather/xml/ON/s0000326_e.xmll, there is already such a line in the PullRequest merged today.

I’m trying to convert from MMM-OpenWeatherForecast to something else, but Openweather is confusing me with the API subscription.

same situation here. I like the above module but I don’t want to subscribe to the new openweather api.

First alternative was the mm weather module because it has several providers so you can switch easily. But the design is so far away from MMM-OpenWeatherForecast …

So next approach was to use the data from mm weather for an own module with better UI.

Thats the current output:

It is still a beta version and not published yet.

Another approach could be to extend the mm weather module with configurable njk templates and the cool skycons (which can be animated) …

@Jalibu v2 LGTM.

But you have still an error in the README:

You want beer but you’re getting only coffee ;)

@KristjanESPERANTO said in Automatic checking of all MagicMirror² modules:

After you showed me the examples, I tinkered a bit with a simple frontend (without dependencies): check it out. I just have to fill it with real data.

cool, exactly what I thougth of …

looking at your example json

  {
    "name": "MMM-PublicTransportHafas",
    "image": "https://raw.githubusercontent.com/KristjanESPERANTO/MMM-PublicTransportHafas/main/img/Goerdelerring_all.png",
    "maintainer": "KristjanESPERANTO",
    "link": "https://github.com/KristjanESPERANTO/MMM-PublicTransportHafas",
    "category": "Traffic",
    "tags": ["Schedule", "Public Transport", "Traffic", "HAFAS"],
    "text": "This module displays real-time departure times for public transportation.",
    "description": "Stay informed about the upcoming departures from your local public transit stations."
  },

there are only a few things which are not available via github api (image, category).

category and tags are similar, do we still need a category?

tags are similar to api topics (may without magicmirror key words)

@sdetweil said in MMM-Strava stopped updating:

it appears the module doesn’t log much…

debug must be set in the config to get more logs …

@sdetweil said in CALL FOR TESTERS: New install script:

@mumblebaj AND there is no practical need for encoding anything

there was a need for the binary which was removed meanwhile, but not for the text files …

so e.g. this

base64 -d > /tmp/mm-install/xinitrc <<< 'IyEvYmluL3NoCgp4c2V0IHMgb2ZmICAgICAgICAgIyBkb24ndCBhY3RpdmF0ZSBzY3JlZW5zYXZl
cgp4c2V0IC1kcG1zICAgICAgICAgIyBkaXNhYmxlIERQTVMgKEVuZXJneSBTdGFyKSBmZWF0dXJl
cy4KeHNldCBzIG5vYmxhbmsgICAgICMgZG9uJ3QgYmxhbmsgdGhlIHZpZGVvIGRldmljZQoKaWYg
WyAtciAiL2V0Yy9tYWdpY21pcnJvci94cmFuZHJfb3B0cyIgXTsgdGhlbgogICAgICAgZWNobyAi
cnVubmluZyB4cmFuZHIgd2l0aCBhcmd1bWVudHMgXCIkKGNhdCAvZXRjL21hZ2ljbWlycm9yL3hy
YW5kcl9vcHRzKVwiIgogICAgICAgRElTUExBWT06MCB4cmFuZHIgJChjYXQgL2V0Yy9tYWdpY21p
cnJvci94cmFuZHJfb3B0cykKZWxzZQoJZWNobyAibm90IHJ1bm5pbmcgeHJhbmRyIgpmaQoKeHNl
dHJvb3QgLXNvbGlkIGJsYWNrCgppZiBbIC1yICIvZXRjL21hZ2ljbWlycm9yL3hfYmFja2dyb3Vu
ZF9pbWFnZSIgXSAmJiBbIC1yICIkKGNhdCAvZXRjL21hZ2ljbWlycm9yL3hfYmFja2dyb3VuZF9p
bWFnZSkiIF07IHRoZW4KCXhsaSAtb25yb290ICQoY2F0IC9ldGMvbWFnaWNtaXJyb3IveF9iYWNr
Z3JvdW5kX2ltYWdlKQpmaQoKd2hpbGUgOjsgZG8gc2xlZXAgMTAwMDA7IGRvbmUKCg=='

could be replaced by

cat > /tmp/mm-install/xinitrc <<"EOF"
#!/bin/sh

xset s off         # don't activate screensaver
xset -dpms         # disable DPMS (Energy Star) features.
xset s noblank     # don't blank the video device

if [ -r "/etc/magicmirror/xrandr_opts" ]; then
       echo "running xrandr with arguments \"$(cat /etc/magicmirror/xrandr_opts)\""
       DISPLAY=:0 xrandr $(cat /etc/magicmirror/xrandr_opts)
else
        echo "not running xrandr"
fi

xsetroot -solid black

if [ -r "/etc/magicmirror/x_background_image" ] && [ -r "$(cat /etc/magicmirror/x_background_image)" ]; then
        xli -onroot $(cat /etc/magicmirror/x_background_image)
fi

while :; do sleep 10000; done

EOF

@jalibu

Unfortunately, I can’t tell you that. I am only responsible for the display layer, not for the weather data 🙂

I’m aware of this …

Is it the usual case on your mirror that the displayed radar images do not match the reality?

saw such differences this week the first time

What I can see is that RegenRadar.de and RainViewer have different scales. With RainViewer it needs a much higher degree of cloudiness to be displayed on the map.

will oberve this but the differences are heavy and AFAIS not only explainable with the different scales. Meanwhile I was already asking myself if the rain layer is showing a total different location …

@KristjanESPERANTO

from your todo list

Is there also a GitLab API?

yes, as example you can look at MMM-RepoStats

Another thing is what the source of the list should be, still the wiki (which is very error prone since anyone can edit things).

Alternatively, you could store a list in your repo and we need something for users to add to their repo (e.g. as a PR in the repo or with website functionality).

But maybe there are even better ideas.

@steak

https://forum.magicmirror.builders/topic/15778/fix-for-black-screen-in-2-16-and-later

@drdeath

I just presented a way to get by without the base64 that others have criticized.

To address me here now as if I was the critic is far-fetched.

If you call for testing here, you also have to be able to deal with criticism - regardless of whether it is justified or not.

@sdetweil

the default weather module still uses 2.5 and it works

at the moment, yes.

I looked into their api stuff and onecall v2.5 is not mentioned anymore. The normal endpoints weather and forecast are still on v2.5.

Problem: For onecall 3.0 you need a special api key (as already mentioned here) with a subsciption where you have to give your payment data (1000 request free per day, limit is 2000 per day but you can set your limit to 1000 if you want it for free … ).

I think we will get problems/questions to this for the default weather module too.

So (for default weather module) if you use endpoints weather and forecast and old onecall v2.5 everthing works out of the box with old api keys, if someone use new onecall v3.0 he needs an api key for 3.0 and has to set apiVersion: "3.0", in the config …

@KristjanESPERANTO said in Best practice 'package-lock.json' for modules:

Can you show me where?

we don’t use npm ci but I’m not sure what npm install does if package-lock.json is present.

I do the tests after building my docker images on my own and I always delete package-lock.json before running npm install to be sure getting the newest deps.

@wimthoelke

the module is untouched since 4 years which means dead.

You can try this fork https://github.com/KristjanESPERANTO/MMM-PublicTransportHafas

The “&nbsp” part is missing in the fork so may this is fixed there.

@kristjanesperanto

Life is too short to be mad at assholes…

@sdetweil

http://pirateweather.net

@KristjanESPERANTO said in Automatic checking of all MagicMirror² modules:

@Jalibu wrote:

are there plans to make this the official linked modules store on the project‘s page?

I’m definitely open to the idea of turning it into an official part of the project and moving it to MagicMirrorOrg, for example.

However, I have not yet sought dialogue with the core developers in this regard. It it would be very interesting to hear if the core developers are open to that idea. @karsten13 , @rejas and @sdetweil, what do you think?

I‘d also vote for making this the source of truth without dependency to the old page as a datasource

The current solution (the list in the wiki) works and does not cause any additional work for the core developers.

However, as soon as we automate the process of creating the new module webpage, a vandal could provoke ugly effects. That’s why a different approach to maintaining the list, one that provides more protection against (intentional and unintentional) vandalism and includes a simple quality check, would make sense.

My concrete suggestion would be to create a pull request template for this purpose.

---

If we decide that “my” list should become an official part of the MM project, I would spontaneously suggest these rough milestones in the following order:

1. moving the repository to MagicMirrorOrg.
2. finding a better way to maintain the source of truth (currently the wiki page).
3. replacing/redirect references to the old module list.
4. automating the creation of the module list website.

I’m fine with this. The Wiki stuff should not stay the source of truth, this construction is horrible. Maybe we have to wait until we have full control over MagicMirrorOrg …

@timogden

you could use envsubst < config/config.js.template > config/config.js.

The config.js.template is the config for both which contains variables for the different values. So you could write a script which sets the variables for user1 and then run envsubst for config1 and the same for user2/config2 afterwards.

@sdetweil

thanks for the hint, had to check mmos …