- This topic has 25 replies, 2 voices, and was last updated 4 years ago by
.
-
Posts
-
This shouldn’t be this confusing but here we are. I have an ancient (from when the v2.0 OS first launched) OpenSprinkler controller that has suited me fine for a number of years. I recently had some issues by trying to assign/change the port manually that caused me to have to manually reset my controller in order to access it via the browser interface once again. Since I’m starting from a clean slate I figured I’d use this opportunity to upgrade to the latest (and I believe last) firmware version to get the most out of my hardware.
I started by watching this video by Ray:
https://www.youtube.com/watch?v=oUb9A_kK_3Q
It doesn’t seem to go into too much detail about the v2.0 hardware as it appears about 80% of the video is devoted to the v2.1 hardware and/or Windows v8.1
Nevertheless it says to go to OpenSprinkler.com to download the latest update program. Apparently that no longer points to Rayshobby.net so I manually navigated to Rayshobby.net to eventually get to this link:
https://openthings.freshdesk.com/support/solutions/articles/5000832311
From there I go down to Legacy OS v2.0 update instructions. Since I have Windows 10 I proceed to Step 2 above as instructed and download “avrdude_win” and unzip it to a folder on my laptop’s desktop. At this point I’m not sure if I should proceed with Step 3, 4 & 5 from above regarding the next steps or if I should try to find the “latest OpenSprinkler Firmware Update Program” as per the video instructions. I downloaded the firmware from the “OpenSprinkler legacy firmware OS 2.0 subfolder” as instructed and now it wants me to open a terminal and manually type the instructions? I see no mention of this in the video at all.
Can someone help me to make sense of what seems like an overly complicated upgrade path? I now remember why I chose to just stay on v2.0.4 so many years ago as it was working for me needs well enough. I think the only functionality I was looking for wasn’t on v2.1.x anyway. *shrugs*
At this point I just want to cross the finish line with a little help since I feel like I’m close to being done here.
Thanks for the help and sorry for the long drawn out explanation.
The video instructions are obsolete. Since we haven’t updated the firmware updater for a few years, it no longer runs on many operating systems. Instead, just use avrdude and follow the command line instructions. (The updater is simply a GUI for the same command line instructions).
Thanks for the response. Disregard the video, got it. Moving on….
I now have a folder that inside contains another folder called “avrdude” which was named as it was unzipped and a hex file named firmware2.1.7.hex but when I try to run the command text via powershell (I hold the shift key while right clicking to run powershell from within that folder) I get an error. I took a screen grab so please see image #1 below for details. I tried the same command from within the “avrdude” folder as well with similar results and a different error. I also have a screen shot of this error which is #2 below.
Of note, when I plug my US v2.0 into my laptop’s USB port it shows it as USBtinySPI under device manager with a yellow exclamation point. I’m not sure if this is how it’s supposed to be or not. I attached an image of that as well in case it’s useful.
Attachments:
Maybe it’s called avrdude_win? You can do
dir *.exe
to find what’s the exact name of the executable.Since I’m not allowed to edit the last post: the .exe in this context is an application so ignore the previous post.
I guess I just don’t understand how to do this and much of the jargon I’m reading is going over my head. I’d like someone to please explain to me what it is I need to do at this point in as simple to understand language as possible as I clearly don’t get it.
I attempted the following command again from PowerShell:
avrdude.exe -c usbtiny -p m644 -U flash:w:firmware2.1.7.hex
I get a return of “The command avrdude.exe was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default. If you trust this command, instead type:” (at this point it basically tells me to add .\ to the beginning of the string which I do and run)
I then get an error that says “could not find USBtiny device (0x1781/0xc9f)”
Followed by: avrdude.exe done. Thank you.
So I feel like maybe I took a step forward here but one of my previous concerns mentioned in a previous post might be the culprit as far as how the laptop sees the device. As I stated previously, Hardware Manager doesn’t show USBtiny device but instead USBtinySPI with an exclamation point.
I found another thread online about a totally different device that said that if you have avrisp on the device (which I believe one of the install notes says is the case with the OS v2.0 hardware) you can substitute the “usbtiny” portion of the code with “avrisp” which I tried and I seem to get a little bit further but the error says that it can’t open the device “\\.\com1” The system cannot find the file specified.
Updated firmware shouldn’t be this difficult.
“could not find USBtiny device (0x1781/0xc9f)”
means it’s missing a driver. You can download and install the driver available here:
https://learn.adafruit.com/usbtinyisp/driversThe instructions say specifically that you don’t need to install drivers on Windows machines unless you’re on Windows XP or 7 specifically which I’m not. I’m on Windows 10. This is nearly impossible to do as someone who understands very little of what should be happening or how to do it with the instructions given. Little of it makes sense even if I follow what’s stated but it seems like half of what needs to be done isn’t even stated.
Finally, success!
For anyone else who is having issues that may find this thread, I’ll type what worked. Be warned though that this is for OS ver2.0 specifically and I upgraded from v2.0.4 to v2.1.7 and I (clearly) don’t understand this stuff well enough to say what other hardware or firmware version combinations this works on. I’m also running this from Windows 10 which also differs from Linux, MAC and even other versions of Windows from what I’ve read.
For starters, you WILL need to install the drivers before plugging in the OS USB cable. Use the link two posts above and follow the instructions. Once that’s installed plug in the USB cable and open Device Manager to assure that your machine sees the OS as USBtiny (mine was under libusb-win32 devices) and then proceed with the code mentioned in the install instructions.
I found that the best way is to download and unzip the avrdude files to a folder. Then download the firmware v2.1.7 (latest and last for OS v2.0 hardware) hex file and place this in that same folder where all of the unzipped avrdude files are located. Verify that that hex file is indeed within this folder with all of the other files before proceeding to the next step.
Now, you need to launch PowerShell which is easiest down by holding the shift key down and (while in the folder you just moved the firmware file) right click this explorer window and select “Open PowerShell window here” which will bring up a PowerShell window that is already pointed to the proper directory.
Here is the next important change that was made from the posted instructions. In the instructions it states to type in the following code (cut and paste works for all of these BTW) and run it:
avrdude.exe -c usbtiny -p m644 -U flash:w:firmware2.1.7.hex
I can tell you that that likely will not work. The problem appears to be twofold. Up first, the avrdude program/application you need to run is just named avrdude w/o the extension on the end. This may work or it may not so try it like this first:
avrdude -c usbtiny -p m644 -U flash:w:firmware2.1.7.hex
Note that the ONLY difference in that string of text is the omission of “.exe”
If that doesn’t work PowerShell will likely give you a hint on how to fix it so that it runs properly. This is to add a “.\” to the very front of the string of text which will then run the avrdude executable which will then complete all of the last steps for you automagically. You should see it erasing and writing the firmware files to the OS.
Viola! All is well and my OS v2.0 now has the most recent and final firmware created for it. Mine has been running about 8 years now and my needs are minimal so there’s no reason for me to throw this in the landfill to get the latest greatest when this meets all of my needs. I only wish the firmware update was a little more beginner friendly but I guess I never need to worry about that again now so water under the bridge I suppose.
Do I still need to forward port 123 for weather info on 2.1.7 or is this nullified by the new weather solution?
Of note, related to my previous post (which is now off-topic) the OS is showing my location incorrectly as Boston, MA and the time/date to be in the year 1970.
When I disable NTP sync and manually set my date/time & location it doesn’t appear to be saving them properly.
(also, the “Notify me of follow-up replies via email” option appears to not be working for me)
Actually, I was wrong. I went back to verify that “NTP Sync” was disabled and it wasn’t. I unchecked the box and clicked “submit” and it returns home but when I go back into advanced settings NTP Synch is enabled once again. It appears as though I’m unable to disable NTP Sync in order to manually set my time & date.
The date & time are all over the place and it doesn’t seem to matter if NTP Sync is enabled or not. I’ve managed to successfully disable NTP Sync and even when I manually set the date and time it will change itself minutes later to some random date in 1970, 1988 or something along those lines. Not only can I not set programs to run at a specific date & time but I can’t even manually run the zones now because rather than running for 15 minutes they run for only a couple of minutes before shutting off since the time changes itself and they think they’ve been running for decades.
First of all, since you said your device is OS 2.0, make sure you uploaded the correct firmware. Firmwares for hardware version 2.0 are available here:
http://raysfiles.com/os_compiled_firmware/legacy_os/v2.0/
If you are sure you used the correct firmware file, and you suspect firmware 2.1.7 is causing the NTP problem (which I am not aware), why not try to flash it back to your original firmware 2.0.4, it’s available in the folder. You can flash the controller to any version of firmware.Please, stop creating new forum posts about the same issue. This only makes it difficult for us to keep track of your questions.
I’ve tried being patient and I’m appreciative of any assistance that anyone is willing to offer me. I need to get this up and running ASAP though so that’s making weeks passing a real issue for me.
Yes, that link was the exact list of firmware I downloaded v2.1.7 from. I’d rather not downgrade back to 2.0.4 because then all of this was for nothing. I’ve invested enough time in this now I’d prefer having the most recent firmware version so that I’m never tempted to do this again.
The only reason I created a new thread is because the original problem this thread was created to solve had been resolved. Since then, several days had passed and nobody had responded to my newly discovered issue. It was a fair assumption that nobody was tracking this thread anymore and I was tired of manually refreshing it to see if there was a response. Several days had passed & I’m sure you would have decided that creating a new thread to see if someone on this forum could help me with the new problem was also the right thing to do. After all, it’s not like this forum is being hammered with so much traffic that a new thread would further soak up the bandwidth. I even linked to this original thread in case you or anyone else who was willing to help wanted to review what I did to arrive at this point. If you prefer keeping the whole process in this thread I’m fine with that but w/o any communication it’s hard to know that’s how you’d prefer handle it.
Not responding to peoples posts, deleting new posts without any notification and not addressing online support tickets isn’t what I would consider strong customer service. If someone somewhere would help me with this I wouldn’t have felt the need to create a new thread after several days had passed w/o a response. I mean, the last response to this thread other than mine was March 19th congratulating me on a completed job. Was it not sage to assume that perhaps nobody was monitoring this thread any longer?
I’ve searched and I’ve found that the RTC can be an issue on rare occasions (I verified that my OS has the proper RTC for the device/firmware) and that there were a few versions of the firmware that also had issues that match what I’m experiencing. Since it worked flawlessly for so many years prior to this firmware update I really doubt that the hardware is defective. Since the only variable was the firmware I’m assuming that this is the culprit so that’s why I’m asking for help. I could attempt to downgrade back to 2.0.4 temporarily (assuming it’s not going to be a gigantic undertaking the way upgrading to 2.1.7 was) to verify it’s still working properly but ultimately I would really like to have this device on the newest and last firmware version once and for all.
I’ve mentioned it numerous times now (without acknowledgment) but the email notification system of this website is completely broken. That’s not helping matters at all.
I have a test OS 2.0 loaded with firmware 2.1.7. I’ve run it for a couple of hours and I cannot reproduce what you said about timing issue. Look, the reason I said you should consider downgrading back to 2.0.4 is so that you can have a point of reference: if the timing issue is gone after downgrading to 2.0.4, then it says something about the difference between the two firmware. I didn’t tell you to abandon your efforts. Instead, doing so can help rule out the possibility that the RTC or RTC battery may be the root cause. I have no idea why you are so persist at not downgrading to 2.0.4 — this is for the purpose of debugging and isolating problems so we can narrow down the problem. If after downgrading to 2.0.4 you still experience the timing issue, then the problem is not in the firmware, it’s somewhere else.
Also, this is a community forum, this is not the support system. We sometimes don’t check the forum on a regular basis, understanding that this is a place for users to assist each other. Especially now I am sure you know there is a pandemic going on, we are short staffed and have many things on our plate, I don’t think you should expect any immediate response on this forum. However, if you have a technical problem that requires urgent response, send a support ticket. The reason it’s hard to provide support through forum is that we need to ask you for your order number, sometimes asking you to export your configurations, your shipping address, etc which I am sure you don’t want to post on a public forum.
Finally, I politely ask you to keep your post concise and to the point. That will help us get to the bottom of the issues quickly. Complaining about a bunch of stuff in a single post doesn’t help us understand what are the main problems or provide any motivation for others to help (especially since your purchase was from almost 7 years ago, which is way out of warranty).
I flashed v2.1.7 again just to see if I had a corrupt file in that portion of the code or something and the behavior was the same. Upon initial startup it seemed to reboot multiple times at the NTP Sync portion before settling in. Unsure if this is related but given this is the point of contention I would guess it is.
I then flashed the previous version which was v2.1.6 and it behaved the same as v2.1.7 as it pertains to the booting sequence and then randomly shuffling the date/time no matter what I do.
I then flashed v2.0.4 (downloaded from the same link as the above two firmware versions which was taken directly from the link you supplied previously) which is the firmware I was previously on. It seems as though it’s maintaining the proper date/time it pulls via NTP sync. I went into the GUI to assign the proper location and time (default is Boston and EST, I’m in MST in Colorado) and it also appears to be holding the proper date and time without issue. I was able to successfully change the port to the one I had previously and the one that doesn’t conflict with any other clients on my network. I can now access it via the app and everything seems to work properly exactly as it had previous to me attempting to upgrade to the latest firmware version. Plenty of time has passed and my date/time is rock solid and hasn’t shift to the 70’s or 80’s.
During my internet searches trying to find answers over the last couple of weeks I read that two different version of RTC were used and due to that it was important to use the proper firmware version that accounted for this. Could this have anything to do with the problem I’m experiencing?
As far as I am aware, firmware 2.1.7 handles both types of RTC that we’ve used previously:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/49f0c3dd8ce5501ae88b810412ecd5e157754aa3/DS1307RTC.cpp#L40
so I honestly can’t explain the symptom you are seeing. As I said, I have a test OS 2.0 and I don’t observe any RTC issue as you reported. If you suspect it’s the RTC, can you take a look at the RTC you have on your board and find out the part number?The RTC itself & the battery is fine because it’s keeping time perfectly now on v2.0.4 just like it was prior to me ever trying to upgrade the firmware. Even though I re-downloaded the firmware you said was for OS v2.0 just to be sure I had the proper version it appears to be a firmware issue as opposed to a hardware issue since it works fine back on v2.0.4.
Something is up with the RTC portion of the firmware in v2.1.7 as well as v2.1.6 and possibly others since those are the only other two I tested. It could also have something to do with the question I asked earlier about if I need to open up port 123 on my router for the NTP sync. I don’t believe this is the issue though unless there was a change in how the NTP Sync occurs from v2.0.4 to v2.1.7.
I am not sure why you had to open up port 123 — are you turning on firewall and blocking ports? Otherwise why do you have to open up port 123? I never had to do it and that’s not a necessary step in the setup.
Opening port 123 was something I did when I first bought this probably after reading/seeing something regarding network security or what I was running at the time. It’s carried over each time I did something with my network because it wasn’t broken so why fix it? This is why I asked earlier because I was going to remove it from my short list of open ports if it’s not required. I just wanted to make sure it wasn’t necessary but given this aspect is directly related to this issue it seemed like a good place to ask.
It seems you’re now saying that this is unnecessary though so I can safely remove it and expect it to have no effect on this situation. I already deleted it the other day and my OS v2.0 is still keeping time (it appears to be off about 10min but not jumping around by decades like newer firmware versions) on firmware v2.0.4 so any insight as to why this is the case but not on the newer updated versions?
- You must be logged in to reply to this topic.