- This topic has 15 replies, 5 voices, and was last updated 9 years, 3 months ago by
.
-
Posts
-
Hi,
my name is Arnd and today I received my open sprinkler controller (after sitting in German customs for 2 weeks), which is a big improvement over my 10+ year old Gardena controller, so I am quite happy about it.
Everything seems so be working just fine except for two minor things:
When I go to the options dialog and I try to save the modified options whatever I do I get the message: “Please check input and try again” (or the German equivalent).
However, it seems that all changes are saved in spite of the error message. So this is not a big problem, but still a bit irritating.The second thing I noticed is that I cannot use a wunderground weather station near to me. When I enter the “Map-picker dialog” I am able to locate a station very close to my house and select it. The entry changes correctly to “Kirrlach, Baden-Württenberg”. I save it (get the error msg, but never mind) and when I re-enter the dialog, I get “Altlussheim, Baden-Württemberg”, maybe 10km away. Are there some limitations in wunderground which prevent a higher accuracy with the free service?
Any help appreciated!
Arnd.Hi Arnd,
Regarding the error message you are seeing, which OpenSprinkler are you using and also which firmware?
The way the location works in the app is the GPS coordinates are saved (and not the weather station name). This means you can put a point anywhere you want, including your home address. Weather Underground will resolve the coordinates to the closest weather station (and if it matches the coordinates of the saved station there will be no ambiguity).
The app shows the location by asking Google to geolocate the coordinates. I use Google because the location names provided by Weather Underground are variable and seem user generated.
Thank you,
SamerHi Samer,
thanks for your fast reply!
Sorry I didn´t mention the details in my previous post, I am using the DC Version 2.3 with Firmware 2.1.5 (2).Thanks for the clarification concerning the weather location, that makes sense.
Really a great controller! I spend the last 30 mins looking at the android app watching the stations cycle throug the programs, thats really cool.
Arnd
I admit full testing with the latest app against the DC controller was not performed and I will take a look at this right away to identify the issue.
Thank you for letting us know!
We don’t see an issue with the DC controller so it might be an option setting you have causing the issue.
Do you mind exporting your configuration and emailing it to [email protected] (I want to discourage pasting configuration’s here since they contain API keys)? This will allow me to replicate your options and hopefully the error.
Thank you!
I have sent the config to [email protected]
I have noticed one more thing concerning the options which may or maybe not related to the problem stated in this thread: When I modify the Zimmerman parameters, click on save in the parameter dialog everything is fine. But when I re-enter the parameter dialog (just after having closed it after saving) the old 100/100/100 values are still present. Even when I export my config, set the values to something different than 100/100/100 by editing the config in an editor and then re-importing the config the parameter dialog will still show 100/100/100. As the water level% display seems to have changed after importing the modified parameters I suspect that the parameter dialog is just showing the wrong values (always 100/100/100). I wonder anyone else can confirm this behaviour running firmware 2.1.5.
Arnd
I too am seeing the “Please check input and try again” message. My settings are being saved despite it. Also, my “Weather Adjustment Options” dialog has always had that reset issue. I found that I can usually get around it if after clicking “Submit” in the dialog, I immediately click the Edit Option’s back button and save my changes. YMMV
Firmware: 2.1.5(2), Hardware Version:2.3 – DC
It turns out that Firmware 2.1.5 (including minor revision 2) has a bug that causes the boost time variable (for DC controller only) to be incorrectly reported as out of range. Specifically, the firmware internally stores the variable as a byte (ranging from 0 to 250), and that times 4 is the actual boost time. When it receives changes from the app, it’s supposed to be dividing that number by 4 for internal storage, but due to the bug it’s not dividing by 4 and consequently the error detection reports it’s out of range. This has already been fixed in firmware 2.1.6 (which will be released tonight or tomorrow). For the moment, the work-around is to change the Boost Time (under Advanced section) to 60 *every time* you make a change to any option. In other words, the actual boost time will be 240ms, but due to the bug, you have to manually divide that by 4 before submitting option changes, to avoid the out of range error.
Sorry about the issue, which we discovered just today.
Ray,
I’m also seeing this after upgrading to 2.1.6 compiled from git today (I’m using the Android AP). The controller is essentially an OS AC HW2.3. Is there an easy way to debug and see what input value it’s failing on?
Ian
This isn’t a known issue for OS AC version (we are only aware of ‘error saving options’ as an issue for OS DC version running firmware 2.1.5, due to the DC Boost Time option). So can you check to make sure if yours is AC or DC?
Ray, I updated to 2.1.6 and the “Please check input and try again” bug is resolved for me. Thanks.
Firmware: 2.1.6, Hardware Version:2.3 – DC
Never mind. To externally reference const (which are implicit static), the declaration needs to be as follows:
-prog_char op_max[] PROGMEM = {
+extern prog_char op_max[] PROGMEM = {In trying to figure this out, I had left in server.cpp
extern const char *op_max;instead of
extern const char op_max[];
which seems to be deferenced differently and messed up the maximum values.
Please don´t think I am crazy but although I haven´t upgraded to 2.1.6 yet, for some reason:
– the saving error bug is gone
– there is no boost time field in the options anymore
– my problem, that changes to the zimmerman parameters could not be saved is gone as well.All I did was a restart, but I doubt that this can be the reason.
Am I crazy? What happened?[even if I am crazy I am glad everything is working now]
@Arnd: Samer updated the UI/app script to not send the DC boost time variable for firmware 2.1.5, therefore, even if you haven’t upgraded your firmware, the bug is gone.
The reason to simply not send this variable is that firmware 2.1.5 has another bug, in that it ignores the DC boost time variable and uses a fixed 250ms instead. As a result, it doesn’t make any difference to change that variable at all. These bugs have all been fixed in firmware 2.1.6.
If you are wondering what role DC boost time plays: it controls how long the boost converter is turned on before opening each valve. The boost converter itself is set to a maximum voltage of 22V, so there is no danger in exceeding that voltage. But depending on the input voltage, the time it takes to reach that voltage may vary. For example, one feature of the DC controller is that you can even use USB power to drive the sprinkler valves (yes, you can try it, and it works). But USB power is only 5V, so it takes longer to boost that to 22V compared to a 9V input. In that case you may want to suitably increase the boost time to allow the extended charging time. The other reason to have a configurable DC boost time is that there are cases you might not want to enable the boost voltage, such as someone using a 12V power supply and drive 12V solenoids — in this case there is no need to boost the voltage to 22V. You can set the boost time to 0 to achieve this.
Now I think about it, it’s probably not necessary to have this as a configurable variable, and we may as well just remove it in the future.
- You must be logged in to reply to this topic.