Setting up weews -> opensprinkler-weather -> opensprinkler

[flynwill]

Hello:

I have had a Davis Instruments weather station connected to a Raspberry PI running weewx for some time now. I’ve also been a user of open-sprinkler for some time, I have two Raspberry-Pi based opensprinkler systems setup as master/slave pair.

Now I’m trying to use opensprinkler-weather to feed accurate local weather information to opensprinkler. I have the docker image up and running on my synology NAS. The Docker compose file currently in use (taken from examples in this forum) is this:

version: '3.8'

services:
  weather-server:
    image: ghcr.io/opensprinkler/weather-server:master
    container_name: opensprinkler-weather
    restart: unless-stopped
    ports:
      - "8085:3000" 
    environment:
      HOST: 0.0.0.0
      PORT: 3000
      GEOCODER: GoogleMaps
      GOOGLE_MAPS_API_KEY: XXXXXXX
      WEATHER_PROVIDER: local
      PWS: WU
      LOCAL_PERSISTENCE: true
      TZ: America/Los_Angeles

An I added the needed lines to weewx.conf on the weewx Raspberry Pi:

    [[Wunderground]]
        # This section is for configuring posts to the Weather Underground.
        
        # If you wish to do this, set the option 'enable' to true,
        # and specify a station (e.g., 'KORHOODR3') and password.
        # To guard against parsing errors, put the password in quotes.
        enable = true
        station = SynologyLocal
        password = SynologyPassword
    	server_url = http://ebenezer.ross-mccown.com:8085/weatherstation/updateweatherstation.php

At this point tailing the weewx logs I can see that weewx things it is successfully publishing data with every update cycle (every 10 minutes in my setup). Opening a shell on the container I can see that a file /weather/geocoderCache.json appears immediately after the first update. However the expected /weather/observations.json never appears.

Likewise querying the opensprinkler-weather interface using some of the example query urls usually gives “Error 11” which I believe means not enough data collected.

Not sure how to make further progress on this. Is there documentation of the environment vars for opensprinkler-weather somewhere? I was unable to find anything among the docs in the github repository.

[Ray]

After settings up Local weather provider, you generally need to wait at least 24 hours so your server can collect enough data for any of the weather adjustment method to calculate reliable numbers.

[flynwill]

I did wait 24 hours, that’s when I finally decided to connect to the container with a shell and look and saw that the expected /weather/observations.json was not there.

However, somehow the issue got fixed this afternoon. The only change I made was to change the environment section from a YAML list to the dictionary syntax that you see in what I posted above, so perhaps that was needed to the environment to be set up properly.

I am now seeing data being collected, so tomorrow afternoon I should be able to test to see if it is actually integrating properly with OpenSprinkler.

That does leave a further problem however, that is how to get the data to be saved outside of the container so that it will persist over restarts, or container updates. My first attempt was to map the /weather to an outside folder:

volumes:
    - ./weather:/weather

but from the resulting errors it’s clear that the container is dependent on the other files in /weather I’m guessing the workaround is to copy all the files in /weather out of the container somehow, but that means those files won’t get changed if the container is updated. Much better would be if there is an environment var that specifies the folder where opensprinker-weather should save the observations.json and any other files that should be persistent.

PS: Once I have this figured out I’d be happy to help add to the DOC pages on github for the next person.

[Ray]

This is going beyond my knowledge. To be honest, these are questions that Codex or Claude Code can answer really well. You can start with Codex as it gives you free access without subscription. Just install Codex, run it in the folder that you installed the weather code, then you can ask questions, describe the symptom, and ask it to fix the issue.

[flynwill]

So after running for a day and a half I see that the observations.json has exactly one day’s worth of data, corresponding to the most recent 24 hours. However when I attempt to query the server with the example URLs from the github docs I’m still getting “Error 10” which Google says means “insufficient data”, is google right or does that error actually mean something different?

will@cratchit$ curl 'http://ebenezer.ross-mccown.com:8085/weather1.py?loc=50,1&wto="h":100,"t":100,"r":100,"bh":70,"bt":59,"br":0'
&errCode=10&scale=100

Does the lat/lon passed in these call matter in the case of a personal weather station? I didn’t see any way to configure a lat/lon.

[Ray]

Error 10 indeed means insufficient data:
https://github.com/OpenSprinkler/OpenSprinkler-Weather/blob/master/src/errors.ts#L10
This could mean things other than not having 24 hours of data – assuming you haven’t updated your OpenSprinkler-Weather repo (we released a new version, 3.1.0 just yesterday) – the older version you are on requires local weather station to also report solar radiation and other parameters, which some local weather stations don’t report. These could also lead to error 10, I think. Again, it would be really easy if you can install codex and just ask it to find out the reason it’s returning errorCode 10.

[flynwill]

Ah, indeed my weather station does not return Solar Radiation, Here’s the records being recorded:

{"timestamp":1786545600,"temp":67.1,"humidity":93,"windSpeed":0,"solarRadiation":null,"precip":0}

Is that sufficient data for the newest version?

[Ray]

Yes the new version (3.1.0) we just released yesterday addressed this issue by not requiring solar radiation if you use Zimmerman adjustment method.

[flynwill]

Ok I’m making progress… The docker image now seems to be running and working as advertised.
Weewx is logging successful posts, and querying the the server with curl yields the expected results:

Now now I’ve turned my attention to the OSPI OpenSprinkler and getting it configured. Attempting to set the Weather Server through the /su page however fails consistently with “error 2”. However I was able to set the server via the API and curl.

And browsing to the su page again I see that the server is correctly set to http://ebenezer.ross-mccown.com:8085, However it is still not querying. I setup tcpdump on the Synology hosting the docker image and trapped all traffic to port 8085, I can see the periodic updates from my weather station, and also from my test queries quoted above. However I don’t see any queries from the OpenSprinkler RPI, not even after doing a systemctl restart OpenSprinkler on the RPI to restart the service which I expected would do an immediate query.

Any suggestions as to where to look next?

PS: I had to edit out all of the examples of my curl queries because this post seemed to be getting blocked by some security system.

[flynwill]

For other’s reference here is the docker compose YAML:

version: '3.8'

services:
  weather-server:
    image: ghcr.io/opensprinkler/weather-server:master
    container_name: opensprinkler-weather
    restart: unless-stopped
    ports:
      - "8085:3000" 
    environment:
      HOST: 0.0.0.0
      PORT: 3000
      GEOCODER: GoogleMaps
      GOOGLE_MAPS_API_KEY: XXXXXXX
      WEATHER_PROVIDER: local
      PWS: WU
      LOCAL_PERSISTENCE: true
#     the documentation indicates that /data is the default PERSISTANCE_LOCATION for the docker build.
      PERSISTENCE_LOCATION: /data
      TZ: America/Los_Angeles
#      LOG_LEVEL: debug
    volumes:
     - ./data:/data

[flynwill]

I’m still stuck. I have made progress, using tcpdump I determined that the OSPI is indeed sending queries to the OpenSprinkler-Weather instance, and those queries are failing with error code 35 Provider API key missing. Now that I have the complete URL that the OSPI is sending I can see that the issue must lie with the provider option being passed. If I modify the URL to remove the provider and key fields and test with curl there is no error. So the question is: How do I configure OpenSprinkler to know that the weather server is a personal weather station and the provider field should be left off?

Update: Reading the OpenSprinker-Weather API doc I see that the provider should be local in this case, but there is no “Local” option in the Options->Weather adjustments menu. Is there some config somewhere needed to make this option appear?

[flynwill]

Further update. I was able to set the weather provider field to null using the API /co call and now it seems to be working. So the real issue is the options that need to be set can’t be set through the Web GUI interface.

[Ray]

You have correctly identified the issue. Removing provider and key from your test URL allows the server’s WEATHER_PROVIDER=local setting to take effect, but that does not change the options stored by OpenSprinkler. The UI currently has no way to clear the selected provider if you already selected it.

When you start your firmware in a factory reset setting, the wto field is empty, i.e. it contains no provider or key. If you subsequently used the UI to select a different provider, those will remain and not be cleared.

You can either perform a factory reset; alternatively, here is a work-around: use firmware’s /co endpoint to rewrite the stored wto value without provider and key, while preserving the adjustment parameters you may need. We will add a Self-hosted choice to the UI so this can be configured normally without manual rewriting.

[flynwill]

That would be a useful addition. Meanwhile I can write up my config and the steps I took to get this working for the benefit of other users.

Also there is the matter of not being able to set the Weather Server through the /su endpoint (I had to use the API /cu endpoint to set that). Perhaps that should get moved to the Weather options menu also?

Now the fun part begins in actually tuning the parameters to provide a reasonable match for the actual water needs. First step will be to just monitor it’s behavior as the weather gets cooler.

[Ray]

Regarding /su failure: this is not a known issue. But here is how it’s implemented, to help diagnose the issue: /su returns an HTML form rather than changing the URL directly. That form loads the external hasher.js script to hash the password, then submits the values to /cu. If hasher.js fails to load, the submission will fail authentication. Check the browser console/network log for the script request and inspect the resulting /cu request.

We deliberately do not want to show these url change options to the main UI, for a good reason: these are for advanced users. If you show these to regular users, they may change it unintentionally, and diagnosing it becomes a support nightmare. So it’s deliberately hidden from regular UI.

[flynwill]

Nevermind about the su failure…. That was user error.

[RfxiEmil]

You should check the weather-server container logs right after a WeeWX update. Since geocoderCache.json appears but observations.json does not, the server seems to be running but not accepting the weather data.

Also try the NAS IP directly instead of the hostname to rule out DNS or reverse proxy issues. Check whether station = SynologyLocal matches what the local provider expects. The container logs should give you a better clue about where the POST is failing.

[Author]

Posts