@foggy - @sdetweil may be onto something. I jsut added your url to my config.js file and I now get the BBC just fine.

I also wonder whether the "{ " and “}” brackets are required but missing in your feeds array? I have each feed url in its own brackets and it works for me. See my config below, modified to add your BBC url.

@sdetweil - related question: In the[recent] past my system has always restarted Magic Mirror when i commit a change to config.js using control-O, but lately it doesn’t and I have to manually restart MM. Is this expected behavior?

Here is the file MagicMirror/config/config.js now correctly displaying BBC news.

{module: "newsfeed",
     disabled: false,
     tableClass: "small",
     position: "bottom_center",    // bottom_center bottom_bar
     config: {
     feeds: [
        { title: "New York Times", url: "https://rss.nytimes.com/services/xml/rss/nyt/HomePage.xml" },
        { title: "BBC", url: "https://feeds.bbci.co.uk/news/world/rss.xml"},
        { title: "Las Vegas Review Journal", url: "https://www.reviewjournal.com/feed/" },
        { title: "Detroit Metro Times", url: "https://www.metrotimes.com/detroit/Rss.xml" },
           ],
           reloadInterval: 600000, // Content fetch interval - 600000 = 10 minutes
           updateInterval: 15000, //Display new headline interval - default = 10000 milliseconds / 10 seconds
           showSourceTitle: true,
           showPublishDate: true,
           broadcastNewsFeeds: false,
           broadcastNewsUpdates: false
                } },

@MMRIZE
OK - thanks. Maybe I will give it a try…

@MMRIZE
Do you know whether the install script developed and maintained by @sdetweil would install on various specified versions of Windows [E.G. Win7, Win 8, Win 8.1, Win 10 or Win 11]? if that script will install on the various implementations of Windows, that would likely solve this question of how to do it.

Kristian - do the links to the modules listed as numbers 7-10 need some validation? :)

@sdetweil - Sam, I know you don’t have the answer either. I guess I was partly venting, and partly trying to be complete so that others who are having issues or questions can see that various of you and us have tried to work this through.

@sdetweil – Hi Sam. I guess maybe my central point got lost in transit - which is I just want[ed] to know from openweathermap.org whether they can tell me if the API key they issued last year (around the time it became apparent ver 2 would be deprecated) is a ver 3 or ver 2 key. FWIW, I did try one final time and explicitly asked only whether they can tell me the version of key I have. They did respond to the email, but did not address the question.

Yes, I’m sure you are correct and it probably is simple from their point of view. However, the issue is that they are [apparently] currently servicing both the old and the new APIs, so from the user’s side it is not possible to do what they and you are suggesting and just see if calling with the old key generates an error.

If I run my MagicMirror and the API that openweathermap.org issued me last year is the old API the module will still work, so there is no diagnostic value there. Yes, I do see that when the point in future time comes that they shut down responding to calls using the ver 2 API and only respond to ver 3 - then all our modules that are calling with ver 2 APis and modules using old endpoints will fail.

My goal was to get ahead of this and avoid having the modules fail, or in the alternative having to replace the API keys in every module in every MagicMIrror where it is used - just in case they issued me a ver 2 API key last year.

Thanks again to you and Krisjan for all the help and support!

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