Offline
Before I could send this another day passed and now they are correct! Docker is still on UTC but the Clock and Agenda are correctly showing times on BST!
Thanks for the feedback. This is expected behavior. If you really need the timezone for other stuff in the container you can set it by adding this in the compose.yaml:
environment:
- TZ=Europe/Berlin
The external url for getting the TZ doesn’t work anymore, I had to switch to another one. Meanwhile this did not work but I pushed new images some minutes ago which should fix this. So please pull the new image and let me know if it works.
Thanks to: @cgillinger, @khassel, @KristjanESPERANTO, @sonnyb9
⚠️ This release needs nodejs version >=22.21.1 <23 || >=24 (no change to previous release)
Compare to previous Release v2.35.0
This release falls outside the quarterly schedule. We opted for an early release due to:
The cors proxy is now disabled by default. If required, it must be explicitly enabled in the config.js file. See the documentation.
You can find several publicly accessible MagicMirror² instances.
This should never be done. Doing so makes your entire configuration, including secrets and API keys, publicly visible. Furthermore, it allows attackers to target the host; this is only prevented beginning with this release.
Public MagicMirror² instances should always run behind a reverse proxy with authentication.
Is this something that could be build into the default module?
we introduced Themes for this use case with the lastest mm release
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.
Thanks to: @angeldeejay, @in-voker, @JHWelch, @khassel, @KristjanESPERANTO, @rejas, @sdetweil
⚠️ This release needs nodejs version >=22.21.1 <23 || >=24 (no change to previous release)
Compare to previous Release v2.34.0
⚠️ We introduced some internal changes with this release, please read this forum post before upgrading!
require() calls (#4056)see https://github.com/MagicMirrorOrg/MagicMirror/releases/tag/v2.35.0
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.
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
custom*.css file from css to configconfig.customCss: "config/custom3.css"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 …
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.
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).
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",
},
},
],
};
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>.
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…
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
one thing (if not already done) would be a reboot and then again the prune command.
Otherwise start from scratch …
really strange, the 1b1... is still there …
try docker system prune -f and check after this again docker ps -a
show docker ps -a.
From the logs it looks like the strange container was deleted but I see no labwc container.