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) …

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

@wuermchen

address, not adress

see https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/

@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

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

@bdream said in automatic update module by notification:

I would prefer having an automatic to update in case it’s notified.

option1: Adding a new paramter “forceUpdate” to the notification module so that it does the update instead of the notification (someone has to code this)

option2: Write a bash script which iterates over the module folders doing something like this (in every module folder)

git reset --hard
git pull
[ -f "package.json" ] && npm install

This script should be executed e.g. daily by e.g. a cronjob.

As Sam already mentioned this would be the hard way, may its better not to change a running system and ignore the notification, your decision.

@oberfragger yes, in the mm folder

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

@KristjanESPERANTO

AFAIS the wrong license is coming from the gitHubData.json file.

So looking into https://github.com/MagicMirrorOrg/MagicMirror-3rd-Party-Modules/blob/main/scripts/updateGitHubApiData.js I stumbled over the line
let maxQueryCount = 58; which is used in the shouldFetch function.

Maybe I’m wrong but this looks like we only fetch 58 repos from github and then switch to historical data?