Forum Replies Created
-
Posts
-
@catalin Do you have the Raspberry Pi version or the microcontroller version (the one with the LCD)? If you reboot the device, does the adjustments occur?
We found a possible issue which we are resolving in 2.1.6 regarding the DNS resolution of the weather service. The DNS reply was being cached by the firmware indefinitely and because we use Amazon Elastic Beanstalk we are behind a load balancer and the IPs are liable to change.
A reboot of the controller is updating the DNS entry however this is only temporary fix. In firmware 2.1.5, we added a feature to reboot the microcontroller version because at that time we did not understand the underlying issue but knew a reboot fixed it, hence why I am asking. We are not rebooting the Pi as it may be doing other functions which we do not want to interrupt.
We now believe we understand the issue completely and will be offering a fix in 2.1.6.
Hosting the UI files off the SD card is no longer supported in the newest firmware and moving forward will no longer be supported.
You are welcome to host the files on your local network or elsewhere but we don’t believe there is a need for this feature in the Unified firmware.
Thank you for your understanding
You need to be using the Unified firmware. More details here: https://opensprinkler.freshdesk.com/support/solutions/articles/5000524845-initial-configuration-of-raspberry-pi
That is awesome, thank you for sharing!
Might have to buy a Pebble just to try this. Very cool!
Update: Curiously, Is this written in Pebble.JS or using C?
To clarify on Ray’s comment about hosting the weather service, this is something we will be supporting in 2.1.6 but currently is not supported.
When 2.1.6 is out, you will have a field to input your weather script URL and we will also provide documentation on setting up the weather service.
Thanks!
I just grabbed the App Store version of 1.4.6 on iOS 8.4 and cannot reproduce the issue.
With that said, this is a known bug on Android and really can affect any platform so I will see what I can do to figure this out. It’s related to how jQuery Mobile initializes.
That is absolutely correct and I have updated my post above to reflect that now.
Yes a git pull is what you do to update however we have plans to streamline the update process for Pi and Beagle users. Another user suggested allowing the app to trigger a hook in the firmware to just update. This is very doable and should be added soon.
Thanks!
Apple is being quite slow about the whole process and delaying us because they couldn’t access the demo for testing. They have been testing this for many versions now with the same instructions so not sure what changed.
I will contact them today to see what can be done to expedite this.
Thanks!
Scott no the ET calculations are not yet incorporated into the firmware/weather service as we are still working this out. I like the work you have done with OSPi and will definitely look over that to incorporate some of the things you have done. I admit time has been an issue and not enough work has gone into ET based adjustment at this point to give a meaningful ETA on when it will be out. This is key to getting WaterSense certification so we do have a motivation to get this done and are trying to as soon as possible.
Thank you!
Ah, you did the export to internal storage. Unfortunately, there is no easy way to copy that out of the storage. This was one of the first methods of backing up and remains supported for the early adopters however its the least reliable means of backing up (in my opinion).
Was it only the duration that was incorrect or were other problems also present from the import?
Although your first screenshot does help expose the issue it doesn’t tell us the cause. The problem is you selected “Computed” instead of rules which will show us what rules are influencing the final or computed style. Can you tell me which element was selected to show that difference in screenshot 1? You can use screenshot 3 as a reference if that helps. If the element under rules doesn’t show the difference you will have to traverse the tree upward until you find the rule difference.
Hopefully that exposes the issue otherwise is it possible to let connect to your device with a temporarily different password? If so, you can email me the information and we can proceed from there in order to allow me to see the issue and possibly fix it.
Thanks!
This seems like a bug importing from Dans program to the Unified program. If you don’t mind emailing me the backup that failed I can see what I can do about fixing it. My email is [email protected].
Thank you!
I just tried on Safari and Firefox without this issue. I suspect you might have a plugin that is modifying CSS on the page. You would be surprised how many plugins do this (including ad blockers). I would try a fresh instance of the browser to rule out those kinds of issues. Seeing as I cannot reproduce it I would need something more than just the parsing log from Firefox.
For example, in the web tools you will see a tab on the top right labeled “Styles”. With the div containing the text selected, you will be able to see which CSS properties are being applied to that element. Therefore, you should be able to find what is making the text white in this instance. If you can maybe find this or attach screenshots, that would be helpful. Please note the elements will inherit the properties from their parent elements if they are not explicitly defined which means you will have to traverse outward until you find the class causing the issue.
Thank you!
Regarding the first issue you posted, this is not a bug and the description is correct. To elaborate, let me first quote the same values you did:
0 to 59 seconds, in steps of seconds.
1 to 179 minutes, in steps of minutes.
3 to 16 hours, in steps of hours.The value is cumulative between all the “inputs” on the popup all converted to the units listed on each row. In other words, when we say “1 to 179 minutes” we are saying if the duration is greater than 59 seconds and less than 3 hours the granularity (or highest resolution) is minutes.
For the second issue, I have run into that issue before and have not found a great fix yet. This is a known bug.
The third thing you mentioned is not a bug. When you access the UI directly by using the IP it does not function as an “app” in that it won’t allow you to access other OpenSprinkler units you may have. I realize users now want cloud sync on the direct IP UI for the station images and will work on getting a working solution.
Update: Just to add to the first issue, the watering time has a final unit of seconds when it is scheduled. However to save space, we interpret the stored water value based on how large it is but once interpreted the time is scheduled in seconds. This is important because a value of 2 minutes can be modified into 1m 30s by using a watering scale of 75%.
Hi Richard,
The open source nature of this project is primarily to facilitate the ability for users to contribute to the project or use modified copies for their own use. However, rebranding the app and redistributing it is not an accepted use case.
Thank you for your understanding
For anyone continuing to experience the crashing, I would like to suggest updating to the beta WebView channel. To do this, you need to join the community and then switch beta on for WebView. This is all outlined at the following link: https://plus.google.com/+MattGaunt/posts/71X8tBLToLY
Please let me know if updating resolves the issue.
Thank you!
We are still adding the ability to have remote stations which is what I think you mean by master/slave feature. We expect to have this out in the next version.
Right as I said we support non-sequential stations or in other words, concurrent. You can use the demo here: http://demo.opensprinkler.com password is opendoor.
I’ll look into it but can you not just push the left and right arrows next to the field? You can also hold them for jumping quickly.
We support sequential and non-sequential stations which are modified per station by tapping the gear icon on the top right corner of each station card.
@HFTobeason – We are actually working with Weather.com’s API now to try and provide more accurate weather results. They have a new API which takes into account computer models if accurate weather data is not present with 4 km blocks. Its really exciting and one of the best parts is we will be providing this without having the user need an API key. We already have most of this complete and will announce more details once it’s all done.
