Weather station -> WeeWX -> Weather-Server -> OSPI -> error

[SM]

Hallo all,

I have a Froggit WH1080 weather station and an OpenSprinkler PI (Firmware 2.2.1 (4), Hardware OSPI).

In addition, I ran the OpenSprinkler Weather-Server in a Docker LXC on Proxmox.

The weather station is read out by WeeWX (5.2), which also runs on Proxmox in a VM.

Background of this setup: The values of the weather station should “control” the Zimmerman method at the OSPI.

I created the Weather-Server as follows using Docker-Compose:

services:
  weatherserver:
    image: ghcr.io/opensprinkler/weather-server:master
    container_name: WeatherServer
    restart: unless-stopped
    environment:
      HOST: 0.0.0.0
      PORT: 3000
      GEOCODER: GoogleMaps
      GOOGLE_MAPS_API_KEY: XXXXXXX
      WEATHER_PROVIDER: local
      PWS: WU
      LOCAL_PERSISTENCE: true
      TZ: Europe/Vienna
    ports:
      - 3000:3000
    working_dir: /weather
    volumes:
     - /home/sadmin/Docker/Daten/WeatherServer/observations.json:/weather/observations.json
     - /home/sadmin/Docker/Daten/WeatherServer/geocoderCache.json:/weather/geocoderCache.json

I have set up the connection between WeeWX and Weather server as in the following instructions: https://github.com/OpenSprinkler/OpenSprinkler-Weather/blob/master/docs/weewx.md

This setup has been running for a few days / weeks.

The file observations.json (attached) becomes larger and thus obviously also receives values from WeeWX.

On the “su side” of the OSPI, I specified the weather server correctly.

However, my OSPI always reports when Zimmerman method is choosen: Weather Data Incomplete.
With the manual method, the weather data is loaded correctly.

What am I doing wrong?

Where could the error be?

I am happy about any kind of help.

Thank you very much in advance.

Sigi

[Ray]

Can you attach the the files as a single zip? The forum only accepts zip, and image files.

[SM]

Sure.

Attachments:

1. Archiv.zip

[Ray]

I checked the observations.json. One thing I noticed is that the solarRadiation is null – this will cause ETo to fail, though that shouldn’t be the source of the issue since you said you use Zimmerman. Since you know the error message (“Weather Data Incomplete”) it should be easy to debug – you can open the Zimmerman adjustment method code, insert a few console.log where it returns error code such as weather data incomplete, and re-compile the weather code, and run it. Upon a weather query, it should print out the debug message so you will see which data is missing. It could be that it doesn’t have a full 24 hours of data of the previous day, or it could be a specific field (such as precipitation) is missing. If you don’t know how to modify the code, just upload the weather code as a single zip to generative AI (ChatGPT, Gemini, Claude, etc.), describe the symptom and let it figure out the problem or diagnostic steps.

[SM]

Hello Ray,

Thank you for your response and for the hint about AI.

With the help of claude.ai, I conducted several investigations on my systems.

Here’s what I found and changed:

I reviewed the OpenSprinkler Weather Server repo again and decided to change my Docker container from tag :release to :pr-170 to utilize the Multi-Day Averages functionality (7-day data retention).

On the OSPi’s su page, I added a trailing slash after the port in the Weather Service URL.

Since I want to use both Weather Underground and the Weather Server with WeeWX, I’m using the WeeWX extension Wundergroundlike (https://github.com/vinceskahan/weewx-wundergroundlike). This extension appears to send data on both loop and report events, which caused duplicate values in my observations.json.
I was able to fix this by adding post_interval = 300 (300 seconds corresponds to my report interval of 5 minutes) in the [[WundergroundLike]] section of weewx.conf.
I also cleaned up the existing duplicates.

My OSPi has been running for years and has gone through multiple updates (both Raspberry Pi OS and OpenSprinkler). Apparently, an error crept into the settings over time.
I performed a factory reset of all settings in the web UI and then reconfigured the location.

Now I’m getting “success” messages and sensible values in the OSPi, and everything works as expected.

Perhaps my approach can be helpful for others as well.

In any case, this entry can be marked as solved/closed.

Thanks again to Ray for his helpful guidance.

Happy holidays!
Sigi

[franzstein]

Hello Sigi, Ray,

I’m new to Docker and need some help with the OpenSprinkler-Weather server installation. I’m already running WeeWX on a Raspberry Pi 3 and used an old local OpenSprinkler-Weather server installation in the past. Reading about this threat gave me the idea of using the WeeWX Wundergroundlike extension and running the Weather Service Version 3.0.2 in a Docker Installation. I’m using Debian GNU/Linux 12 (bookworm) and Docker Version 29.1.3.

The weather server was installed from the command line as described in the corresponding github weather-server installation description.

pi@raspberrypi:~ $ docker pull ghcr.io/opensprinkler/weather-server:master

Thereafter, I created the /weather directory and copied the above described compose.yaml to it. However, I deleted the “volumes definition”, for reason that it will not work in my setup.

I started the WeatherServer with Docker Compose:

pi@raspberrypi:/weather $ docker compose up
[+] up 2/2
 ✔ Network weather_default Created                                                                                                                       0.3s
 ✔ Container WeatherServer Created                                                                                                                       0.5s
Attaching to WeatherServer
WeatherServer  |
WeatherServer  | > [email protected] start
WeatherServer  | > node dist/index.cjs
WeatherServer  |
WeatherServer  | OpenSprinkler Weather Service now listening on 0.0.0.0:3000
WeatherServer  | OpenSprinkler Weather Service now listening for local weather stream
WeatherServer  | Loaded baseline ETo data.

It works as expected and is still waiting to get sufficient weather data.

OpenSprinkler Weather Service v3.0.2
&errCode=10&scale=100

The question is now, what “volumes definition” is valid for my setup? I would like to have the observations.json file in place, to cache the weather observations. Any ideas?

Thanks in advance.

Franz

[franzstein]

With the help of the Docker Community I finally solved it. The compose.yaml file looks now as follows:

#YAML configuration file, known as the Compose file, to configure the WeatherServer services.

services:
  weatherserver:
    image: ghcr.io/opensprinkler/weather-server:master
    container_name: WeatherServer
    restart: unless-stopped
    environment:
      HOST: 0.0.0.0
      PORT: 3000
      GEOCODER: GoogleMaps
      GOOGLE_MAPS_API_KEY: XXXXXXX
      WEATHER_PROVIDER: local
      PWS: WU

# LOCAL_PERSISTENCE=true will cause the WeatherServer to write the received weather history
# to disk every 30 minutes so that when it restarts it can pick up from where it left off.

      LOCAL_PERSISTENCE: true
      TZ: Europe/Vienna
    ports:
      - 3000:3000
    working_dir: /weather

# The Weather Service needs at least 23 hours worth of data to create a meaningful water scale.
# The "WeatherData" volume is used as persistent data store implemented by the container engine.

    volumes:
      - WeatherServer:/weather

volumes:
  WeatherServer:
      name: "WeatherData"

It’s maybe some help for others, who like to run the Weather Server locally on a Raspberry PI.

Thanks

Franz

[franzstein]

Just FYI. Running the WeatherServer several days I encountered the following problem. After 1 to 3 days the WeatherServer request ended up in “There is insufficient data to support Weather response from local PWS.”. I don’t know what causes this issue. Looking at the observations.json file there seems to be no big problem. There are sometimes missing measurements? However, there are enough timestamps to cover the requested period of more than 23*60*60 seconds.

WeatherServer request:
192.168.178.38:3000/weather1.py?loc=49.47432,10.94365&wto=”h”:100,”t”:100,”r”:100,”bh”:65,”bt”:70,”br”:0

Response:
&errCode=10&scale=100

If I restart the Docker container with docker restart WeatherServer the response is fine again:

&scale=0&tz=52&sunrise=480&sunset=1017&eip=3232281146&rawData={"wp":"local","h":86.12,"p":0,"t":20.6}&errCode=0&scales=[0]&ttl=35096739

I know that there are some OpenSprinkler-Weather Pull requests waiting for review. Nevertheless, it might be helpful to look at this issue?

Attachments:

1. observations.zip

[Ray]

Honestly I think the best way to debug this is to insert console.log in the code it can print out any variable value or debugging messages to help you diagnose the issue. Error code 10 does generally mean ‘insufficient weather data’:
https://github.com/OpenSprinkler/OpenSprinkler-Weather/blob/master/src/errors.ts
it can be raised in a number of places, including if it needs solar radiation, for example, but your weather service does not return solar radiation or it’s a null. You can search in the code where this error InsufficientWeatherData is raised to find out.

[franzstein]

Thank you for the support. I have started to insert console.log functions in the weather service code to print out variable values and debugging messages to help to diagnose the issue. Moreover, I’m running the weather service on my Raspberry Pi 3 outside docker and used the PM2 Daemon Process Manager to log the console messages. The Observation captured from the local datastream shows no missing measurements and is – with a few exceptions – continuously received every 5 minutes.

The error occurs after 2 days. In response to the Zimmerman Adjustment server request the cached Watering Data has expired and must be newly cached to answer the request. It looks like the metric check with the variables cTemp, cHumidity, cPrecip, cSolar, cWind isn’t working as expected. The variables are overwritten by the queue.length variable!

The logged console output triggered by the Zimerman Adjustment server request in the non-error case is:

WateringData expiry time:  _TZDate 2026-02-10T23:00:00.000Z {
  timeZone: 'Europe/Berlin',
  internal: 2026-02-11T00:00:00.000Z
}
Amount of Watering Data measurements (queue.length):  273
Watering Data derived from local datastream:  {
  weatherProvider: 'local',
  temp: 38.32051282051279,
  humidity: 90.45787545787546,
  precip: 0,
  periodStartTime: 1770616800,
  minTemp: 31.1,
  maxTemp: 43.7,
  minHumidity: 83,
  maxHumidity: 100,
  solarRadiation: 0,
  windSpeed: 8.299999999999994
}
Zimmerman Adjustment Method Watering Data:  [
  {
    weatherProvider: 'local',
    temp: 38.32051282051279,
    humidity: 90.45787545787546,
    precip: 0,
    periodStartTime: 1770616800,
    minTemp: 31.1,
    maxTemp: 43.7,
    minHumidity: 83,
    maxHumidity: 100,
    solarRadiation: 0,
    windSpeed: 8.299999999999994
  }
]

In the error case we get:

WateringData expiry time:  _TZDate 2026-02-11T23:00:00.000Z {
  timeZone: 'Europe/Berlin',
  internal: 2026-02-12T00:00:00.000Z
}
Amount of Watering Data measurements (queue.length):  280
Watering Data derived from local datastream:  {
  weatherProvider: 'local',
  temp: 39.0307142857143,
  humidity: 90.70357142857142,
  precip: 0.07999999999999999,
  periodStartTime: 1770701700,
  minTemp: 30.9,
  maxTemp: 43.9,
  minHumidity: 80,
  maxHumidity: 97,
  solarRadiation: NaN,
  windSpeed: 7.477499999999991
}
log: Invalid or missing weather data to support watering calculation from local PWS.
cTemp:  280
cHumidity:  280
cPrecip:  280
cSolar:  0
cWind:  280
minTemp:  30.9
maxTemp:  43.9
minHumidity:  80
maxHumidity:  97

There is insufficient data to support watering calculation from local PWS.

Please find the console logs and the modifications to the local.ts, WeatherProvider.ts and the ZimmermanAdjustmentMethod.ts in the files attached.
Unfortunately, I’m not good at TypeScript programming and have no idea why these variables are necessary? Isn’t it possible to use the result.temp, result.humidity, result.precip, result.solarRadiation, result.windSpeed variables for this metric check?
Any suggestions?

Attachments:

1. Raspberry-PI-Weather-Service-Analysis.pdf

[Ray]

The issue seems to be solarRadiation is NaN (not a number). It’s puzzling because your other outputs have solarRadiation as 0 which is expected, but why does it suddenly give out a NaN? Yes you can modify the code to avoid this issue or simply assign a 0 to any variable that is invalid. You can use any gen AI to help you modify the code (Gemini, Claude, ChatGPT). We routinely use gen AI to spot bugs, identify issues, and implement new features. You can totally use it to change the code yourself without having to rely on us.

[franzstein]

I’ve changed some of the console logs again to investigate the puzzling behavior. After restarting the weather server, the weather data for the watering data calculation is retrieved from the observations.json file. The observations are stored as null in the observations.json file (JSON silently replaces NaN with null):

{
	"timestamp": 1770788700,
	"temp": 39.7,
	"humidity": 97,
	"windSpeed": 4.3,
	"solarRadiation": null,
	"precip": 0
	}

Restoring the observation.json file data generates counted solarRadiation: null data items.
The observations captured from the local datastream are as:

{
        timestamp: 1770880200,
        temp: 40.3,
        humidity: 100,
        windSpeed: 9.3,
        solarRadiation: NaN,
        precip: 0
        }

This means the watering data calculation is a mix of retrieved and captured weather data for the first 2 days. After the 2nd day only captured data is used for watering data calculation. There are no counted solarRadiation: null data items anymore and the resulting cSolar counter equals 0, which leads to the insufficient data issue.

To be honest, the metric check including the cSolar and cWind counters is somehow overdone. The corresponding data items aren’t necessary for the Zimmerman calculation. NaN for windSpeed and solarRadiation observations shouldn’t cause errors, if the Zimmerman Adjustment Method is requested.

As a workaround I modified the metric check as follows:

if ( !( cTemp && cHumidity && cPrecip ) ||
[ result.minTemp, result.minHumidity, -result.maxTemp, -result.maxHumidity ].includes( Infinity )) {
	console.error( "There is insufficient data to support watering calculation from local PWS." );
	throw new CodedError( ErrorCode.InsufficientWeatherData );
}

[Ray]

https://github.com/OpenSprinkler/OpenSprinkler-Weather/issues/178#issuecomment-3901645509

[Author]

Posts