Forum Replies Created
-
Posts
-
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.
@km9830, please be more specific. How are you accessing the controller, what error messages are you getting. Are you able to go to:
https://demo.opensprinkler.com/
and see the interface there? There are several different scenarios discussed above, just saying ‘getting the same issue’ doesn’t give us enough details to help you diagnose.Error 0x2D is due to SD card issues. It has nothing to do with wired Ethernet. Yes, try to change the microSD card — it’s located close to the top edge of the circuit board. Any size is fine, probably 4GB and 8GB is the most common, you almost can’t find anything smaller, and larger is more expensive.
Also, I would highly recommend you to upgrade your firmware to 2.2.1(0). Your current firmware 2.1.9 is outdated and has known issues with the current UI/app. Upgrading to the latest firmware will solve this problem.
https://openthings.freshdesk.com/support/solutions/articles/5000381694Please check the HTTP API document:
https://openthings.freshdesk.com/support/solutions/articles/5000716363-os-api-documents
page 5, section 12, “Manual Station Run” /cm. The ‘ssta’ parameter can be used to skip a current running or scheduled station.Per the support article for MQTT:
https://openthings.freshdesk.com/support/solutions/articles/5000859089-how-to-use-mqtt
the /cm command is also supported by MQTT.I am a bit confused. You said “I have a ospi board v1.4 circa 2012 that’s running fine” — but what RPi are you using with it? Don’t you have a RPi plugged into the OSPi at the moment? Otherwise, how is it running fine? You can update the firmware on any RPi — the firmware runs fine regardless of the RPi version.
One possible reason is you may be using ETo weather algorithm and the returned data by ETo is now quite large and exceeds the storage allocated to it in your firmware. So the bottomline is your firmware 2.1.9(9) is outdated. If you are not ready to upgrade your firmware yet, you can try the following:
Download the API testing script:
https://openthings.freshdesk.com/support/solutions/articles/5000716363-os-api-documents
open it in a browser, put in your controller’s IP and device password, then choose Change Options (/co) API at the end. Type in option name:
uwt
and value
0
This will reset the weather algorithm to 0. After that, power cycle your controller (remove power and then plug in power again). That should fix the issue, if the issue is indeed caused by the weather data.You can also use the script to save a copy of your configurations (the Get Json All /ja API). But in the end the only solution is to upgrade your firmware to the latest 2.2.1, which should solve this problem for good. Firmware update instructions are here:
https://openthings.freshdesk.com/support/solutions/articles/5000832310Yes it works, and I always recommend Pi 0 (instead of 4 or 5) because it’s cheaper, draws way less power, and is sufficient to run the firmware.
Thanks for pointing it out. Yes we are aware of this. The plan is to gradually migrate those back to opensprinkler.com, which is already the main store front of everything we sell currently. At some point the cloud server at cloud.openthings.io will be migrated to a different domain name and we are working on it.
The latest firmware automatically identifies the gpio chip number:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/gpio.cpp#L529
For RPi 5, I believe it will find gpiochip4. I am not sure where you changed gpiochip0 to gpiochip0, but it’s likely where you made the change is for other RPi versions, so it doesn’t matter.The power issue isn’t just that the onboard 24VAC to 5VDC converter isn’t capable of delivering 5A; note that 5V*5A=25Watt, which means the 24VAC power adapter needs to output at lest 25Watt. Most common 24VAC power adapters is only rated for 0.5A up to 1A, so the power adapter itself isn’t capable of delivering 25 Watt to begin with.
Honestly I would always recommend using RPi 0 with OSPi — it’s the cheapest and it requires minimum power. RPi 5 is so power hungry that it’s approaching a mini PC which should use its own power supply. We could use a beefier voltage regulator but first, the issue is that the 24VAC adapter isn’t able to provide that much power to begin with; second, if RPi foundation releases RPi 6, that may require even higher power, and at this rate there is no way we can keep up. So if you must use RPi 5, the only viable way is to give it its own power supply.
What are you using to power the board? If you are only using the 24VAC power adapter, that is probably insufficient. RPi 5 calls for 5V 5Amp, which is beyond the capability of the OSPi’s on-board voltage regulator. You need to use a USB-C power adapter to provide additional power.
Can I ask you to not duplicate the same message on the forum and also on github? This reduces my work of having to respond the same thing to both places.
