Forum Replies Created
-
Posts
-
Because it’s undesirable to store and use plaintext password. Worse than a stolen MD5 hashed password would be if the attacker obtains your plaintext password and can log in to your other accounts. It’s not possible to recover your plaintext password from its MD5 hash. This is similar to how Linux stores user passwords — it never stores the plaintext password, it only stores a hashed version, so if someone obtains the hash, at least they won’t be able to get the plaintext password and use it to log into your other accounts.
Correct, it’s currently for display only. You can use it to manually check if there is any broken lines, for example, if the current is too low when a zone is on, that generally indicates the solenoid is not activated.
There is no plan yet to use the current sensor for triggering any actions, although similar to the Flow Alert, it’s fairly easy to implement a current sensor alert. Note that often when there is a shorted circuit, it would result in a tripped fuse, or the power supply voltage collapsing triggering an immediate reboot — there won’t be enough time for the current sensor to even read a reliable value.
The firmware always resets the watering level to 100% before sending out a weather query so it shouldn’t get stuck in 0% — usually if it’s stuck at 0%, it’s because the weather algorithm returned 0% to the firmware.
One example of how ETo will return 0% is if there is significant precipitation. The formula of ETo is explained in our support article:
https://openthings.freshdesk.com/support/solutions/articles/5000823370-use-weather-adjustments
as you can see if there is significant precipitation it can cause ETo to become 0%.The OSPi board does not have a built-in microcontroller so the test code is not in the firmware since the firmware will have to run on a RPi. We have a dedicated OSPi tester, which is based on a ATmega microcontroller. It runs basic testing code including testing each zone, button, and LCD etc.
The current firmware is Y2038 compliant, but not Y2106 compliant — it represents time using unsigned long, which means it will overflow in the year 2106, but it will work just fine through 22038.
It’s probably ok. The entire 5V rail can supply up to 2 amp. OpenSprinkler’s ESP8266 draws about 100 to 150 mA (if you use wired Ethernet module, that’s another 180mA). So it can easily support another gadget that needs 200mA. Keep in mind that all this power eventually come from the external 24VAC power adapter (if using AC) or 7.5VDC power adapter (if using DC), so if you also want to run many zones simultaneously then it’s going to strain the external power adapter. But if you don’t run more than 1 or 2 zones at the same time, it should be ok.
Please check the user manual:
https://openthings.freshdesk.com/support/solutions/articles/5000716364-opensprinkler-user-manualsYou may want to consider installing a per-zone fuse. Using one single fuse for the whole controller makes it difficult to choose the correct fuse rating. Because some of the customers run multiple zones at the same time, which draws a lot of current, it’s very difficult for one single fuse to distinguish between whether the current surge is due to turning on multiple zones at the same time, or one solenoid is shorted. To solve the problem you can install a small fuse (like 0.5A or 1A) inline on each zone wire, that way, if a particular zone is shorted that should trip the fuse quickly and correctly.
That’s what the ‘Remote Station’ feature is for: use one OpenSprinkler as a master controller, and another one as remote controller. Just one expander cannot be a remote controller, because the expander is a passive device that does not have a microcontroller in it. But you can buy another main controller and use that as a remote controller.
The per-zone flow data will only be non-zero if the zone runs for at least 2 minutes and half minutes or more. This is because the logic to compute a reliable flow rate for each zone requires that much running time to stabilize the reading.
I see, I figured out the link issue: it should be https://raysfiles.com/.. NOT http (i.e. secure vs. non-secure). It has been fixed now. Please try again.
Are you using static IP assignment on OpenSprinkler? If so, yes that will be erased so it goes back to DHCP mode. You can always click button B1 to find the IP address it’s assigned by the router. In fact, we always recommend not changing DHCP settings on OpenSprinkler, instead, use the router’s DHCP reservation to reserve a fixed IP, that’s a much better way to manage fixed IP.
After you upgrade the firmware, and find out the IP address, then you can still go to:
http://os_ip/su
to change the UI link to your local server. You should probably update the content on your local server too, as new firmwares generally have new features that require matching UI files. If you don’t upgrade the content on your local server, some of the new features won’t be visible.The link is not broken. Try to use a private browsing window or clear your browse cache. It may be that your browser has cached an old and outdated link.
The firmware update instructions say specifically to save a copy of your configurations so you can import them after the firmware upgrade, to restore settings.
I’m not sure about static content from your reverse proxy. You need to provide more details.
If you have 24VAC power adapter connected, you can measure the AC (note: AC, not DC) voltage from the COM (common) terminal to a zone. When that zone is open, the voltage should be about 24VAC.
Alternatively, you can measure the DC voltage (note, DC) from +5V pin to a zone. When that zone is open, the voltage should be about 5VDC, and when the zone is closed, the voltage should be close to 0V.
The firmware build script automatically handles I2C config in your config.txt:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/dev/221_1/build.sh#L11
The firmware does NOT use I2S or SPI so they are not needed.Firmware 2.2.1(1) is in this branch:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/tree/dev/221_1
so you can pull this branch already and it will make the LCD and buttons work. It’s not yet merged to the master branch because we are finalizing the UI/app and will release the new firmware once the UI/app is released.@dun4cheap, look, you need to provide some more specifics about your setup. Not everyone who gets this error has the same setup. Let me first clarify that this error is due to the OpenThingsCloud library that we use for enabling OTC remote access. The library handles both local and remote connections. The error occurs if it receives a header that’s larger than its allows size. Because OpenSprinkler hardware 2.x does not support OTC, this doesn’t apply to 2.x. So it’s only relevant to hardware v3.x.
As you can read from the above, some users encountered this because they are using CloudFlare Tunnels. I don’t have it so I can’t test it myself, but the bottom line is that it’s sending a request to the controller with an overly large header, causing the request too large error.
I don’t see any evidence you are using CloudFlare Tunnels. So if I had to take a guess, your Visual Basic script is probably sending a header that’s overly large. The first thing to try is to figure out what header it’s sending, and if it’s possible to reduce itself. Look, when you access the controller using a browser, you never encounter this issue because the browser doesn’t send a very large header. This error almost always happens when you use a script, or as said above, CloudFlare Tunnels, which possibly appends a large header.
We can certainly modify the OpenThingsCloud library to increase the allowed header size, but ESP8266 has limited memory size, so we can’t increase the limit arbitrarily. The question really is why your script is sending a very large header, and if it’s possible to shrink it.
Regarding the app: the app is just a front end / UI that we provide. Please note that you have access to the OpenSprinkelr API, you can write a custom front end / UI as you want, to provide backup features. The thing is no matter how we change the UI, it’s not going to fit everyone’s need. The whole point of making the project open-source is to give users the freedom to customize the firmware, the UI, in any way you want, instead of always relying on us to provide these custom features.
I also recommend you to use more modern scripting languages, like Python, Javascript, etc. I am not sure how many people still use Visual Basic. You are likely to get a lot more community support and sample code with Python and Javascript, than VB.
Finally, ChatGPT and other similar generative AI can easily write simple scripts in no time. Just describe what you want, the basic constraints, the variable names, it can produce the script / program you want instantly.
The UI does display notification for new firmware update, but it won’t help if the root problem is the UI can’t be displayed due to outdated firmware.
It’s possible the import got disrupted for some reason. You can modify the .json file, leaving only the stations data, and just import that, see if it works. I attached the modified .json file here. It’s the original json with all sections other than “stations” removed.
Well, I got the same error about uploading file, so here is the file content:
{"stations":{"masop":[255,255,255],"masop2":[0,0,0],"ignore_rain":[0,0,0],"ignore_sn1":[0,0,0],"ignore_sn2":[0,0,0],"stn_dis":[2,128,255],"stn_spe":[0,0,0],"stn_grp":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"snames":["Lawn","Front Yard","Ferns","Retaining Wall","Driveway","Dry Creek Bed","S07 - Unused","S08 - Unused","Hill #1","Hill #2","Hill #3","Hill #4","Hill #5","Hill #6","Hill #7","S16","S17","S18","S19","S20","S21","S22","S23","S24"],"maxlen":32}}I believe this issue has been resolved via support ticket. For the record: any changes to expanders (such as adding an expander, changing its index) are effective after rebooting the controller. This is because the firmware detects expanders when it boots, and doesn’t defect any expander changes while it’s powered on.
The official OpenSprinkler v3 enclosure is designed and owned by SeeedStudio. I will see if it can be posted, but it’s a design meant for injection molding so the enclosure thickness may not be suitable for 3D printing, and it has many small structures which are definitely too small and thin for 3D printing.
