Forum Replies Created
-
Posts
-
@jnissen, the attribution to Dark Sky on the weather forecast page is correct. Dark Sky is always used to provide the forecast information. I suspect that your pws historic data from weather underground is correctly being used for watering duration. Unfortunately, attribution of historic data is not currently showing up on the System Diagnostic popup.
Franstein, I think you are using a locally hosted Weather Service right? If so then you are on a slightly newer version that hasn’t yet been put live for everybody else. So it works for you but unfortunately not yet for the majority.
PrinzEisenherz1, we are working on getting this out just need a bit of time to get everything sorted. I’ll re-post when ready.
We are getting closer 8)
errCode 10 means that the Weather Service is working but has not received sufficient weather observations from weewx to create a meaningful water scale. The Weather Service needs at least 23 hours worth of data. The syslog confirms this at 21:59:29. Note that we have reduced the amount of diagnostic output now that things are more stable with the weather service so the Observation logs aren’t produced any more. So I think it is just a matter of checking back tomorrow to see if things are up and running.
Note that every time you reboot the RPi, the weather service restarts and you need to wait another 24 hours before you start getting water levels produced. If we want to cache the weather observations in Weather Service then you can add
LOCAL_PERSISTENCE=truein the Weather Service .env file. This will cause Weather Service to write the received history to disk every 30 minutes so that when it restarts it can pick up from where it left off. You might want to set this option first and then restart the weather service. After 30 minutes, you should see a file called “observations.json” with the history of data.In weewx.conf, you need to update the server_url to reflect port 3000 rather than port 80 i.e.
server_url = http://127.0.0.1:3000/weatherstation/updateweatherstation.php. Hopefully that will fix things.PrinzEisenherz1, the post from franzstein is correct but unfortunately there is something else amiss here. The clue is that your System Diagnostic popup is showing “Powered by DarkSky”. If it were pulling data from a WU PWS then it would say “Powered by Weather Underground”.
The problem is that under certain situations – for example changing the language – the “pws” setting gets deleted and the weather service falls back to using DarkSky. The team have managed to isolate the problem and a fix is being worked on.
In the meantime, what you can do is make sure that after changing any settings via the submit button, that you then go back into the options menu and re-select the PWS in the map and then hit Submit again to store it. This should ensure that the PWS is saved. Let me know if that works in the interim.
Thanks for raising this on the forum and look out for a fix soon.
Hey Franzstien,
The line “Error: listen EADDRINUSE: address already in use 0.0.0.0:80” suggests that something else may already be using port 80. Are you running a web server on the RPi ?
You can enter
sudo netstat -tlnpuat the command line and it will produce a bunch of lines showing what ports are in use. Look for something like the following that has a “:80” in the Local Address column and shows it is being used by my apache web server:tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 576/apache2If something is already using port 80 then OS 2.1.9 allows you to set an alternative port, say 3000, and set that in both the “~/weather/.env” file and in the “/su” page of the OS3.0 like “ip_of_the_pi:3000”
Let me know if that fixes the problem or whether we need to look deeper. I will update the docs to reference that OS 2.1.9 removes the restriction on OS using port 80.
PrinzEisenherz1, did you select your specific PWS Station in the Location Map at the top of the Settings page ? It may be that the system is picking up a nearby station or getting the average for the local area. To be absolutely sure, you can Export your configuration setting and look in the file for a field called “pws”. You should see the Station Name next to that setting (e.g. “pws”: “ILONDON333”).
@Ray, I think /weather129.py might be Zimmmerman (1) and California Restriction (128).
Matthew, the “loc” parameter is short for location and in this example is latitude,longitude (i.e. 50,1 is approx London). You can change this to reflect the lat/lon of your location when testing the interface. In general usage, this api call is automated by OpenSprinkler using the location that was set in the Phone App->Edit Options->Location menu.
@skynet, unfortunately, I don’t have experience of installing WeeWX on Synology. As a wild guess I would suggest trying
pip install configob. But I fear you might get “pip: unrecognized command”!You might want to try the WeeWX google forums as I have seen some threads about Synology installations before. If you do manage to get past this obstacle then happy to help with the other steps.
@alco, can we give this 24 hours to see if it settles down ? There have been service issues posted by one of the third-party data providers that may be causing api timeouts. Bad timing but I’ve seen the log files to confirm. If you can keep an eye on the “Last Weather Call” and “Last Successful Weather Call” results then we can see if this is transitory or something more fundamental. The weather call is only made every two hours so you should see the System Diagnostics timestamps update on that cycle. Let me know how you get on.
@alco, OK, thanks for clarifying, the OP was talking about a weewx skin so I presumed you were referring to that as well.
I assume you tried hitting the local Weather Service directly to ensure the port was open and accessible, i.e.
http://192.168.1.111:8081/weather1.py?loc=50,1&wto="h":100,"t":100,"r":100,"bh":70,"bt":59,"br":0. This should result in a json response with the watering scale. If that works then the problem is upstream. Can you confirm that you have set a “location” in App i.e. you have gone into the App->Options->Location and clicked to specifiy your PWS location. Without that things wont work at the moment. Let me know and happy to help diagnose.@alco, you may be talking at cross-purposes here. I notice that you are using a customised WeeWX skin to achieve PWS integration with OS. This is a bit different to what jhaug40 is doing. I believe jhaug40 is using the built-in PWS capability of the OS Weather Service. I also hope he has managed to get that solution working 8). I suggest that you wait for someone on the other thread to respond that has knowledge of that customised skin.
Update: Just seen that you are referring to a custom WeeWX skin and not the new PWS support now built directly into the OS Weather Service. I don’t have any experience of the Skin so will leave it to others to feedback on this.
—————
@alco, which instructions did you follow? I can see that OSPi is not successfully calling the weather service. Did you test that the local Weather Service was receiving your PWS data from WeeWX ? Happy to help but I need to understand a bit more about your set-up.Note that there is a defect in the System Diagnostic page that is displaying the wrong Temp and Humidity data. The only relevant fields are the Last Weather Call and Last Successful Weather Call.
@skynet, if you go into the Synology Package Manager, you should be able to install the Git Server package. This is a bit overkill but will provide the git command line tools.
@jeffhaas, the new weather service has gone through a number of fixes/tweaks over the last few months and should be providing reasonable watering levels if correctly configured. However, some users have reported that the OpenWeatherMap data is not an accurate/reliable service for their particular location. This seems to come down to specific micro-climate conditions that OWM isn’t able to model or errors in the OWM data for a particular location.
To help us understand your situation, can you expand on “the weather adjustment wasn’t working” ? Is it that it is “stuck” on 0% or is it that the watering level changes but doesn’t reflect your particular weather conditions? It would help if you could let us know the version of App, Firmware and Hardware you are using (see the About menu item in the app), as well as, providing a screen shot of the System Diagnostic page and the Zimmerman Adjustment Options page. You can upload images using the “Attachments: Choose File” button when submitting a reply.
@skynet, it is possible to use WeeWX and a local Weather Service to connect your Netatmo PWS to OpenSprinkler.
However, most of the instructions to do this assume you are using a Raspberry Pi (see HERE for end-to-end Netatmo guide). I dont know of any equivalent end-to-end guide for a Synology specific setup. My suggestion would be to use a RPi in this situation, if you have OSPi then you can use that.
If you really want to go down the Synology route then below are some pointers but you will need to adapt them to your situation and the Synology operating system:
A) Install NodeJS on the Synology: A good guide is this LINK. Follow the instructions for Package Centre and also to test that node js works using the little “test.js” script. Dont bother setting up node to restart when the Synology boots up just yet as we can do that later
B) Install Weather Service on Synology: The instructions to install the Weather Service on a Synology are very similar to installing on a Raspberry Pi and can be found HERE. Follow steps 2-5.
C) Install WeeWX on the Synology: I haven’t seen a specific installation guide for WeeWX on a Synology NAS but you might be able to follow the generic WeeWX instructions HERE.
D) Configure WeeWX for Netatmo: The steps to register your Netatmo PWS with their cloud service and then install a Netatmo plug-in for WeeWX is provided HERE with Step 3 onward.
E) Ensure Weather Service Will Auto-Start: To ensure that the Weather Service will automatically start whenever the Synology boots then go back to the Synology video LINK and right at the end it shows an example script that needs to be created in /etc/init directory. Do this but delete the line with “setuid” and change the the reference to the “test.js” file to the “server.js” file in the Weather Service directory.
F) Test the Set-Up: Go back to the standard instructions for installing a local Weather Service HERE and follow steps 7 and 8.
@jhaug40, can you re-enable your location via the App settings map page. The App uses this location to retrieve current and future weather condition to provide the right icon on the main page of the App and also to provide a summary of future day’s weather outlook when you click on that icon. The location setting is not used to actually calculate the watering level. Your local Weather Service will override any location setting, if you have set it up to use PWS data instead. let me know if any issues persist.
@franzstein, that is fantastic and much appreciated. I will get this up along with the other instructions around setting up a local Weather Service.
@illdoitmyself, this is a known defect that is on the radar to correct. At the moment the system diagnostic page is showing current temp/humidity/… rather than the daily average numbers that are used in the watering level calculation.
@franzstein, great that you have this working! The Netatmo PWS is pretty popular and the cloud plug-in for WeewWX is definitely the simplest approach. If you have a spare moment and would be willing to post a brief set of steps that you took then I would be happy to “write it up” and add to the support page to help others.
The OS version (as opposed to OSPi) only accepts an ip/hostname in the “su” configuration popup for the weather service. It is hardcoded to port 80. You are right that the temp/humidity/precip that is shown in the System Dialog page is obtained directly from OWM rather than from the local Weather Service. We are looking to update this to show the actual values used during the water level calculation so that users can better understand the results.
@franzstein, that is a good summary. Currently OS supports OWM using forecast data for the next 24 hours as the basis for a Zimmerman calculation as the standard service. But for users that are prepared to host a local Weather Service within their own network then other options become available. Firstly, a DarkSky option is in pilot that uses the last 24 hours as the basis for the Zimmerman calc. For users with a WU compatible PWS then the local Weather Service option can use that to calculate Zimmerman based on yesterday’s temp/humidity/precip plus today’s precip. The later option is the most closely aligned to the old WU method. So you can see that there are a few options based on slightly different approaches. This is all new work as a result of the recent WU changes and is going through a bit of revision and refinement so things may evolve
To break it down a bit more. There are basically two variables here; 1) the choice of weather provider, and 2) the “window” of data used. Unfortunately nothing is simple in this world and the best option is very dependent on the user’s situation.
In terms of the weather provider, then the choice goes along the lines of: 1) the PWS in your backyard is generally the best option, 2) the next best choice would be a nearby PWS but unfortunately the change in WU api has ruled this out, 3) then we need to look at an online weather provider that best matches your local conditions i.e. either OWM and DarkSky. For some OWM will provide better results but for others DarkSky may be more representative so a bit of research is needed. The last option, 4) is to go old-school and revert to manual watering levels!
In terms of the “window” of data used i.e. historic or forecast, then that is harder to answer. The theory goes that in a perfect world using forecast weather is better as it avoids stressing the plants. To put this a different way, the forecast approach is about “giving the plants enough water to see them through an upcoming dry patch” whereas the historic approach is about “giving the plants a load of water that they have been desperate for all day”. Unfortunately, the logic breaks down a bit as data is not perfect. Unfortunately, historic data is pretty accurate whereas forecast data is prone to error. So whilst the forecast approach may be better in principle it may not be better in practice. It comes down to the sophistication of the weather provider’s algorithms and their source information.
So at the moment there are a few options available to users but the best one is probably down to individual circumstances and requires a bit of trial and error.
@baggar11, that is extremely useful information. I’ve found the cause (my bad) and pushed a fix. Hopefully available in the next release.
@Sturdley, so I have 48-hours of data (except for an annoying 6 hour internet outage) in the attached image. In each graph the thick yellow line is what OWM thinks the conditions are at that point in time. I don’t have easy access to your national provider so I have used two local Weather Underground PWS as a proxy for the actual conditions on the ground. I have also included comparable data from DarkSky as they are a leading alternative.
For temp, so far I think OWM is doing an OK job. It tracks the PWS references and does a better job than DarkSky that has some divergence in some circumstances. There is perhaps a few degrees Celsius error (this would be +/-15% on zimmerman)
For humidity, the OWM data is “choppier”, my guess is that they don’t update humidity as often as temp and that leads to some timing bias. But again OWM tracks the PWS conditions better than DarkSky. Perhaps with ~15% error in certain areas (this would be +/-15% on zimmerman).
For precipitation, the values just look wrong. They are reporting rainfall, and heavy rainfall at that, when all other services are reporting dry. I have raised this with OWM so will see what happens. I suspect that OWM are leveraging PWS data and that something has gone wrong in the mapping of PWS locations (i.e. they are pulling in some data from non-local PWS – pure speculation on my part). Not exactly confidence building.
On each chart (temp, humidity, precip), I have also shown a grey, dashed line. This is the information used by the OWM Zimmerman calculation. The grey line is the average of the next 24-hour forecast data. So you can see that over the course of the two days, OWM was predicting temp to increase over the period and humidity to decrease i.e. weather will get hotter and dryer. What is interesting is the grey line for precipitation is zero for the duration. I think this is further evidence that OWM has a “problem” in the model. I would have expected the grey line to show forecast precipitation before the yellow line showed what they think is actual rain. This is somewhat curious ! Again, I have raised this with them.
The final graph shows the Zimmerman water level calculated for the period. I forgot to update my logging software to use a Cupertino-friendly baseline so the graph values are based on London setting. So the absolute values are not representative but the shape of the curve is relevant. In essence the values look reasonable given the grey lines for the temp/humidity/precip graphs i.e. increasing the watering level as the forecast predicts hotter/dryer conditions.
This is only a couple of days worth of data and hardly conclusive. I just wanted to get something out quick. I’ll keep it running for the week and we can see how it goes.
Attachments:
@sturdley, I have just started to log Cupertino data. One initial question, can you confirm whether there was heavy rainfall overnight in Cupertino?
OWM was reporting 40mm/hour of rain around 1-3AM on the 8th June. I didnt see any reported rainfall on any of the major weather sites and neither DarkSky nor WU reported rainfall. I have included a screen capture of their report at 09:30 BST today. The fact that the same image shows humidity at just 35% suggests something wrong in the back-office. I have submitted a ticket and curious if they will respond and what they say.
Attachments:
