G6EJD / ESP32-e-Paper-Weather-Display

An ESP32 and 2.9", 4.2" or 7.5" ePaper Display reads Weather Underground data via their API and then displays the weather
Other
978 stars 207 forks source link

Layout editor #260

Closed Oxmaster closed 3 months ago

Oxmaster commented 3 months ago

I wanted to comment that this project is quite nice.

I want to make a more usefull layout for 2.9" display. I don't need to see "city name", moon phases, wind directions etc. I only care about temperature and precipitation for current day and next one. Not sure how to edit the program to my needs.

Also is there support for non battery application with more frequent updates and partial refreshes?

G6EJD commented 3 months ago

The orphanage fetches the data into the various logically named variables eg dewpoint or humidity or temperature. It then displays the variables at the defined x, y locations. Solid you want to omit any displayed data just scroll down through the programme and remove the sections of display you don’t need, so remove display_moon or I may have called it just moon();

I think you’ll find it very easy to do to get to what you need left.

Finally adjust the x, y coordinates and text size to suit your needs.

I have made all the functions modular so they can be used or not by a single line, they are either called or not.

I don’t use partial refresh because the overheads of the display are too great for simple code,, for example you can only write to a section of the screen a few times before that section starts to go dark, which then needs the whole screen to be cleared and reset the ink pigment particles.

you will find with this size screen it is the most efficient of the pepper displays s d can run on battery power for about 1-year, not they your using battery power. The surplus is also one of the fastest available.

Oxmaster commented 3 months ago

I've almost got what I want. I've added the 3 hour forecast from 2.7" example. I will also try to add the wind direction arrow from 2.13" display.

I will be adding a small LED strip and LDR to light it up at night.

image

Waveshare_2_9_v4.zip

G6EJD commented 3 months ago

Looking good, I think you’ve got the hanger of it now.

Oxmaster commented 3 months ago

Something is wrong, the next day forecast is still on thursday even though it's thursday.

How does the forecast variable work?

This is my displayweather function that should display the next day forecast

//#########################################################################################
void DisplayWeather() {             // 2.9" e-paper display is 296x128 resolution
  UpdateLocalTime();
  Draw_Heading_Section();           // Top line of the display
  Draw_Main_Weather_Section();      // Centre section of display for Location, temperature, Weather report, Wx Symbol and wind direction

  const uint16_t spacing = 50;
  const uint8_t yloc = 102;
  uint16_t xloc = 0;

  Draw_3hr_Forecast(xloc, yloc, 1);    // First  3hr forecast box
  xloc += spacing;
  Draw_3hr_Forecast(xloc, yloc, 2);    // Second 3hr forecast box
  xloc += spacing;
  Draw_3hr_Forecast(xloc, yloc, 3);   // Third  3hr forecast box
  xloc += spacing;
  Draw_3hr_Forecast(xloc, yloc, 4);   // Fourth  3hr forecast box
  xloc += spacing;
  Draw_3hr_Forecast(xloc, yloc, 5);   // Fifth 3hr forecast box
  xloc += spacing;
  Draw_3hr_Forecast(xloc, yloc, 6);   // Fifth 3hr forecast box

  int Forecast = 1, Dposition = 0;
  DisplayForecastWeather(257, 38, Forecast, Dposition, 57); // x,y coordinates, forecast number, position, spacing width
}
G6EJD commented 3 months ago

This is really a OWM issue not the code, it just displays what’s broadcast/recovered. There is a strange anomaly in they broadcast say Thursdays forecast that is the same as the 06:00 variant right up to 11:00 and sometimes up to 13:00 even though they give the forecast the correct time. In some of my later code for bigger screens I detect this issue and place an * by the forecast to denote it is incomplete, usually by 14:00 the forecast is corrected. Because the weather data is loaded into an array and then it is displayed in the order received eg 1, 2, 3, 4, 5, 6, so you can move the data forward by 1 to 2, 3, 4, 5, 6 etc thereby ignoring the daily anomaly by OWM.

Oxmaster commented 3 months ago

I don't see any other example with a day ahead forecast, only 2.9" seems to have it.

I'm under assumption that forecast is the day, 0 is today, 1 is tomorrow and so on.

int Forecast = 1, Dposition = 0;
  DisplayForecastWeather(257, 38, Forecast, Dposition, 57); // x,y coordinates, forecast number, position, spacing width
G6EJD commented 3 months ago

That’s because the code doesn’t correct for it. If you study the early morning responses from OWM you can see the effect. If you move the API call to the new OneCall it will solve it, but it’s a subscription based service with 1000 free calls per day.

Oxmaster commented 3 months ago

1000 updates per 24 hours is plenty. Is it hard to change to OneCall variant? Can't see any examples for the new API

G6EJD commented 3 months ago

Version 7.5” uses onecall