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

@KristjanESPERANTO

I’m using https://globe.airplanes.live/ and they have a RainViewer Layer which still works when zooming in - maybe they use a license key …

Another approach I played with is using german dwd data (problem: germany only), tested this in my MMM-Flights module:

@smegbadger said in MMM-Universal-PIR - ‘GPIOcommand exited with error!':

It never occurred to me the container would update things unannounced!

the container does not update things on your host, but the container itself is running debian and (if you are using karsten13/magicmirror:latest) the debian version of the container image switched from bookworm to trixie …

see https://github.com/rainviewer/rainviewer-api-example?tab=readme-ov-file#personal-use-api-limitations

@KristjanESPERANTO

colorScheme seems to be useless too, the docs only mention 2 which is the default in the module, if I try other values there is no difference.

said in MMM-RAIN-MAP:

but since today, the two lowest of my four zoom levels seem to have stopped working

they are definitely gone …

I used for several years

        mapPositions: [
          { lat: ${LAT}, lng: ${LON}, zoom: 9, loops: 1 },
          { lat: ${LAT}, lng: ${LON}, zoom: 8, loops: 1 },
          { lat: ${LAT}, lng: ${LON}, zoom: 7, loops: 1 },
          { lat: ${LAT}, lng: ${LON}, zoom: 6, loops: 1 },
        ],

and now found in their docs Maximum zoom level is 7.

Another restriction is that there is no forecast anymore (as already stated in the module readme).

That’s a shame, it unfortunately devalues ​​the module.

@smegbadger

I had no idea about that, but now that you’re using Docker:

The gpiomon command is called inside the container (doesn’t work) and you call it for testing on the host (does work).

So I assume you have the newer version of gpiomon running in the container. So update the command in config.js to the new syntax described in the module README and try again (the new command will fail on the host but should work from inside the container).

@Stulli

you can set the mapUrl in the config:

var config = {
  modules: [
    {
      module: "MMM-Flights",
      position: "top_left",
      config: {
        laMin: 50.0,
        laMax: 50.21,
        loMin: 8.4,
        loMax: 8.8,
        mapUrl: "https://{a-d}.basemaps.cartocdn.com/light_all/{z}/{x}/{y}.png",
      },
    },
  ],
};

@Stulli

from the README:

As default map openstreetmap is used, other maps are possible, you find a list here.

You also can use maps from mapbox and create own maps with mapbox studio.

With mapbox you have to provide

• <username> (e.g. karsten13)
• <mapid> (e.g. cjp8vd7p807su2rqp8hc4dzoq)
• <accesstoken>

and set the mapUrl in config.js to https://api.mapbox.com/styles/v1/<username>/<mapid>/tiles/{z}/{x}/{y}?access_token=<accesstoken>.

@KristjanESPERANTO

The module is working for me, but since today, the two lowest of my four zoom levels seem to have stopped working (no change after updating).

I don’t see any 429 errors in the logs.

But let’s just wait and see; it might work again tomorrow…

@Klinge

from the module README.md:

Please test the used commands first outside of MagicMirror². If they not work from a terminal it makes no sense to use them inside this module.

So what is the output if you run gpiomon -r -b gpiochip0 17 on your machine?

And provide the version with gpiomon -v

@Mathes75

one thing (if not already done) would be a reboot and then again the prune command.

Otherwise start from scratch …

@Mathes75

really strange, the 1b1... is still there …

try docker system prune -f and check after this again docker ps -a

@Mathes75

show docker ps -a.

From the logs it looks like the strange container was deleted but I see no labwc container.

@Mathes75

looks like there is an old container but no idea why docker is unable to remove it.

You can try

cd /opt/mm/run
docker compose down
docker rm -f $(docker ps -aq)
docker compose up -d

@Mathes75

which script?

show content of “the script” and output of docker compose config

@sdetweil said in Having difficulty starting my mirror. I really need some help:

But it’s provided and is a ‘quick’ ‘win’ to get base up and running.

I’ve had another setup running for a while now, which solves some of the problems but of course also has its drawbacks.

It runs on Fedora with PM2. Why Fedora? Because I use bootc and therefore get automatic operating system updates. The downside is, of course, modules related to the Pi’s hardware, but the PIR sensor works.

@mcirim

I think you installed MagicMirrorOS, this is not a simple setup because it uses container images to start the mirror.

If so, log in and execute the following commands line by line and post the output here.

uname -a

df

# following line only moves to another dir without any output:
cd /opt/mm/run

docker compose config

docker logs labwc

docker logs mm

@Mathes75

looks like you still have an old labwc image, try from /opt/mm/run folder:

docker compose pull
docker compose up -d

@Mathes75

Let me know if you get another black screen without mm start after reboot (I want to know if it is fixed or not …)

Can you please show me again the output of docker compose config (so I can check if you have the latest changes)?