Mathias Stöber
Forum Replies Created
-
AuthorPosts
-
Mathias Stöber
ParticipantHi,
I just tried something again. I had the entire config output via API. I first defined “Manual” as the watering method. There were no entries for the value “wto:{}” in the config that gave me the API. When I changed and saved the weather provider, the value was gone after I reopened the options and was reset to “apple” as the provider. I couldn't see any changes in the output of the config via API either. Next, I set the watering method to “ETO”. Afterwards I could also see settings under “wto:{…}” in the config from the API. When I then set the weather provider to “openmeteo”. This was in the config on the one hand
“wto”: {
“baseETo”: 0.15,
“elevation”: 262,
“key”: “”,
“provider”: “OpenMeteo”
}but then also displayed below
“wtdata”: {
“wp”: “OpenMeteo”,….}Is it possible that some options are saved in areas that are not always present in the config and there are gaps here? If I understand it correctly, the web interface is just the js file that runs on the web server, which then uses the API to actually make the changes. It seems as if there is a difference between what the interface shows, possibly as default, and what is then written to the sprinkler via API. Or if you change something in one place but then the default values are written back in another place.
If I can help in any way or test further, just let me know.
VG Mathias
Mathias Stöber
ParticipantHello,
I also have the problem that some of the options are still not saved. Sometimes they are there, but after a restart they are gone again. This means that options and settings from the analog sensor configuration are always reset. Is there a way to debug this a little better?
I have an Ospi here with a current checkout from the Github.
VG Mathias
Mathias Stöber
ParticipantSo, a small update. I reinstalled the Raspi again. This time with Bookworm instead of Trixie. After the installation, I only changed the “Adjustment Method” from “manual” to “monthly.” No other values were changed. But the error pattern described above remains. My assumption is that there is an error when saving the JSON in that area.
If I should send logs or anything else, just let me know.
VG Mathias
Mathias Stöber
ParticipantMist damit wird das Projekt doch noch mal größer als gedacht
Another question can you tell what exactly the data of the API means when calling “/jc” under “wtdata”? Are there values for “minT” and “maxT”? I didn't find anything about this in the documentation and from the values (54 and 80) it doesn't seem to be the normal min/max temperature of the day.
VG and thanks Mathias
Mathias Stöber
ParticipantHi,
Thank you! I just pulled an update and am testing it.
Is there a reason why the release numbers in Github are a little behind?
See Mathias
Mathias Stöber
ParticipantHi,
thank you for the answer. By “reading interval” I meant the point in the analog sensor configuration (see Figure 1), but in my case it is not an Mqtt topic that I receive, but the temperature of the Raspi.
Yesterday I deactivated data logging in the configuration of the sensor (also in Figure 1). This meant that the data record stopped in my InfluxDB, but the changes continued to be published in the Mqtt server (Image 2). So there must be a difference in the triggers, at least for the analog sensors. Because the change in the water level was logged in the Influxdb at the same time.VG Mathias
-
This reply was modified 1 year, 3 months ago by
Mathias Stöber.
Attachments:
You must be logged in to view attached files.Mathias Stöber
ParticipantHi,
I watched it again, the amount of rain was sometimes a day late. Today I also saw the following, see screenshots. At the top of the main view it says 27 degrees, but in the system info it's only 21 below max. The latter is more like yesterday's value.
Attachments:
You must be logged in to view attached files.Mathias Stöber
ParticipantI think that's normal, it went away for me after a few hours.
See Mathias
Mathias Stöber
ParticipantHehe,
Not only do we have almost the same name but also the same location? For me it's 7.9 too. Do you happen to also have the weather station for the Braunschweig region?
See Mathias
Mathias Stöber
ParticipantHi,
Something is strange today. I use the dwd service, see above, but even though not a drop of rain fell here today, the ospi says it doesn't need to water because more than 7mm of rain would have fallen. The dwd app doesn't show any precipitation for today either. There may have been a problem yesterday because he drove the sprinkler at 120% in the heaviest rain.
I use eto as a method, it has worked wonderfully since the posts above. It almost looks like the data is shifted by a day.
Thank you very much in advance!
See Mathias
Mathias Stöber
ParticipantHi,
Thank you for the hint. Since it is an OSPI, I have firmware 2.1.9(9), as far as I know there is no newer version. I may have to configure the systemd service a little differently so that it waits until the network is actually up.
Otherwise the query is definitely more accurate than before!
Thank you for that!
Mathias
Mathias Stöber
ParticipantHi,
Short update from me. Yesterday I changed everything back to the default so that the automatic irrigation system would work this morning. This morning I tried again, first with the same result as described above. But after about 6 hours or more, the error message disappeared and the app only displayed the message as described in the blog post and weather data was displayed again. I'll keep doing it this way now.
If necessary, it would be good to have a note in the blog that the first update can take several hours.
Thank you again!
See Mathias
-
This reply was modified 1 year, 3 months ago by
-
AuthorPosts
