[Denis]

I’m looking to move to either the RPi or BBB version in the near future, after finding the low-level management of memory and TCP/IP stack on the microcontroller version a bit beyond me.

Whilst the OS-Pi customer base is likely much larger, that forum is where the development of the interval program which runs on both the RPi and BBB is based, so I’m guessing this is taking activity away from the OS-Bo forum too.

I was going to go for the RPi B+ version, simply because my OCD-tendencies were having trouble with the untidy angle that OS-Bo 1.1 sits at, but I’ve decided I need to get over it and decide objectively. In my defence, it will be mounted in a transparent outer enclosure with the cover off, and I will be using a longish USB WiFi adapter that would stick out at a funny angle across the inside of the enclosure.

I’m now leaning toward the OS-Bo, as the additional UARTs will come in useful for my intended application. Ultimately I will be using parts of both the P8 and P9 headers, but I’m having difficulty working out from the pictures in the manual if they are all physically available.

Can someone tell me if a using a USB WiFi adapter obstructs the OS-Bo 1.1 P8 breakout at all, or is there adequate clearance to be able to solder in and use pin headers?

[Denis]

@salbahra; thanks, I missed the firmware appending the “1”.

Have changed /weather1 back to /weather (from the original /scripts/weather) and all is good still pointing to weather.opensprinkler.com 🙂

[Denis]

Has the server shenanigans resulted in the URL to the weather python script being changed? It now appears to be absent from http:/www.rayshobby.net/scripts/weather.py .

I think I have found it at http://weather.opensprinkler.com/weather1.py , so commented out the former and uncommented the latter URL in defines.h, and modified /scripts/weather to /weather1 in weather.ino, but it still does not seem to update the timezone, sunrise and sunset data.

I must be missing something still. Yes, I’ve been resetting it this time…

[Denis]

PWS timezone, sunset and sunrise all good now; thanks for sorting that out 🙂

I imagine the external Python script means we no longer have the option of hosting all the files on the SD card?

I was hoping to incorporate wind data and make slight UI modifications for a pool monitor and controller…

[Denis]

Yeah, you’re right; after a full-reset, “Adelaide, Australia” works correctly. I’ve discovered a few quirks though, mostly surrounding the weather APIs, but also with the v2.1.0-b UI.

I think a summary of what I did was; try PWS-fail, try local town location (green lookup)-fail, set time-zone using buttons during startup, try various other location settings-ongoing fail.

Despite lots of rebooting I have only just tried a full-reset. I’m guessing setting the timezone using the buttons during startup hard-codes them, resulting in continued failure to correctly set sunrise/sunset even if the correct data was returned.

So why did the PWS and local towns fail? I’ve been digging around within weather1.py from the repo to determine the source of data, and found the API responses to be quite inconsistent in various situations.

For a start, the PWS data returned by wunderground and openweathermap is from a completely different country! Check the responses for a PWS in my neighborhood:
http://api.wunderground.com/api/YOURAPIKEYHERE/current/conditions/q/pws:ISOUTHAU107.json
http://api.openweathermap.org/data/2.5/weather?q=pws:ISOUTHAU107

I don’t really understand weather1.py, but it looks like it is getting the sunrise/sunset data from openweathermap.

Another quirk is that “Aldgate, Australia” gives a green lookup in the UI, but the wunderground API returns an error:
http://api.wunderground.com/api/YOURAPIKEYHERE/current/conditions/q/Aldgate,%20Austalia.json
The openweathermap response looks reasonable:
http://api.openweathermap.org/data/2.5/weather?q=Aldgate,%20Australia

Choosing “Adelaide, Australia” gives a consistent response across the APIs and UI, but unfortunately the temperature and rainfall is significantly different from where I live.

So I guess I’ve discovered an edge-case. I’ll keep tinkering with it, but my level of understanding of the code is fairly limited at the moment.

[Denis]

I’ve tried both “Adelaide, Australia” (which turn’s green upon lookup), and “pws:ISOUTHAU107”.

Both give appropriate current and forecast weather, neither result in any change to time zone or sunrise/sunset settings.

Thanks for looking into it…

[Denis]

Hi; I was happy to see the introduction of automatic determination of sunrise/sunset times with a view to eventually have them triggering programs, but unfortunately this feature is not working for me. Neither is automatic time zone setting.

Specifically, neither time zone nor sunset/sunrise is correctly set whether I select a large city or a PWS location, or if I enter an API key or not.

I was able to enter the time zone manually pressing B3 as the OpenSprinker started, but the sunrise/sunset times are still wrong. I think they may still be the timings for Boston, offset by my time zone versus theirs. NTP sync itself is working OK.

Here’s a clue; I’m in the southern hemisphere. I’ve had issues with other software not accepting negative latitudes before. An unsigned variable somewhere in the works?

Other than the above, the new UI and features are a great step forward, thanks heaps for all your work on this 🙂

PS; can someone explain the arrangements for GitHub going forward please? I like to compile and upload manually (using Arduino IDE in Win7), which is working fine. I note the source for the beta is in a separate repo, but I’m still having to link back to Ray’s main repo for the Arduino IDE Hardware files.

[Author]

Posts