[Peter]

@paravis, you can query OWM for your particular PWS data. I have been sending in my PWS data for a few months now and have checked that it is being received using their new v3.0 api. You can make a call to the url below substituting in your api key and station id to get the last weeks worth of daily values:

https://api.openweathermap.org/data/3.0/measurements?station_id=<station id>&type=d&limit=100&appid=<app id>&from=1559476800&to=1560081600

As far as I understand it both WU and OWM have in effect have two loosely coupled solutions each. The first allows users to store/receive PWS tagged weather observations. They both then use this data to help “teach” their predictive solution. The predictive solution allows the user to query the weather for any lat/lon and WU/OWM apply their “artificial intelligence”, “crowd sourced”, “interpolated”, “micro-location” (buzzword buzzword) algorithm to predicts the current/forecast weather at that location. It is a little un-intuitive that querying based on your PWS ID and then querying based on your PWS lat/long can give very different results. This is because WU and OWM weight the value of PWS information to reflect that most personal weather stations are both poorly sited and poorly calibrated (I suspect they positively bias information from national observers and airport stations that might be further away from the requested position).

[Peter]

Have you just connected the two wires from the valve directly to two terminals of a particular relay ? If so then that wont work. There are two very separate circuits here and both of them need power. Firstly, the logic side of the relay (i.e. the side connected to the OSPi) needs a 5V supply but the Relay side of the board (the big green screw connectors) needs 24V to drive the valves.

The board you have looks fine. Just connect the positive side of a 24V supply to the input pin on one of the relays, then connect the NO (normally open) pin to the active wire on the valve, then connect the common wire on the valve to the ground wire from the 24V power supply. That way when the OSPi “closes” the relay switch, the relay will connect 24V across the valve.

[Peter]

Jurgen, that’s brilliant, I’ll review the points and update the documentation appropriately. Many thanks.

[Peter]

@Sturdley, any chance you can let me know your aprox location (lat/lon say one decimal place = 10 miles) and any nearby PWS that you have used in the past. I would like to log some data and check out the situation. I’ve posted elsewhere that OWM is OK for me (but then I’m in London only 5 miles from the OWM HQ). So fully understand that different locations will have different results. We cant do anything about the accuracy of OWM forecasts but we can tweak our Zimmerman algorithm a bit. In my view it is currently very sensitive to forecast rain and I’m working with the OpenSprinkler team to try and improve on this. I would like to log the data from your location and compare with a couple of other providers and see what the data can tell us.

@paravais, as I say above, OWM accuracy seems to vary significantly depending on location. I’m glad you have the local Weather Service up and running and that it seems to be meeting needs. I don’t think server resources are the problem here. It just seems that for some locations OWM doesn’t provide an accurate forecast. If you would be willing to post your approx. location also then I would be very keen to try and quantify the problem.

[Peter]

You get to choose which pin goes to which relay/zone. If you have already installed opensprinkler firmware onto the Pi then you can select a station (click the associated cog). In the settings popup, click the Advanced tab and select “GPIO” as the station type. You can now select the gpio pin that you want to toggle when this station needs to water. Make sure you then wire up that gpio pin to the corresponding relay. You may need to swap the Active High/Low setting in the Advanced options depending on your particular relay board.

[Peter]

@franzstein, so it sounds like WeeWX may be able to extend our support to netatmo which would be great news. I think you only need a very modest raspberry pi to do this, say, Pi Zero connected to your network wifi or Pi 2 if you want Ethernet connection. The Zero should have enough horsepower to run both WeeWX and a local Weather Service. You will need to specify the local Weather Service IP as either localhost or 127.0.0.1 in the weewx configuration file. The instructions are on the opensprinkler-weather github page. Let me know if you need any help.

[Peter]

Sorry if duplicate post but the forum isn’t playing nice 8)
———————————————————–
Jurgen, I am not sure why you could not install node.js on your OSPi. My only thought is that it might be an old version of raspbian on your OSPi. I am using the “stretch” version of raspbian and a compatible version of node without problem. If you enter lsb_release -a then it should print out your Operating System version (e.g. Jessie). Let me know out of interest.

Looking at you screen image, you are setting up multiple forwarding rules. Each time you run iptables it adds another rule to the list. So it looks like you create the first rule to forward to port 3000 and then add a second rule to forward to port 3001. But the first rule is still active and because it is first in the list it will always be selected. The second rule will therefore never trigger. So all information is probably being get sent to the port 3000.

If you want to start afresh then you can “flush” out any existing rules with the command sudo iptables -t nat --flush. You can then create the right forwarding rule that you want and then use iptables-save to ensure that it survives a reboot. Does that make sense ?

[Peter]

Hey Jurgen, sorry for the delay. Did you get this working ?

I would recommend following the installation instructions provided on the OpenSprinkler Weather Service github page [HERE]. This does not use nvm as it is not necessary for this installation.

If you are experiencing problems the I would suggest: 1) ensuring OSPi is on the latest Stretch release of rasbian, 2) ensuring the OSPi is up-to-date sudo apt-get update and sudo apt-get upgrade; 3) removing anything in the weather directory and re-downloading from github; 4) then try the instructions again. I have certainly had versioning issues with node before.

[Peter]

@vince6464, because of the changes by Weather Underground to their service model and API, it is no longer supported by OpenSprinkler. If you have a PWS and you would like to use that data for OS watering levels then there is a way to do that but it requires some technical knowledge and a local machine that is always on to run the service.

There is some documentation [HERE] that explains the steps to take. Scroll down to the section titled “Installing a Local Weather Service” and the section titled “Connecting a Personal Weather Station to a Local Weather Service”.

If you are up for that but need a hand then I’m happy to help with the setup.

[Peter]

Jurgen, I dont know the specifics of Synology upstart I am afraid. I think a more maintainable solution may be to host the Weather Service on your OSPi. This would take one machines out of the equation and you could then use the systemd method to keep the service running. Just a thought. Not that every time the Weather Service restarts then it takes around 24 hours for the scale to stabilize as it ideally wants to use a full 24 hours of information.

The location is not used by the Weather Service when in PWS mode to calculate watering scale. The location is however used by the App to provide the “current” weather conditions and the five-day outlook that you get when you click on the weather icon. These are two different things.

[Peter]

Jurgen, feel free to open an issue on the opensprinkler-weather github page with any feedback on the documentation. That would be very welcome.

[Peter]

To see if the data is being used then you can check if the Weather Service is publishing the same scale as is being shown in the App. Browse to the the Weather Service endpoint mentioned before (the one with the t/h/p and bt/bh/bp items) and see if that generates the same scale as is shown on the App front page. They may be slightly different as the App only updates every couple of hours.

There shouldn’t be much data stored on the NAS as there is only a few variables so it shouldn’t impact. Just so you know, you could have installed the Weather Service on the OSPi itself if you wanted. Not a big difference just wanted to make sure you knew it was an option.

[Peter]

Hmm, strange, so you should just need to replace weather.opensprinkler.com with weather_service_ip:port. You will need to enter your password in the last text field and click submit. The password is by default opendoor but you may have updated it to something else.

[Peter]

Jurgen, if you go to htto://<ospi ip>:8080/su then you should see a configuration page. On that page, you can enter the ip:port of the Synology Weather Service and then hit save. I suggest you backup the working SD card before testing the guide just in case 8). Thanks, Pete

[Peter]

@robi, if you can replicate this ( and are familiar with Chrome Browser->Menu->More Tools->Developer Tools ) then I would be very interested to see what is returned when you enter the following three lines into the Console: navigator.language, isMetric and currentCoordinates. These three variables control the units of measure displayed. I would also be interested to know if the problem occurs when just going between pages or following a browser refresh. I suspect the later but would be good to get confirmation.

I don’t doubt that having a switch might be better (particularly for those that have a unit preference not tied to their location) but still keen to get to the route cause here.

[Peter]

Jurgen, that’s great ! Let me know if the instructions are clear for setting this up and any feedback you may have.

[Peter]

Apologies if duplicated posting
——————————-
Jurgen, I have replicated your setup on my network “faking” a wifi PWS so hopefully near enough to the real thing. By doing this I found a couple of incorrect steps in my comments. I had forgotten to ask you to edit /etc/sysctl.conf in order to uncomment the line net.ipv4.ip_forward=1. I also didn’t realise the iptable command for a bridged connection is different:

sudo iptables -t nat -A PREROUTING -m physdev --physdev-in wlan0 -s <PWS IP> -p tcp --dport 80 -j DNAT --to-destination <Weather Service IP:PORT>

I have created a full instruction document for this scenario and checked it into the OpenSprinkler github [HERE].

Could I ask a favor ? Would you be willing to start afresh with the Raspberry Pi Zero and see if you can follow the instructions in the link provided. I am keen to get something written down for this use-case so that others can more easily set this up. Let me know if you find any issues.

[Peter]

The rawData={“h”:null,”p”:null,”t”:null,”raining”:0} means that the PWS is not sending data to the Weather Service successfully so we have a problem.

Can I check that when you had the PWS connected to the Pi Zero (but before the intercept) that it was sending data to Weather Underground successfully i.e. did you confirm that was the case by visiting your PWS page on Weather Underground and seeing the data update. That would confirm that the problem is with the intercept rather than any infrastructure or the Access Point software.

I assume that you managed to setup the Synology to auto-start the Weather Service otherwise you could just stop the service with a CTRL-C or a reboot of the NAS. If you did configure auto-start then at the Synology command line you could run ps -ax to list all of the running processes and look for any that show something similar to node server.js. You can the stop that process using the ID number in the first column with kill -9 ID. The you can start the process manually with npm start.

[Peter]

Jurgen, another way of seeing if the data is being received by the Weather Service is to ssh onto the Synology box and manually start the Weather Service “npm start” (you may need to kill the existing process if you have it already running) it then will print out to the console every time it receives some data from your PWS.

[Peter]

Jurgen, yeah I need to tidy up the docs a bit 8) as the current setup doesn’t really give the end-to-end process very well … on my to-do list.

But if you go back to the original “installing a Local Weather Service” page [HERE] then you should see a Step 7 that contains the test/query endpoint. To see if data is being received by the Weather Service then call the following from a browser:

http://<Weather Service IP:PORT>/weather1.py?loc=50,1&wto="h":100,"t":100,"r":100,"bh":70,"bt":59,"br":0

This mimics the call that OSPi will make when calculating watering level. You can swap out the h/t/r values with the Zimmerman percentage weightings and the bh/bt/br values for the baseline shown in the App Zimmerman config popup. The result should look something like:

&scale=20&rd=-1&tz=48&sunrise=268&sunset=1167&eip=3232235787&rawData={"h":47,"p":0,"t":54.4,"raining":0}

Where scale is the watering level.

[Peter]

Jurgen, great, assume that the PWS is talking to the WU Cloud through the Raspberry Pi successfully. So can you try the following line, note that I cant test this as I don’t have the network equivalent but 8) …

sudo iptables -t nat -A PREROUTING -p tcp -d rtupdate.wunderground.com --dport 80 -j DNAT --to-destination <Weather Service IP:PORT>

The above is for PWS that are using the Rapid Fire (real-time) interface which most are but if that doesn’t work then you may need the one below instead:

sudo iptables -t nat -A PREROUTING -p tcp -d weatherstation.wunderground.com --dport 80 -j DNAT --to-destination <Weather Service IP:PORT>

This should redirect information heading to the wunderground cloud service and send it toward the local Weather Service instead. You can then test whether the data is getting through by hitting the Weather Service endpoint from a browser to see what watering scale is being reported. It might take 5 mins for data to get into the Weather Service depending on how often your PWS provides updates.

If either of these works then you will still need to make the change persist across a reboot by following most of Step 4 using iptables-save and iptables-restore.

[Peter]

Jurgen, you might need to back a step to go forward as reversing is a bit different. Can I suggest that you first set-up the Raspberry Pi Zero W as a WiFi access point connected to your network. There is a good article explaining the setup at this link HERE. You need to scroll down that article as the bit you want starts with the ttitle “Using the Raspberry Pi as an access point to share an internet connection (bridge)”. If you manage to get that set-up then you can connect your PWS to the Raspberry Pi Access Point and your weather data should start flowing through the Raspberry Pi and out to the WU Cloud. Once that is confirmed then we can put the “intercept” logic in place.

[Peter]

Giles. two questions, 1) is there a repeatable behavior here that we can try and diagnose, and, 2) is this replicable on a browser such as Chrome as that has some tools that can help us diagnose the problem ?

[Peter]

Hey Pat, great that you have joined the dots. Yep, WeeWX can send WU format data to Weather Service so this should expand the potential support no-end. Let me know if any questions or feedback on how we can improve this functionality. Pete

[Peter]

OK, so the code base has moved a bit. Looks like you need to change “WEATHER_PROVIDER=PWS” to “WEATHER_PROVIDER=local” and add additional line “PWS=WU”. This should configure the service to accept a “local” feed in the Weather Underground format.

[Author]

Posts