[Samer]

This is a different suggestion all together. Update the device manually. Here is how:

1) Install avrdude, guide here: http://www.ladyada.net/learn/avr/setup-win.html

2) Download the following firmware (2.0.9): https://raw.githubusercontent.com/rayshobby/opensprinkler/master/OpenSprinkler%20Controller/software/osFirmwareUpdater/Firmware/OpenSprinkler_v2.0/firmware2.0.9.hex

3) In the command prompt (the last step in that guide), put the following:

cd C:Downloads

Replace “Downloads” with the path to the firmware file you downloaded in the previous step.

4) Finally, flash the OpenSprinkler hardware 2.0 with this command:

avrdude -c usbtiny -p m644 -F -U flash:w:firmware2.0.9.hex

[Samer]

The reason is the limited RAM on the device. The firmware can’t possibly keep track of all the different data storage methods of previous firmwares and convert them on update.

That’s why I’m handling it in the UI. I admit the process of using the updater to do this (grab config, flash, and upload back config formatted for the new firmware) is a good technique and something to explore.

[Samer]

Although unreleased at this point, I have updated my apps to do one of two things moving forward:

If you are using a device with file support (currently only desktop), you will have an export to file and import file options now. This is essentially a traditional backup/restore method.

If file support isn’t detected, a new import option has been added allowing a paste of the export email.

In addition to either of these methods, the previous method of using the app’s storage still exists and works.

Hopefully this will help the process!

[Samer]

@cpaine The IP in the screenshot is random and not meant to be used as is. Neither is “os_ip” and the document does say to replace these with your OpenSprinkler IP.

Basically, you need to add “/su” after the device IP.

Opening the device address on my home network just gets the OS user interface; but there is no option there to change the Javascript URL (or if there is, I haven’t found it).

Just add, /su, after the address in the browser to get to the page described.

Update: If you are using 2.0.0 than the SD card is not supported. This method is only supported on firmware 2.0.3+.

Update 2: The guide has been updated to reflect this.

[Samer]

I am able to reproduce this and apologize for the bug!

I have fixed it and it’ll make it’s way into the next version of the app.

For the web interface (using http://os_ip), I have already pushed the fix so a refresh should resolve the issue.

Thank you for the report!

[Samer]

Yes, please. The edit programs page is undergoing work. Technically it should work fine but I would hate for something to go awry. I will have a stable with the OS X bug fixed soon.

Thanks!

[Samer]

Here is an updated app with the above linked fix: http://s000.tinyupload.com/download.php?file_id=08968129098027616232&t=0896812909802761623261415

Hopefully this works. Sorry I am unable to test. For some reason it works no matter what I do on my Mac.

Again, thanks for the testing!

[Samer]

This is important because due to a bug in WebKit, if you don’t store your LocalStorage WebView files in the same directory as the tracker database, they are deleted every other time you run your application.

Source: https://stackoverflow.com/questions/8198453/local-storage-in-webview-is-not-persistent

I will get this fixed now, thanks for the testing!

[Samer]

@TechFan wrote:

Sure, I’ll test it from home if you update the download.

Okay, I have uploaded it here: http://s000.tinyupload.com/download.php?file_id=35951665401476349232&t=3595166540147634923285318.

By the way, a lot of things are broken in this version (lots of ongoing changes). So please don’t worry about bugs I just want to know if the persistence issue is fixed for OS X settings.

Thanks again!

Update: Sorry for the 10MB download size, I need to remake the DMG at some point.

[Samer]

Looks like the default quota is 0 bytes for storage and I need to formally request it to be expanded. I have done this now and will update the next app. Before I do, would you be willing to test again if I update the download link?

Thanks

By the way: Apple just approved the updated OS X app (current: 1.2.0).

[Samer]

I think your asking two separate questions at the same time.

You discuss rain delay and what seems like a timezone issue but then you ask if rain sensor detects the reverse state.

First, based on what you said, there is a timezone issue setting the rain delay. I’ll check it out (this is also causing TechFan to see the wrong day in preview page after a certain hour).

Second, yes the rain sensor clears after rain sensor swells down an resets. Be sure you’ve set the correct method the sensor uses (normally closed vs normally open).

[Samer]

Thank you for the detailed information. I will use this to debug the issue.

[Samer]

Ah okay thanks. That is very odd that it is intermittent but I will take another look at this.

[Samer]

We will have to wait for the app to update on the store because the DMG seems to work according to a few users. Maybe being an App Store app will fix it.

I guess Apple review people are too busy to do their job…

By the way: What do you mean 1.2.0 (6), specifically the (6)?

[Samer]

Well, daily email isn’t ideal for logs IMO at least not in the data format it’s being exported in right now.

I’m suggesting a server script because you mentioned earlier you want them to sys log or other logging method. By using a crontab script, you can generate the days time stamp and request the corresponding text file using wget.

[Samer]

It is within the firmware. But you can also make a script to run on a server and pull the text files daily off the opensprinkler.

[Samer]

I have updated UI-old.zip to use local images instead of the one’s on rayshobby.net.

If you have any other issues, please let me know.

[Samer]

@Oasiz37 wrote:

I’ve just noticed that all scripts still refer to remote images (as in http://rayshobby.net/images/icons/svc_*) and not the local files. I assumed the local distribution should contain the entire fileset and should not have any dependency on Internet-located files. It’s not a big deal, but are there plans to have _all_ files, including icons, in the local package?

Thank you!

Well, this is the old UI so their are no plans but I will fix this for you and update the ZIP soon.

[Samer]

Everything being done here is to accomplish per-station watering time.

If you want, you can set every station to use the same time, of course.

This thread is simply to discuss options of reducing the storage requirement of the watering time. In order to accomplish this successfully, we need to assess the needs of the users.

The reasoning behind this is simple: right now we have a single value per program representing the watering time for all stations but to add per-station watering we need to have a value for each station. If people have 400 stations (exaggerated to make a point) for example, then one program alone will exhaust the EEPROM capacity.

The end result of all of this will be: added feature of per-station watering inside programs. The tradeoff of reducing from 2 bytes to 1 byte for watering time is the granularity (or the maximum watering time if you stay with seconds).

Right now, the current maximum is 18 hours (@iDoug, it doesn’t even do a full day as it is right now). The proposed change limits the maximum to 7 hours and changes the granularity to the highest unit used.

Hope this makes sense!

[Samer]

The about screen of my UI will tell you the version (which means you can find the about page contents in main.js if you want to dig in code).

The old UI won’t but it is for version 2.0.7. It should work with previous versions as well.

[Samer]

@iDoug wrote:

I give up. Do whatever way you want.

I need a minimum of a 1 minute and a maximum of 1 day duration for the next 15 years.

That is accounted for in option 3 that Ray suggested.

Also, this won’t be used for the logging output. The controller will still log with a granularity of a single second and report exact usage.

Update: Actually he has a maximum of 7 hours right now. Are you saying you need a station open for 1 whole day? If so, the interval option is available to re-run the program as often as needed to accomplish the end watering goal.

[Samer]

@TechFan wrote:

Maybe you can at least note in the guide that it will point to the latest.

Good idea and the guide has been updated to support 2.0.7 and below.

[Samer]

@iDoug wrote:

Every coder is going to understand that “water time” is different from “time” or “datetime”?
Every coder is going to know how to convert “water time” to/from “time” or “datetime”, and be able to do the math?

First of all, using datetime (timestamp) makes no sense for a duration field. I am not sure what you mean about converting a duration to datetime.

Are you suggesting we give users a start date and end date for each station?

The proposed solution depends on people understanding the value so answering your question, yes, they cannot just use it assuming it represents a value such as seconds.

@iDoug wrote:

No user will ever want more than 63 units?

The point of this thread is to weed out what user’s need in terms of water time.

@iDoug wrote:

I am still of the belief, if the function for storing the time accepted a standard time data type, none of this would be an issue.

Although I understand what you are saying here this is deceiving to the end user. If we just accept and send a duration value from the UI side without trying to understand what the firmware is doing then you will run into situations where the user’s set value is not valid, such as 1 hour and 30 minutes (since the controller is rounding to the highest selected unit).

Also, the idea is to save space not use more. We are discussing fitting the watering time per station to one byte to allow more programs on the controller, especially for a user with many stations.

[Samer]

Yes it will be. I can add the version to the suffix but I would have to update the guide each time (or use -latest).

[Samer]

@ray wrote:

Another question: since ‘seconds’ is not very common, do people care about the accuracy of 1 second, or would 5 seconds suffice?

If we do units + value do we need to further compress seconds? I’m just curious.

If we did non-linear my plan was to show “seconds” and after 59 (at 60) switch the value to 1 min and change the lable for units to “minutes” and keep moving up as we increase. Same thing as we decrease the value.

[Author]

Posts