Posts made by j.e.f.f

j.e.f.f

@ebolisa said in MMM-OpenWeatherForecast - Replacement for MMM-DarkSkyForecast:

@j-e-f-f Thanks for sharing.

Does it work on Pi Zero? In my case it doesn’t load. I just see FORCAST and then “Loading…” forever :astonished_face:
Using defaults, no changes made.

I haven’t tested this on a pi zero (I don’t have one to test on). Do you see any errors either in pm2 logs mm or in Electron if you run Magic Mirror with npm start dev?

Also, just double-checking: did you remember to run npm install in the MMM-OpenWeatherForecast` directory to ensure all of the dependencies were installed? Forgetting to do this would be another reason you might see it stuck on “Loading…”

j.e.f.f

@swvalenti said in MMM-OpenWeatherForecast - Replacement for MMM-DarkSkyForecast:

@j-e-f-f Am I missing a way to turn off current weather alerts? Once a weather alert like high wind or snow it drops my tables down and throws other modules off.

If you set summary: false this will stop weather alerts from displaying. The OpenWeather API doesn’t return a detailed summary (usually just a single word like “Cloudy.” ) so I didn’t think it was necessary to split these two out into separate configs.

If you wanted to keep the summary, but not show weather alerts, you can set summary: true in your config and then prevent display of alerts in your custom CSS as follows:

.MMM-OpenWeatherForecast .weather-alert {
  display: none;
}

j.e.f.f

@jenga said in MMM-OpenWeatherForecast - Replacement for MMM-DarkSkyForecast:

I am trying to adjust the hours under the hourly forecast to reflect a different time zone. I was reviewing the code and I see UTC references. How can I adjust this to CST?

The API returns UTC time for everything as well as a timezone offset for the long/lat you provide. The module translates UTC into local time using these two bits of information. Say you’re living in London, but you configure this module with Long/Lat for New York, then the time you’ll see is local to New York. I can’t request a different timezone in the API.

UPDATE

So quick to jump to conclusions am I… this was a bug in my code. OpenWeather documentation says the hourly time forecasts are provided in UTC, and elsewhere in the API response a timezone offset is provided. I took this to mean that in order to see local time for the forecast I needed to add the offset to the hourly time. As it turns out this is not the case. OpenWeather does not explicitly say this anywhere in the docs that I could find, but the JSON response is already translated to whatever local timezone the request was made from. So if I live in London and I make a request for weather in Chicago I’ll see the hourly forecasts in local London time, not in local Chicago time.

I’ve changed the code so that I no longer add the offset to hourly forecast times. Do a git pull in the MMM-OpenWeatherForecast directory, then restart MM. Should be fixed up.

j.e.f.f

@swvalenti @BKeyport

I’ve released the module for everyone. To get the latest code, you’ll need to navigate to your installed MMM-OpenWeatherForecast directory and execute:

git pull

followed by

npm install
(depencies have changed, so this step is important!)

Optionally you can run npm prune to remove old dependencies that are no longer used, but not necessary,

Restart MM and you should be good to go.

j.e.f.f

@stoffbeuteluwe No you can’t change those names. The code explicitly looks for those header names. But they are never exposed to the module’s display – only icons are displayed

If it helps, here are what the headers refer to:

GreenBin: refers to compost
Garbage: household waste that is not compost or recyclable
Recycling: recyclable waste
YardWaste: waste from gardening or landscaping (leaves, grass clippings, etc)
ChristmasTree: usually a service provided in January that picks up dead Christmas trees after the festive season is over.

j.e.f.f

Ever since Apple bought Dark Sky and announced that that would stop allowing free access to their API (Thanks Apple!), I’ve been meaning to write a replacement for MMM-DarkSky Forecast.

Well I finally got off my lazy ass and wrote it. Link to code here:
https://github.com/jclarke0000/MMM-OpenWeatherForecast

If you’re already using MMM-DarkSkyForecast, this will look familiar to you. In fact I based MMM-OpenWeatherForecast on MMM-DarkSkyForecast’s code.

But! Many improvements have been included. With this rewrite I have made it possible to display every bit of weather data provided in OpenWeather’s One Call API. Be sure to fully read the README.md file to see how you can configure this module exactly to your liking.

Installation:

Navigate into your MagicMirror modules folder and execute
git clone https://github.com/jclarke0000/MMM-OpenWeatherForecast.git.
Enter the new MMM-OpenWeatherForecast directory and execute npm install.

NOTE
If you’re using a pre-release version, doing git pull won’t be enough to install the latest code. I replaced the deprecated request library with axios. So make sure you run npm install to get the latest dependencies. Optionally you may run npm prune to remove installation for request.

Configuration:

At a minimum you need to supply the following required configuration parameters:

apikey
latitude
longitude

apikey needs to be specified as a String, while latitude and longitude can be specified as either a String or a Number. Both work fine.

e.g.,

  {
    module: "MMM-OpenWeatherForecast",
    position: "top_right",
    header: "Forecast",
    config: {
      apikey: "a1b2c3d4e5f6g7h8j9k0", //only string here
      latitude: 51.490230,            //number works here
      longitude: "-0.258810"          //so does a string
    }
  },

You need to create a free account with OpenWeather in order to get an API key:
https://home.openweathermap.org/users/sign_up.

Free tier is fine – this module will not make anywhere near 60 calls per minute / 1,000,000 requests per month.

Find out your latitude and longitude here:
https://www.latlong.net/.

Refer to the README for all of the other configuration options.

NOTE
This module uses the Nunjucks templating system and therefore requires MagicMirror version 2.2.0 or later.

j.e.f.f

@bkeyport Glad it’s working for you! Thanks for pointing out the typo. Will fix.

j.e.f.f

@swvalenti

@swvalenti said in MMM-DarkSkyForecast - Yet ANOTHER weather module:

Can the throughout the week line up better with the hourly above like the icons and other data sets?

You can do this, but you’ll need to do it in your custom CSS. Here’s why:

The old module used a single table for both weekly and hourly forecast. But with the additions I have made in this module, you can have different columns for your hourly forecast versus what you have for weekly, and therefore they are two separate tables, meaning they might self-adjust to the content in the columns differently, even if you have the same columns in both.

I can’t enforce a uniform column width because a) I don’t know how many columns you’ll be using and b) I don’t know the width of the master region in Magic Mirror that you are using.

So long winded way of saying that once you have configured your tables just the way you like, if you want them to be uniform, you need to take a the extra step to set explicit pixel widths for your columns in your custom CSS file. Here’s an example of what that could look like:

.MMM-OpenWeatherForecast .wrapper.table .forecast-container .forecast-item .time,
.MMM-OpenWeatherForecast .wrapper.table .forecast-container .forecast-item .day-name {
  width: 105px;
}

.MMM-OpenWeatherForecast .wrapper.table .forecast-container .header-row .weather-icon-header,
.MMM-OpenWeatherForecast .wrapper.table .forecast-container .forecast-item .forecast-icon-container {
  width: 80px;
}

.MMM-OpenWeatherForecast .wrapper.table .forecast-container .header-row .temperature-header,
.MMM-OpenWeatherForecast .wrapper.table .forecast-container .forecast-item .temperature-container {
  width: 100px;
  white-space: nowrap;
}

Prefixing your CSS with .MMM-OpenWeatherForecast .wrapper.table limits your rules to just the MMM-OpenWeatherForecast module and specifically .wrapper.table will limit your rules to the table layout version. This way if you change your mind and switch to the tiled layout, it won’t be affected by the rules you set for the table layout.

If you take a look at mmm-openweather-forecast.njk you can figure out what the class names are for each specific column, so you can target specific columns. I’ve given pretty much everything a unique class so you should be able to style everything exactly as you need. Make sure you style every column in your tables. If even one column is left unstyled you might get the same problem with them not lining up.

I hope this helps!

j.e.f.f

Hi folks

I’m noticing that many of you are experiencing failures of this module. It’s very likely that Apple is systematically shutting down the API access for some, but not everyone. In that light, I’ve made a replacement for it that uses the OpenWeather API instead.

I’m not ready to release it to the masses just yet, but if you’d like to try it out, link is here:
https://github.com/jclarke0000/MMM-OpenWeatherForecast

It works and looks the same, but has a few added features – be sure to read the README to see how to configure it.

Let me know if you run into any issues. I’m currently running it on three separate systems – my laptop for debugging and two raspberry pis, and it’s looking pretty good.

j.e.f.f

@stoffbeuteluwe I wonder if it’s the spaces you have after the commas? I think that might confuse the parser