[mcmuller]

Hi Ray,
it’s a token from TheThingsNetwork….
Greetings,
Gregor

[mcmuller]

I was affected by the same error and switched to Stefans weather server, which solved the problems! As a very welcome side effect, this server implements ETo for Wunderground just perfect! @Ray: Maybe it’s time to merge Stefans commit into your main branch?

[mcmuller]

Thanks, Samer,

I learned that my specific setup relies on a middleware, that I’ve no control of.

For reference if someone runs into the same: I use Truenas-Scale with traefik from the truecharts.org -repo as proxy and opensprinkler is set up there as external-service. Adding tc-opencors-chain as middleware didn’t do the trick and from https://github.com/truecharts/charts/issues/6004 I learned that developers are not willing to make any change there now.

…so I’m quite sure that you can’t help me out of this mess, Samer 🙂

sunny greetings from Portugal,
Gregor

[mcmuller]

Thanks Samer for pointing us to that post.

Can anyone confirm success in applying this for the recent android-client. I’ve set up my proxy as described, but still cannot connect with basicauth….

[mcmuller]

I’ve added tc-opencors-headers (aka Access-Control-Allow-Headers: * ) middleware to my traefik proxy, but still get no connection. Will look for some logs, which is a challenge in my kubernets-setup…

[mcmuller]

Hi all,

can confirm that basic auth is the problem – after disabling it, app is working as expected. For tomorrow (late in Europe now) I’ll figure out, how to tell my proxy (traefik) to add CORS-Headers as suggested. Will keep you informed.

Good night,
Gregor

[mcmuller]

Hello from Portugal,

I’ve the same problem with far too high perception numbers in OWM! It’s often around factor 10 too high!

Greetings,
Gregor

[mcmuller]

Same here! To give an idea how time-of-day dependent opensprinker Zimmerman turned after switching to OWM, please see the attached data from the last days, oscillating between 0% and 138% in a few hours:

value	acknowledged	from	timestamp
86	true	parser.0	2018-12-31T12:21:29.356Z
66	true	parser.0	2018-12-31T13:21:29.426Z
27	true	parser.0	2018-12-31T15:21:29.555Z
23	true	parser.0	2018-12-31T17:21:29.708Z
0	true	parser.0	2018-12-31T18:21:29.764Z
6	true	parser.0	2019-01-01T07:21:31.067Z
0	true	parser.0	2019-01-01T08:21:31.196Z
97	true	parser.0	2019-01-01T09:21:31.319Z
113	true	parser.0	2019-01-01T10:21:31.424Z
125	true	parser.0	2019-01-01T11:21:31.475Z
123	true	parser.0	2019-01-01T12:21:31.552Z
75	true	parser.0	2019-01-01T13:21:31.692Z
15	true	parser.0	2019-01-01T15:21:31.916Z
11	true	parser.0	2019-01-01T16:21:32.158Z
0	true	parser.0	2019-01-01T18:21:32.468Z
77	true	parser.0	2019-01-02T09:21:33.675Z
105	true	parser.0	2019-01-02T10:21:33.803Z
133	true	parser.0	2019-01-02T11:21:33.996Z
138	true	parser.0	2019-01-02T12:21:34.086Z

I’ve several systems deployed here and definately need a fix soon.

Greetings,
Gregor

[mcmuller]

…existing WUndergroud API keys expire end of 2018, as I just read on my API-page there….

[mcmuller]

Yes, same behaviour here after I switched to OpenWeatherMap: As temperatures go down at night, watering level drops dramatically.

[mcmuller]

I grab this thread for a similar idea: What if we could set a “minimum Zimmerman percentage per station”? I have diffrent types of irrigation: Plants, Lawn, Vegetables. The lawn should only be watered when Zimmerman says 80% plus, the plants should be watered at 30% plus and the veggies always.
I think of having a “year-round” setting, without the need of switching sttions on/off during seasons.

Greetings,
Gregor

[mcmuller]

@Ray Thanks, that hint was helpfull!

[mcmuller]

Hi Ray,
following your post, I wired up a cheap hal-sensor driven flowmeter with ease! Working so far, providing readings. But specs are 270 pulses per liter, which is a 0.0037 liter per pulse. Any chance you can mod upcoming release to support others than full integer in liter/pulse setup? (or pleae direct me to how modify myself). Those Flowmeters are cheap and I have demand for various installs here.

Greetings,
Gregor

[mcmuller]

Hi Ray,

thanks for your quick reply! To be honest: I didn’t realise that the global ‘station delay’ can handle up to 59 min – which suits me and my well-deposit just fine… Sorry for the fuss….

Greetings,
Gregor

[mcmuller]

Hi,
just stumbled across this post. I’ve the same problem – need recovery time for my water deposit to recover after every station. Setting up a program for each station is possible, though, is an unflexible sulution and not easy to rearange. Any suggestions?

Greetings from Portugal,
Gregor

[mcmuller]

@samer:
Thanks for your quick help! Problem was not the DNS, but a poor connection. When I tried near the access-point, I used another bridge (too lasy to rip the whole install from the wall) – and that one had a DNS-problem, so you were right.

Conclusion: Wifi has to be >= 75dbi

I solved the whole thing by daisy-chainig two PLC-networks….now it’s working like a charm!

Greetings

[mcmuller]

Hello from Portugal,

I’ve the same problem here with my install. Opensprinkler (DC version) is connected through TP-Link-Wifi and i can get/send commands just fine. But the “successfull weather call” remains empty. Although, I do get forecast in the App/Webview. Strange thing: When I connect Opensprinker directly via LAN, it receives weather-data “successfull”, so it’s got something to do with the Wifi-Link. Perhaps a tough timeout? My connection is not the strongest, but working well for UI and commands.

ADD: Just checked with Firmware-Update 2.1.5(2) – no success.
ADD2: Checked with Wireless-Bridge 1m away from Access-Point – no success (so connection strengh is not the problem.)

Greetings

[Author]

Posts