@BKeyport - there are some reviews out there stating, that raspi 5 power supply isn’t capable to power this config sufficiently and that the temperature is about 70°C and fan is loud …
As you‘re recommending this I assume that his isn‘t the case in your installation (mentioned reviews are for the NVME housings…).
Is this assumption correct?

Thanks,
Ralf

@BKeyport OK, thanks!

• Have seen this somewhere sometimes …
  I had to have the one with NVME - pretty expensive (for a pi-housing) and pretty big - I‘ve not that much space behind the mirror but will consider this as an alternative.
  Keep you posted…
  Regards,
  Ralf

Good morning, Gurus!

How do you, guys cool your Raspi5?

I‘ve installed the „original raspi 5 fan“ which worked for a while (3-4 weeks) silently without any problem.
Yesterday in the afternoon fan becomes hearable - for whatever reason.

In the meantime I‘ve identified how to adapt the speed of the fan (there are some dtoverlay parameters steering this) but it doesn’t help that much because if I toggle down speed to get the fan non disturbing the temperature is increasing fast to get nearly immediatly to ranges where I have to set speeds to cool „really“ to avoid damages in the system (+65 °C)…

Do you have a tip for „working“ hardware or have an idea how to „repair“ the existing fan?

• It isn‘t a funny or even cheap hobby to buy a new fan every few weeks … :-)

Thanks for any hint!
Warm regards,
Ralf

@FrostByte said in Bugsounet and MMM-Pir:

As already written by @sdetweil , the node_modules directory is created when npm run setup (or npm install as it should be called).

This one I’ve missed or was to blonde, to see …

If the install is creating necessary files all “should” be fine.
Despite the fact that in the original screenLib.js is an error (for x11 - regarding handling because the calls are slightly different as coded).
Wayland does not work properly with MagicMirror on my Pi5 - so I’ve switched back to x11, found the above error and corrected this.
Not sure how to handle this in “release” and your maintenance of module.

What have I done?

See here:
This is line 311 (of screenLib.js ):

       exec("DISPLAY=:0 xrandr | grep 'connected primary'", //--rkorell
        // original : exec("xrandr | grep 'connected primary'",
 

this is line 489 (of screenLib.js ):

        // original exec(`xrandr --output ${this.screen.hdmiPort} --auto --rotate ${this.screen.xrandrRotation}`, (err) => {
          exec(`xrandr --output ${this.screen.hdmiPort} --primary --mode 2560x1440 --rate 59.951 --pos 0x0  --rotate ${this.screen.xrandrRotation}`, (err) => {

especially the second one was disturbing because the statement simply doesn’t work - this option “auto” is something one can find everywhere referenced but it never worked as far as I have tried to research. from own experience (see above) it don’t work. I guess “–auto” should recover the current settings -but it doesn’t (on bookworm!) . Hard coded screen resolution is definitely no candidate for broader distribution …

(First one “only” produces an error message)

These are my findings.
I’ve mistakenly (not aware of the “dynamically created” libraries/dependant modules) linked the problems of the thread owner with the missing libraries in HIS installation to the likewise missing modules in git clone…

Sorry for confusion!

Ralf

@FrostByte .
Yes there are still “problems”.
@coernel has prepared a re-upload of bugsounet’s MMM-Pir.
But for some reasons this has failed.

Several entities are missing in his upload (including e.g. the core MMM-Pi.js and several other linked and necessary sub-programs (Described in more detail in this post).

I’ve copied a tar.gz file of my own local repository-copy here.

This copy is installable with npm install in the respective MMM-Pir directory in mirror Version 2.30 (NOT tested in brand new 2.31!).
It works without problems on a Pi4 with bullseye.
It does NOT work on a Raspi5/bookworm “out of the box”.
In the meantime I’ve identified and corrected the root cause for this (wrong parameter for the xrandr-call).
This correction is NOT reflected in the URL above because I’ve done this correction after the upload.
I can share this with you if you are interested in - only a very minor adoption and only for MY use-case (working without wayland and with x11).

From my side it would be really highly appreciated if somebody can take the responsibility for maintenance of this pretty module because I really like it very much.
I definitely NOT able to do this but I’m definitely willing to give any additional support in the course of my (tiny) abilities…

Let me know what you’re thinking about.

Warm regards,
Ralf

@sdetweil Yupp. Have read.
For me it’s for later - just potential - use.
Currently I’m fine without daily restart.

Thanks for your explanation!
Ralf

@sdetweil said in Restart MagicMirror once a day:

@rkorell you can do it from the commandline, OR the config file

the config file I create is in the installers folder
pm2_MagicMirror.json

it looks like you can do

pm2 restart xx --cron-restart

AFTER the app was defined already

Do you mean I can issue the above command and pm2 will store/keep this as configuration?

This would be pretty cool…
Wasn’t there a “pm2 save” or something like this???

Ralf

@sdetweil said in Restart MagicMirror once a day:

pm2 can schedule restart

Dear Sam,
which file is called to start the mirror when I have used your install script?
(I guess I have to insert the cron-related additions there…)

Thanks,
Ralf

@sdetweil you’re absolutely true!

• just kidding !

Ralf

@sdetweil This is a single error :-)
try to count mine - you will win ! :-)

@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