OpenSprinkler › Forums › OpenSprinkler Unified Firmware › OpenSprinkler Firmware 2.1.0-beta (Major Upgrade!)
- This topic has 81 replies, 15 voices, and was last updated 10 years, 1 month ago by TechFan.
-
AuthorPosts
-
September 28, 2014 at 6:06 am #28356
RayKeymasterI 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?
September 28, 2014 at 9:27 am #28357
djagerifParticipantLooking 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
September 28, 2014 at 4:52 pm #28358
SamerKeymasterThank 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).
September 28, 2014 at 5:20 pm #28359
djagerifParticipantI 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
September 28, 2014 at 5:35 pm #28360
SamerKeymasterI 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.
September 28, 2014 at 6:00 pm #28361
djagerifParticipantDHCP Release/Renew after MAC change?
September 28, 2014 at 6:04 pm #28362
RayKeymasterI 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.
September 29, 2014 at 1:14 am #28363
jgryllsParticipantHi 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.September 30, 2014 at 3:36 am #28364
jgryllsParticipantToday 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
JohnSeptember 30, 2014 at 4:57 am #28365
SamerKeymasterYes I see the issue. I’ll get it fixed and let you know when it’s resolved.
Thanks for the detail!
September 30, 2014 at 10:32 pm #28366
SamerKeymasterOkay 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!
October 1, 2014 at 9:33 am #28367
DenisParticipantHi; 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.
October 3, 2014 at 12:27 am #28368
RayKeymasterWhat’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.
October 4, 2014 at 5:42 am #28369
DenisParticipantI’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…
October 4, 2014 at 5:50 am #28370
RayKeymasterI 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,AustraliaThis 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=1101October 4, 2014 at 9:49 am #28371
DenisParticipantYeah, 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:ISOUTHAU107I 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,%20AustraliaChoosing “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.
October 4, 2014 at 4:22 pm #28372
RayKeymasterOK, 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.
October 4, 2014 at 6:56 pm #28373
BarryParticipantAny news on the iOS and Mac app updates? Nothing has shown up in either App Store yet. Thanks.
October 4, 2014 at 7:18 pm #28374
SamerKeymasterOS X app has been updated. The iOS app is still pending review.
October 5, 2014 at 11:00 am #28375
DenisParticipantPWS 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…
October 5, 2014 at 3:46 pm #28376
RayKeymasterI 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.
October 5, 2014 at 6:02 pm #28377
vinnyParticipantI 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: 501Date/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-8E3D4694E836Time 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 0x000040dedeadbec0VM Regions Near 0x40dedeadbec0:
MALLOC_SMALL 000000010d800000-000000010e000000 [ 8192K] rw-/rwx SM=PRV
–>
MALLOC_NANO 0000600000000000-0000600000200000 [ 2048K] rw-/rwx SM=COWApplication Specific Information:
objc_msgSend() selector name: lengthThread 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]October 5, 2014 at 6:41 pm #28378
RayKeymasterI 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).
October 5, 2014 at 6:54 pm #28379
vinnyParticipant@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.
October 5, 2014 at 7:03 pm #28380
RayKeymasterIf 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.
-
AuthorPosts
- You must be logged in to reply to this topic.
OpenSprinkler › Forums › OpenSprinkler Unified Firmware › OpenSprinkler Firmware 2.1.0-beta (Major Upgrade!)