@sdetweil said

I am not a system setup guy.

Dear Sam,
you may aware of this - than please ignore it…

You’ve described that you have put a SD card in your NVME-HAT’ed Pi and your Pi has not booted from SD but from NVME…

You can steer this with the BOOT_ORDER entry in eeprom configuration.
This code is read right to left to determine the boot order and should (in your case) be: 0xf461:

1 = Check SD card
6 = Check PCIe NVME
4 = Check USB drive
f = Start again

You can check this:

sudo rpi-eeprom-config

If boot order is not as desired you can edit this with

sudo -E rpi-eeprom-config --edit

enter or modify to:
BOOT_ORDER=0xf461

(In my configuration this opens the nano editor in which ctrl-O writes the changes to disk and ctrl-X leaves the editor.
eeprom-config then modifies the system and a reboot is neccessary)

With this configuration you will lose a tiny bit of time for the SD-card check but it enables you to insert a SD card and boot from there despite the NVME is connected as well.

Regards,
Ralf

@sdetweil said in

but npm start works!?
Not tried.
Leave it currently, as is.
Via your install script provided autostart calls npm run start:x11 - which works fine.

Regards,
Ralf

@sdetweil said

appendLocationNameToHeader: false,

Yeah.
OK, already found this…

Regards,
Ralf

@sdetweil said in My new MagicMirror will not start with Wayland?:

@rkorell great work!

Ohhh - this from you!
Makes me proud.
Thanks!

Ralf

@sdetweil said

by setting the config property to false (default true)

Dear Sam,
Thanks for this.
Which one of the config properties are you referencing to?
I‘ve set

header: „“

This definitely doesn‘t work because it‘s overwritten somewhere
.
Regards,
Ralf

@karsten13 ,
yupp this seems to do the trick.
undoing code changes and adding

appendLocationNameToHeader: false,

to weather config let the header disappear …
Thanks!

Ralf

(not understood why and how but at least this way the header lines are really not present - the blackness idea makes them invisible but they still occupy room.)

@rkorell OK, just seen at least one other mistake:
I’ve picked “appendLocationToHeader” but this should be “appendLocationNameToHeader” …

@karsten13 said in Standard Weather Module showing unwanted header:

there is no property with above name

the part of module code I’ve meant is obvioulsy doing something wrong:
getHeader is “explained” as “// Override getHeader method.”

	getHeader () {
		if (this.config.appendLocationNameToHeader && this.weatherProvider) {
			if (this.data.header) return `${this.data.header} ${this.weatherProvider.fetchedLocation()}`;
			else return this.weatherProvider.fetchedLocation();
		}

		return this.data.header ? this.data.header : "";
	},

I’ve simply replaced this with

getHeader () {
		return "";
	},

And - no surprise - header disappears.

Regards,
Ralf

@karsten13 nope :-(
Deleting “appendLocationToHeader” doesn’t resolve the issue…
One of the headers (in this case weather_forecast instance) immediatly shows up if I disable the blackness of text/border-bottom …

Regards,
Ralf

@karsten13 OK, have found this as part of an if clause and as member of defaut configuration in module code.
If this causes the unwanted behaviour: sorry!

Thanks.
Ralf

Hi Team,
may there a specialist for the standard weather module who can lead me in right direction…
It was disappeared for a while but re-introduces for unknown reasons:
The weather module displays a “standard” header (Location name) despite my personal config.js setting (see below).
I do have two instances of the module - as many others I guess - one current (classes: weather_current), one forecast (classes: weather_forecast).
The error is neither consistent nor reproducable:
Sometimes one of the instances shows a header, sometimes both, sometimes none of them.
The view is inconsistent, too for (HDMI attached) monitor and browser view!

And while playing around with custom CSS for this module I’ve identified that setting

.weather_current .module-header 
 {
border-bottom-width: 3;
}

in custom.css makes the module disappearing completely.

The weather module configuration in config.js is as follows:

// Wetter aktuell für Müllenborn		

		{
			module: "weather",
			disabled: false,
			position: "top_right", 
            header: "",
            classes: "weather_current", 
			config: {
				weatherProvider: "openmeteo",
				type: "current",
				lat: 50.24127,
				lon: 6.61174403,
				onlyTemp: true, // zeigt nur die temp und icon, kein wind kein gar nix :-) 
				showSun: false,
				appendLocationToHeader: false,
				showFeelsLike: false,
			}
		},


// Wettervorhersage - 

		{
			module: "weather",
			position: "top_right",
			disabled: false,
			header: "",
			classes: "weather_forecast",
			config: {
				weatherProvider: "openmeteo",
				type: "forecast",
				lat: 50.24127,
				lon: 6.6174403,
				appendLocationToHeader: false,				

			}
		}, 

currently I have “solved” this with two entries in custom.css:

.weather_current .module-header 
 {
color: black;
border-bottom-width: 0;
border-bottom-color: black;
}

.weather_forecast .module-header 
 {
color: black;
border-bottom-width: 0;
border-bottom-color: black;
}

But this is kind of unsatisfactory …

I guess there is a bug in the module - what do you think?

Thanks and regards,
Ralf

@sdetweil As I wrote initially “npm run start:wayland” doesn’t work …
(despite wayland configured).
And the “stored” auto-start option npm run start:x11 DOES work - for whatever reason.

VNC was really sluggish on this, performance a nightmare so - see above marked as “solution” I switched back to x11 and all is working fine.

In the meantime I’ve also managed to get MMM-Pir to work by idenitfying and correcting two errors in Bugsounet’s code …

Warm regards,
Ralf

@sdetweil Dear Sam,
thanks for this long explanation.
Understood.

But you did it again :-) (no worries - it’s my own inability…).

You’ve introduced - magic again :-) - a .today identifier …
This definitely makes sens but is not “visible” from a dummie perspective …
Just to illustrate what I mean.
If one KNOWS what happens (remember our long discussion in another thread where I was not able to pick the right “div” tag in the console) all is quite easy.
If not - it’s really hard . That’s all what I try to show…
And yes - the right way is and should be to get a full understanding how CSS works - which is not true in my personal case…
So I’m seeking around with “trial and error” - which fails often…

Thanks for your engagement and effort!

Ralf

@sdetweil

then you aren’t using it correctly…

yes :-)
For sure.
But in your given (referenced) example (Thanks for this - highly appreciated!) is happening exacty this “magic” which I cannot get through …

Example:

your “magic” reduces

.CX3 div .cell.today.thisMonth.thisYear.year_2025.month_3.date_25.weekday_2 div.cellHeader div.cellDate {
 height: 1em;
text-align: left;
}

to much simpler

.CX3 div .cell.today div.cellDate {
 height: 1em;
}

The reason behind is pretty clear but from my (naive and may incorrect) “understanding” MY approach would be

.CX3 div .cell.today div.cellHeader div.cellDate {
 height: 1em;
}

And I’m sure this is wrong and won’t work.
But why “div.cellHeader” is NOT neccesary regardless it’s presence in the copied locator - is kind of “contra-intuitive” and hard to understand …

And I guess this exactly are these issues why I’m struggling…

Warm regards,
Ralf

@sdetweil yes, for sure.
I’ve experimented a lot - even with trials to identify CSS-locator with debug-console (which fails)…
Finally this simple statement in module-documentes CSS-locator works fine…
:-)
Lucky punch …

Ralf

@BKeyport , @Kelemvor
Thanks!

max-width: 350px;

worked for me.

• I had a similar “problem” with module MMM-UselessFacts

word-wrap doesn’t do the trick …

Regards,
Ralf

@sdetweil said in My new MagicMirror will not start with Wayland?:

rm -rf ~/.config/Electron

quick question: will this command help, anyway to get “performance” fixed?
Background: Since running on Pi5 / bookworm the mirror has “problems” on reboot.
Module load is extremely slow (minutes!).
A “pm2 reload MagicMirror” after reboot leads to way faster module loadings.

Thanks,
Ralf

@sdetweil said in My new MagicMirror will not start with Wayland?:

note that npm start issues npm run start:x11

? can you kindly please eloborate?
Didn’t get you, sorry!

@rkorell said in MMM-Universal-Pir - Desparately seeking right command:

“DISPLAY=:0.0 xrandr --output HDMI-1 --off” / “DISPLAY=:0.0 xrandr --output HDMI-1 --primary --mode 2560x1440 --rate 59.951 --pos 0x0 --rotate left”

these are the right commands and are working now!

(If one was not too blonde to switch the commands …)
My fault - I’ve entered the on comand to the off parameter …
Sorry!

Regards,
Ralf

@sdetweil Thanks!

overall it doesn’t work for me :-(
system is so slow that even editing config.js took 8 seconds to load the tiny file from pi to Laptop…
So I’ve re-configured to X11 …
NO idea what happened but unusable with wayland.
In addition the target of whole szenario - to get MMM-Pir working without error message is not reached because with wayland, too an error is produced …
So I will stay with X11 and try MMM-Pir-universal …
(which is kinda unreliable…)

Warm regards,
Ralf