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

@sdetweil

only wanted to post this variant …

As background: This is a feature of my docker container where you can use a config.js.template and the variables are defined in the docker-compose.yml which starts the container and before starting mm I run envsubst to make the real config.js.

@tonyarogers said in MagicMirror problem:

Network service crashed

I had similar problems with a setup on a pi zero 2w.

The pi 3A+ seems to have the same memory of only 512 MB.

Short story: The os and the dependencies of mm (node and electron) seems to need more memory with every new version. I gave up with such hardware.

It is not impossible to get it running with increasing swap size or using 32-bit os but it is a dead end …

@sdetweil

http://pirateweather.net

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

@wmx

should be

icons: [{
  "default": "http://localhost:8080/cors?url=http://<my-ha-url>:8123/local/images/hem.png"
}]

@parnic

bullseye support ends in 5 month. But I don’t think we will remove the x11 start option because there are many other os which have no wayland support.

This is an electron option, wayland needs an extra param -ozone-platform=wayland. This is all defined in the package.json.

So as long as electron supports x11 I see no reason to remove the x11 option from mm.

With the new release we only switched to wayland as default option (when you use node --run start) because we think the majority is meanwhile using wayland.

@htilburgs said in MMM-MyTasklist:

Is there a tule for the Ports? Which I can use or not use?

you could add a config param for the port so that everyone who collides with 8123 could choose another one without hacking the source code

@KristjanESPERANTO

Thanks! Maybe I take a look into the authenticating stuff …

@sdetweil

the docker image karsten13/magicmirror:latest doesn’t contain python. Simplest solution for this is to use the fat image karsten13/magicmirror:fat, for more infos: https://khassel.gitlab.io/magicmirror/images/

after some more research I think we are blocked by digitalocean: “SMTP ports 25, 465, and 587 are blocked on Droplets to prevent spam and other abuses on our platform.”

I found another working port so the mail issue should be solved now (until blocked again on the new port …). I was able to send a test mail after the change which failed before.

you can put this into css/custom.css file:

.newsfeed-desc {
  display: none;
}

see https://github.com/MagicMirrorOrg/MagicMirror-3rd-Party-Modules/pull/65

@sdetweil said:

the custom*.css files get moved

no, only css/custom.css and only if the target specified in config.customCss doesn’t exist.

This is the normal setup used by ~95% of the users, we cannot handle every edge case so these users must change it manually.

@BKeyport said:

I’m currently setting the CSS file with customCss: “css/custom3.css”, in the config,

I’ll change that to customCss: “config/custom3.css”, ?

in your setup no file is moved automatically. As you are already using the config.customCss feature you can do the changes before next release by

• move all the custom*.css file from css to config
• change config.customCss: "config/custom3.css"

@sdetweil

yes, the docs … no native english speaker so docs are always a struggle. Thanks for the hints, will update …

@majorc said in Cursor shown in v2.16.0:

Or do I have to wait for version 17?

In v2.16.0 we have electron v11, in current develop branch (which will become v2.17.0 in October) we have upgraded to electron v13.

@HeikoGr

Thanks! Your configuration inspired me to write down and update my own.

I don’t mean to hijack your thread, but since development environments are always a matter of personal preference, I thought I’d share this as an alternative.

@kayakbabe

it is a good idea to put the compliments.json beside the config.js.

In the config.js you have to use

remoteFile: "../../../config/compliments.json"`

which raspberry pi os did you install?

It must be one with desktop