@KristjanESPERANTO - FWIW, openweathermap are not being very helpful in this transition.

I see in my notes the API key I am using is from 2023, but I have no record of what version it is, so I went on their site to see… They don’t specify, either.

I sent them an email requesting how to determine whether the key I have is already compliant, or i I need to start working on applications. The response email just repeated the warnings around them deprecating the old and people’s need to replace ver 2.5 keys with ver 3.0 keys.

I did send a follow-up email asking for a response to my specific question o how to know whether a particular key will work into the future, but received no response.

As such, I am beginning to experiment with my development instance to see what I need to do…

@KristjanESPERANTO - am I misreading or does MMM-OpenWeatherMapForecast appear on both the first and last list? THANKS for the thorough review!

@jbat66 - yes, it is frustrating to know or hear that severe weather is nearby, but the module seems incapable of being configured to display alerts as needed.

@Gjones93 - as the author, can you provide any input?

@kayakbabe - thanks for letting me know. I will keep an eye on the one I am using and if I see issues, will try the other one.

@sdetweil - Ah crap, having both disabled: true AND disabled: false would do it!! :) I’m sure the system would execute the last command. Thanks for putting a second set of eyes on it.

@sdetweil - Thanks Sam - I guess I was and am confused.

Below are two code snips showing the subject module and one other. Both are designated to be disabled with the “disabled: true” instruction outside the config section. The top one still operates, while the bottom one [and every other module I have edited this way] is disabled. So, it’s not a big deal and I will keep an eye out for how I do things. Thanks again.

{module: "MMM-OpenWeatherMapForecast", // https://github.com/MarcLandis/MMM-OpenWeatherMapForecast NOTE: See also https://github.com/sdetweil/MMM-OpenWeatherMapForecast
  disabled: true,
  header: "", // "Weather"
  position: "top_right",
  classes: "default everyone",
  disabled: false,
  config: {
    apikey: "xxxxxxxxxxxxx",
------------------------------------------------------------------------------- 
{module: "MMM-Temperature", // https://github.com/Tom-Hirschberger/MMM-Temperature
  disabled: true,
  header: "Office Temp + Humidity",
  position: "top_right", // bottom_right
  config: {
   sensors: [

@kayakbabe FWIW, i installed the jclarke0000 module, and so far it looks pretty good - thanks again!

@kayakbabe PS: another issue with MMM-OpenWeatherMapForecast is that it doesn’t respect the “disabled: true” configuration. I had seen this before and ignored it since the module is active, but when I went in to disable it in preparation for trying one of the others, I am reminded that I cannot just disable it. I CAN put " /* and */ " around the whole thing of course, but that is just clunky, and more importantly may signal more serious coding issues.

@kayakbabe - Thanks for the tip. Can you tell me which one you use? A quick web search shows several modules with the same name. These two look like top contenders:

https://github.com/jclarke0000/MMM-OpenWeatherForecast
https://github.com/themaxgoldman/MMM-OpenWeatherForecast

My instance of this module also displays rainfall in “mm”, even though I have set units = “imperial” for the MagicMirror system as a whole and also in the module configuration.

I see that the Open Weather site has a page specifying “API response parameters with available units of measurement” (https://openweathermap.org/weather-data). There one finds a parameter table specifying Parameter and Description - as well as columns for “Standard”, “Metric” and “Imperial”.

The interesting thing is this: the table specifies temperatures correctly (“Kelvin”, “Celsius”, “Fahrenheit”) but for rain it calls out “mm”, “mm”, “mm” - or other variants for different fields, e.g.: “mm/hr” and “mm/hour”.

As such, I am inclined to just give up and accept the module’s behavior as a quirk of how Open Weather parses what it is getting from the NWS - but I thought i would see if anyone has a better idea.

Re: MMM-WeatherAlerts
@Gjones93 - Can you comment on how alerts are structured in terms of granularity of area? As an example, there are currently no alerts on the MagicMirror when location is set to lon/lat corresponding to Las Vegas, NV - which is in Clark County – while there IS currently a Flood Watch for “Western Clark and Southern Nye County”. I have tried modifying the lat/lon from a detailed level to a more general level (e.g.: “36.111111 / -115.22222” to “36.1 / -115.2”) to no effect.

I recognize this is likely an issue with either how the NWS reports the alerts, or with how OpenWeather parses what it is getting from NWS - but I am hoping you understand how they operate, as I don’t see anything on either organization’s website that would help manage displaying which local/nearby/regional alerts are active…) A practical way to address this might be to specify location by county (since the NWS seems to be reporting it that way…), but it doesn’t look like the OpenWeather API supports that.

The practical effect of this is that I see no alert showing, while there is nearby significant weather. Thanks for the great module!!

@1a2a3a said in MM current version on Raspberry Pi 5 cannot turn off monitor:

vc4.force_hotplug

That does appear to work! So far I have tried it on two different Pi 4 instances, and each responded to a script called in crontab to turn off the monitor display, and then a script to turn it back on, as expected.

Thanks.

@jbat66 - thanks for the offer. If you do wind up sharing your work, I will take a look and see if it works for me.

I don’t run any remote control module, and don’t find the “MMM-remote” you reference when I search. I do, however, find at least two (2) different modules called “MMM-Remote-Control” by two different authors. Do you mean one of those?

My progress so far is that I can get the monitor to turn off using the following script (called by a cron job), but the monitor then turns back on after ~10-15 seconds:

#!/bin/bash

# Script to turn off monitor display when called by crontab
export WAYLAND_DISPLAY=wayland-1
export XDG_RUNTIME_DIR=/run/user/1000
/usr/bin/wlr-randr --output HDMI-A-1 --off

@BKeyport - That has been my general impression of Adafruit, and for the sake of general continuity, I do hope that is the case. All that said, the situation with the sensor libraries has been a mess for years - with my personal favorite gripe being libraries being deprecated without clear messaging on the website hosting the old, together with new libraries with very similar names but different functionality. For the life of me I cannot understand why simply incrementing the version numbering wouldn’t have accomplished what was needed [accompanied of course, by clear messaging…].

Meanwhile I have ordered and received some DHT20 sensors, and will soon begin standing some of those up. This has entailed first building a development instance to work on, as I find the MagicMirror system to be fragile, and I want to minimize downtime on the production instance. As of yesterday I do have the dev instance running and am trying to iron out a couple of wrinkles, like tracking down why and how the default calendar module on the new dev instance doesn’t display recurring appointments the same as on the existing [production] instance. Seeing as I literally copied and pasted the configuration code from the old to the new, I would think it would perform the same.

Anyway - thanks again for the input and the guidance, as always.

@BKeyport thanks for the response. It looks like my issue is actually with the Linux 12 / bookworm version of Raspbian I installed when rebuilding my MagicMirror, as opposed to the R-Pi 4 hardware.

In reading the Adafruit forums here: https://forums.adafruit.com/viewtopic.php?p=938344&hilit=Adafruit_Python_DHT#p938344 I find the official Adafruit response to someone with the same issues is that “DHT22 really sucks to use on linux” and … “you will be a lot happier just using the DHT20 and friends”, with a reference to an Adafruit web article at https://learn.adafruit.com/modern-replacements-for-dht11-dht22-sensors/overview.

In short, the advice is to just buy all new sensors for your Raspberry Pi installs. The OP pointed out that while he acknowledges the newer sensors may indeed be better, that " I spent a good amount of money buying and building, and for all of that to go away with an update really stinks! :( ".

I agree with him since I have probably five (5) DHT 11/22 sensors working on R-Pis, and while it looks like he found a way to upgrade all pip libraries and get it working again, it also appears to only be a matter of time until another update or upgrade of something breaks the system.

Again thanks for pointing me in the right direction.

I’m having the same issues… I recently built a new MagicMirror instance using the latest Raspbian OS, and the commands I have used in prior instances don’t work in the new OS.

None of the commands listed above work for me. I have also tried the following in the crontab. While it DOES turn off the monitor display, the display turns itself back on in about 10 seconds…

display_off >/dev/null 2>&1

Any help will be greatly appreciated, as the MagicMirror is in a location where running the display all night is disrupting people’s sleep, and having to manually turn it on and off is very inconvenient.

Thanks for your work - it looks good and has the offset feature I need! Like @BKeyport I formerly used MMM-LocalTemperature, but it won’t run on my new MagicMirror build.

For context, I currently do have MMM-DHT-Sensor running on this instance. It runs just fine, but I would prefer the look and feel of yours, as well as needing the offset feature. I have also tried changing from GPIO 4 to GPIO 21 - same results [MMM-DHT-Sensor works on either, MMM-DHT22 works on neither].

My issue with MMM-DHT22 is understanding whether one can get it to run on a Raspberry Pi 4? I have been unable to do so, and it appears to be issues with the Adafruit_Python_DHT libraries. My research appears to show your module relies on that Adafruit library, and the Adafruit library doesn’t support Raspberry Pi 4.

Am I missing something? If so, what? If not, is there a workaround?

@sdetweil - ok, understood. I guess that explains the (usually subtle) differences.

@sdetweil - Sam, how would I go about investigating an issue where it appears my MM install violated your statement (and my understanding) that there is only one web page being published?

The MM runs all the time, directly attached to and displaying on a monitor in my office. At times I will also bring it up in a browser window on the desktop, and see varying values in the weather modules running. ( I’m traveling and lack access to provide a photo showing the simultaneous different outputs, but thought I’d ask.)

@sdetweil - Thanks for the help here and offline. My problem is solved, and for the sake of others following is the resolution.

Problem: MagicMirror install script outputs node.js errors on new RaspbianOS install running under VirtualBox.

Diagnosis [by sdetweil]: “so, the problem is that the intel raspian is a hybrid, x86_64 kernel with a i386 user runtime.
and they stopped making a nodejs for i386 after node 12”

Solution: Rebuilt the virtual machine using Ubuntu instead of RaspbianOS. [I’m sure any Debian or other Linux distribution would work just fine…]

Thanks again - I can now use this as a dev machine and spare myself the risks associated with fiddling with the production machine!