OpenSprinkler Firmware 2.1.0-beta (Major Upgrade!)

[Ray]

I don’t think MAC address is the problem, because first of all, MAC address is never exported and imported, second, firmware 2.0.9 and 2.1.0 use the same software defined MAC address, so it should remain the same. The only thing that may change is the Device ID, which defines the last byte of the MAC address. If you have ever changed the Device ID (default is 0), that may have affected the IP address.

If you can log on to the router’s configuration page, can you tell if the MAC address has changed before and after installing 2.1.0?

[djagerif]

Looking at a 2.0.9 backup file it seems the Device ID is backed up. If it’s actually used on an import in 2.0.10 is another story altogether…

In mine -> “devid”:1

On further investigation I think I found your problem. With a 2.0.9 Export, and when using DHCP, your config file exports your IP as ‘192.168.1.22’ and DHCP as ‘1’. I think the Import procedure in 2.0.10 is broken because when I import the backup file then I get an IP of 192.168.1.22 and DHCP set to ‘No’. The same goes for the GW IP. I did however confirm that 2.0.10 does set the Device ID to 1, in my case, so if the DHCP import setting is fixed then I am sure you won’t have any more problems.

Suggestion to Ray & Samer: When DHCP is set to ‘1’ and you export to a backup, please change the IP to ‘0.0.0.0’ and also ignore the IP when importing. Another issue I found is that the NTP IP is also not exported if changed to a user specified IP. It might all be fixed in 2.0.10 but I am just highlighting the issues found in 2.0.9 that could still be an issue in 2.0.10.

Ingo

[Samer]

Thank you for catching this issue. I have fixed it and will NOT import DHCP/IP or device ID. The idea being if you are able to import, you are obviously connected to your device and importing IP/DHCP settings will only ruin that.

This has been pushed and should be live (the app store apps will be updated today).

[djagerif]

I agree with the IP but am not entirely convinced about the device ID. When I connect OS I only want to select Import and it should restore all settings no matter what. If a DeviceID changes from 0 to 1 then it’s intended like that. Could I ask that if the Device ID changes that you also display a popup once a ‘Submit’ has been clicked. This will inform the user again that the change requires a reload before all changes will be activated AND the user still has the option to configure further changes or to reload to activate the new MAC address.

Ingo

[Samer]

I apologize, I actually do import the device ID. I can do a check if the device ID is changing and if so, notify the user after import as you suggested. I am adding this now.

Update: Discussing with Ray, no reboot will be required.

[djagerif]

DHCP Release/Renew after MAC change?

[Ray]

I think the firmware can be changed to automatically re-initialize network settings after import. This can be included in the official Firmware 2.1.0 release.

[jgrylls]

Hi Djagerif,
Thank you for your investigative work. When I import a 2.0.9 config to 2.1.0b I do end up with an address of 192.168.1.22 after a lengthy delay, and I assumed that the DHCP server had allocated it.

[jgrylls]

Today I again tried to install fw 2.1.0b in my hw 2.1 OS which has been running fw 2.0.9 successfully.
This time I used the updated app 1.2.2 to transfer the configuration from OS running 2.0.9 to OS 2.1.0b.
After the reflash the OS booted normally and quickly connected with an ip 192.168.1.65 as the pre-allocation in my router required. I then imported the configuration with app 1.2.2 and rebooted the OS to see what would happen.
This time the OS took a very long time to connect and had an ip 192.168.1.22 just like I was getting with app 1.2.1.
I include the config data from pre upgrade exported to email

{“programs”:{“nprogs”:5,”nboards”:2,”mnp”:53,”pd”:1,127,0,0,420,1439,1800,14,0],[1,127,0,0,420,1439,1800,16,0],[1,127,0,0,420,1439,2400,32,0],[1,127,0,0,420,1439,1800,64,0],[1,127,0,0,420,1439,3600,128,0},”stations”:{“snames”:[“Bore_Pump”,”Pond_Lawn”,”Mid_Lawn”,”Front_Lawn”,”House_Lawn”,”House_Trees”,”Pool_Trees”,”Shed_Lawn”,”S09″,”S10″,”S11″,”S12″,”S13″,”S14″,”S15″,”S16″],”masop”:[255,255],”ignore_rain”:[0,0],”act_relay”:[0,0],”maxlen”:16},”options”:{“fwv”:209,”tz”:86,”ntp”:1,”dhcp”:1,”ip1″:192,”ip2″:168,”ip3″:1,”ip4″:22,”gw1″:192,”gw2″:168,”gw3″:1,”gw4″:1,”hp0″:80,”hp1″:0,”ar”:0,”ext”:1,”seq”:1,”sdt”:0,”mas”:1,”mton”:1,”mtof”:-1,”urs”:0,”rso”:1,”wl”:100,”stt”:10,”ipas”:1,”devid”:0,”con”:110,”lit”:100,”dim”:5,”rlp”:0,”ntp1″:204,”ntp2″:9,”ntp3″:54,”ntp4″:119,”reset”:0,”dexp”:1,”mexp”:5},”status”:[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”settings”:{“devt”:1412071958,”nbrd”:2,”en”:1,”rd”:0,”rs”:0,”mm”:0,”rdst”:0,”loc”:”Coolalinga,”,”sbits”:[0,0,0],”ps”:0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0,”lrun”:[0,0,0,0],”rodur”:[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}}

And post upgrade ie imported previous 2.0.9 config into 2.1.0b and then exported to email

{“programs”:{“nprogs”:5,”nboards”:2,”mnp”:14,”mnst”:4,”pnsize”:12,”pd”:1,127,0,[0,0,1439,0],[0,1800,1800,1800,0,0,0,0,0,0,0,0,0,0,0,0],”Program 1″],[1,127,0,[0,0,1439,0],[0,0,0,0,1800,0,0,0,0,0,0,0,0,0,0,0],”Program 2″],[1,127,0,[0,0,1439,0],[0,0,0,0,0,2400,0,0,0,0,0,0,0,0,0,0],”Program 3″],[1,127,0,[0,0,1439,0],[0,0,0,0,0,0,1800,0,0,0,0,0,0,0,0,0],”Program 4″],[1,127,0,[0,0,1439,0],[0,0,0,0,0,0,0,3600,0,0,0,0,0,0,0,0],”Program 5″},”stations”:{“snames”:[“Bore_Pump”,”Pond_Lawn”,”Mid_Lawn”,”Front_Lawn”,”House_Lawn”,”House_Trees”,”Pool_Trees”,”Shed_Lawn”,”S09″,”S10″,”S11″,”S12″,”S13″,”S14″,”S15″,”S16″],”masop”:[255,255],”ignore_rain”:[0,0],”act_relay”:[0,0],”stn_dis”:[0,0],”maxlen”:16},”options”:{“fwv”:210,”tz”:86,”ntp”:1,”dhcp”:0,”ip1″:192,”ip2″:168,”ip3″:1,”ip4″:22,”gw1″:192,”gw2″:168,”gw3″:1,”gw4″:1,”hp0″:80,”hp1″:0,”ar”:0,”ext”:1,”seq”:1,”sdt”:0,”mas”:1,”mton”:1,”mtof”:-1,”urs”:0,”rso”:1,”wl”:100,”den”:1,”ipas&quo t;:1,”devid”:0,”con”:110,”lit”:100,”dim”:5,”rlp”:0,”uwt”:0,”ntp1″:204,”ntp2″:9,”ntp3″:54,”ntp4″:119,”reset”:0,”dexp”:0,”mexp”:5},”status”:[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”settings”:{“devt”:1412078038,”nbrd”:2,”en”:1,”rd”:0,”rs”:0,”rdst”:0,”loc”:”Coolalinga,”,”wtkey”:””,”sunrise”:400,”sunset”:1106,”sbits”:[0,0,0],”ps”:0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,”lrun”:[0,0,0,0]}}

Hoping this will be helpful

Regards
John

[Samer]

Yes I see the issue. I’ll get it fixed and let you know when it’s resolved.

Thanks for the detail!

[Samer]

Okay this is finally fixed. The issue was the key lookup during import for DHCP settings. Because your DHCP setting wasn’t properly being imported the OpenSprinkler switched to it’s default static IP.

The mobile apps will be updated soon however the direct access UI has now been updated with this fix.

Thanks!

[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.

[Ray]

What’s your location string? Have you clicked on ‘Lookup’ to see if it’s recognized by Wunderground? The auto timezone setting hasn’t been tested comprehensively for international cities. If you specify your location string we can help you check what the issue is.

Regarding source code: the main repo is for official release, so 2.1.0 hasn’t been checked in yet because it’s not officially released. The separate repo is for maintaining intermediate changes, for example, the current 2.1.0-beta code is there. To compile 2.1.0-beta in Arduino, just grab the hardware profiles from the main repo, and use the 2.1.0-beta code from the development repo.

[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…

[Ray]

I just tried ‘Adelaide, Australia’ and it works fine: the firmware is able to find out it’s UTC+9:30 time zone, and the device time is shown correctly. Note that after you set the time zone, there will be up to 15 seconds delay before the updates are shown in the UI. Also make sure your OpenSprinkler is connected to a router that can reach the Internet, for the obvious reason that it needs to get data from the Internet.

If it still doesn’t work, you can manually try the url below:
http://rayshobby.net/scripts/weather.py?loc=Adelaide,Australia

This is the script that the firmware uses to calculate timezone, sunrise and sunset time (and also water percentage if a WUnderground API key is provided). My output currently contains the following:
tz=86&sunrise=347&sunset=1101

[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.

[Ray]

OK, I figured out the issue with using PWS: apparently the WUnderground geolookup api returns a variable named ‘tz_long’ instead of the normal ‘tz’ (which is what autocomplete usually returns). I changed the scripts accordingly, and it should now work with PWS as well. When using PWS, make sure you also provide a valid API key, otherwise the query will 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.

I don’t think this is true: the timezone variable is never hard-coded: as soon as the script query returns valid result, it will overwrite the existing timezone variable. So setting the timezone upon startup should not matter.

[Barry]

Any news on the iOS and Mac app updates? Nothing has shown up in either App Store yet. Thanks.

[Samer]

OS X app has been updated. The iOS app is still pending review.

[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…

[Ray]

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

The weather script is a server-side script (written in Python), so it has to run on a server that can interpret Python. The microcontroller is not powerful enough to do so. Therefore you can’t host the Python script on the SD card. This is different from Javascripts which are client-side.

You can still host the Python script somewhere else, like on your own server, and modify it as you like.

[vinny]

I just installed it all (the firmware updater crashes in Yosemite MacOSX)
I’ll include the crash log below.

I switched to a mac with a released version of the os and could update. I tried to change the ntp server, and the UI looked like just hanged after hitting submit (not a big deal)

Here is the crash log, it seems from looking at the QT forums that the icu library that qt was compiled with is the issue.

Process: osFWUpdater [518]
Path: /Users/USER/Downloads/*/osFWUpdater.app/Contents/MacOS/osFWUpdater
Identifier: com.yourcompany.osFWUpdater
Version: ???
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: osFWUpdater [518]
User ID: 501

Date/Time: 2014-10-05 10:28:47.007 -0700
OS Version: Mac OS X 10.10 (14A382)
Report Version: 11
Anonymous UUID: E96F7C5A-9C40-980D-7A00-8E3D4694E836

Time Awake Since Boot: 5600 seconds

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000040dedeadbec0

VM Regions Near 0x40dedeadbec0:
MALLOC_SMALL 000000010d800000-000000010e000000 [ 8192K] rw-/rwx SM=PRV
–>
MALLOC_NANO 0000600000000000-0000600000200000 [ 2048K] rw-/rwx SM=COW

Application Specific Information:
objc_msgSend() selector name: length

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x00007fff8425c0dd objc_msgSend + 29
1 QtSerialPort 0x0000000101080e86 0x101074000 + 52870
2 QtSerialPort 0x000000010107fe23 QSerialPortInfo::availablePorts() + 387
[remaining text clipped]

[Ray]

I just installed it all (the firmware updater crashes in Yosemite MacOSX)

Since Yosemite isn’t officially released yet, I haven’t upgraded and so can’t test yet. But you are right that the QtSerialPort library has a known bug that’s likely the cause of the crash.

(by the way, the crash report is a bit too long so I clipped your message. Sorry about that).

[vinny]

@ray wrote:

I just installed it all (the firmware updater crashes in Yosemite MacOSX)

Since Yosemite isn’t officially released yet, I haven’t upgraded and so can’t test yet. But you are right that the QtSerialPort library has a known bug that’s likely the cause of the crash.

(by the way, the crash report is a bit too long so I clipped your message. Sorry about that).

No problem, how about updating the NTP server?? also on the UI when i go to logs it just presents the spinning indicator. I don’t have a sd card in my OS, so i don’t expect to see any logs.

[Ray]

If you don’t have SD card, the log will be empty. Will check the issue about spinning icon, but there won’t be any log data if you don’t provide a SD card.

Which NTP IP did you change it to? I tried a different one and it seems to work fine, I didn’t see the UI hanging. One possibility is that if you changed NTP server to one that’s invalid or inaccessible, the controller may be trying to reach that server and eventually timeout. Meanwhile the UI may freeze until the controller times out.

[Author]

Posts