Forum Replies Created
-
Posts
-
We always recommend you to submit a support ticket. Usually when people post such questions on the forum, they don’t include information such as the hardware version, firmware version, whether using WiFi or wired Ethernet. It’s difficult to diagnose the problem without these basic information.
The misaligned pins are intentional — they are called ‘locked’ pins. Their purpose is to create slight mechanical tension so that the through-hole parts will stay in place even without soldering. The LCD in particular is not soldered, so this locked pins are important to make sure the pins and pads have good physical contact.
The GND and DGND was a mistake in an early version of the AC driver design. It has since then been fixed and I may have forgotten to update the files on Github. The mistake made one leg of C2 (decoupling capacitor) hanging and not connected, but it doesn’t affect the functionality of the board.
I’ve personally verified the flow sensing many times before on RPi and as far as my experiments went, it was quite accurate. I don’t have an RPi zero 2w so I cannot verify it for this particular version of RPi, but I’ve verified it on RPi 0 w, Rpi 2, Rpi 3 etc. What type of pulse generator are you using? Do you have a link? Also, what’s your version of raspbian?
The GPIO pin always refer to GPIO pin, it does NOT refer to positional pin. Generally we don’t use positional pin because that’s not how pins are referred to in a program. Please check the OpenSprinkler Pi user manual for details.
What firmware is running on your controller? And actually which controller do you have? If you are not already on the latest firmware (2.2.0) you should update your firmware first.
I believe this has been implemented by @rmloeb. You can check it on the openSprinkler-weather main github page:
https://github.com/OpenSprinkler/OpenSprinkler-Weather
search ‘Davis’ you will find the link.Well in that case, you can get a traditional sprinkler controller, and you can run OpenSprinkler with another controller in parallel. So if either controller turns a zone on, it can run that zone.
There are some subtle issues regarding the electrical part of running two controllers in parallel, but in general, as long as each of them uses their own power adapter (i.e. don’t share the same adapter), it should be fine.
If you look around for web-based sprinkler controllers, a lot of them don’t even have a screen nor any buttons. So it’s not like OpenSprinkler is any worse than them. If anything, it at least has a LCD screen and three buttons, and you can do some basic control using the buttons.
I don’t understand: you just need to use the app or web interface to create a program once, and then you can run it using the buttons. You can also stop all zones using a button.
If you want to do everything using buttons, why not just get a traditional sprinkler controller? The point of a web-based controller is to interact with the controller using an app or via web.
You can use the buttons on the controller to start a test program (runs every zone 1 minute), or start any existing program that’s already programmed on the controller. You can NOT create a program using buttons, but you can run an already created program using buttons. Long press button B3 will allow you to enter this mode.
If you just need a custom program that you don’t want to run regularly, a common practice is to create this program and set it to Disabled. That way it won’t run automatically, but using B3 you can start it.
Note that both sensor 1 and sensor 2 support ‘program switch’ feature. Which means you can connect a physical button to SN1-GND, or SN2-GND, and configure it as a program switch. When the switch is pressed it will start a program (for SN1 it starts program 1, for SN2 it starts program 2).
I recommend you to take a look at the OpenSprinkler User Manual:
https://openthings.freshdesk.com/support/solutions/articles/5000716364-opensprinkler-user-manuals
and/or firmware 2.2.0 intro video to see all supported features:
https://openthings.freshdesk.com/support/solutions/articles/5000860920-videos-introduction-to-opensprinkler-v3Update your repository and build again. The fix is to add a -std flag in the build script. The fix has been in the os33 branch for a while and I just got it merged to the master branch today.
OpenSprinkler firmware runs as a HTTP server. Once you get it running, you can run HTTP command locally on the RPi. You can use for example curl command.
I don’t think any software based protection will be able to shut off the triac in time. The short will happen instantly and there won’t be time for the microcontoller to respond. I’ve seen some commercial sprinkler controllers using a huge 10 ohm resistor for short protection. It works, but it’s not going to allow users to open multiple valves at the same time. So in case you don’t open more than 2 valves at a time, you can put a 10 ohm, 25 watt resistor in line with the common wire to server as short protection.
One possibility is to write a script (probably in Home Assistant?) that can send a command to OpenSprinkler via its HTTP API to trigger actions when the tank level sensor triggers.
Another possibility is to use some sort of remote switch, such that when the tank level sensor triggers, it sends a signal to trigger a relay via RF or any type of wireless signal. There are off-the-shelf wireless rain sensors that work this way. I would think probably some sort of wireless tank level sensor also exists.
How is your tank level sensor integrated with HA?
The fuse in OpenSprinkler is rated 3A, so it’s possible that the amount of current was enough to burn the triac but not enough to burn the fuse. It’s always tricky to pick the fuse with the right rating — because we always have customers who want to run multiple zones at the same time, if we choose the fuse too low, it will falsely trigger; on the other hand, if it’s too high, it obviously won’t be able to protect anything. We’ve also seen cases where the power adapter’s internal fuse blew before OpenSprinkler’s fuse had a chance to blow. So in reality, it’s not possible to have one fuse rating that fits all situations. If you know roughly what target fuse rating you need you can replace the fuse yourself. It uses the most common type of fuse (5mmx20mm).
Given the symptoms of both your OSPi and OpenSprinkler, you should definitely perform a solenoid resistance testing. You may have a shorted solenoid or shorted wiring somewhere.
Any OSPi can be upgraded to the latest firmware. Technically OSPi is just a passive extension board, it doesn’t run the firmware itself. The firmware runs on Raspberry Pi.
Firmware instructions for OSPi are here:
https://openthings.freshdesk.com/support/solutions/articles/5000631599-installing-and-updating-the-unified-firmware-on-ospiYes you are allowed to use the code. If you are planning to make changes and use it in commercial product, you need to open source your changes. Otherwise if you just want to use it for your own project, you can feel free to do so.
They can still be made to work, by changing the firmware code to send the complete information required by the current weather API. I honestly don’t even remember that firmware 2.1.5 supported dusk to dawn setting (that firmware was from 8 years ago), I thought that was a much later feature.
OS 2.1 and 2.2 are failing because their firmwares can no longer be updated to the latest. The weather service API has changed due to change imposed by weather data providers. Firmwares on OS 2.1 and 2.2 do not send enough data required by the API.
As I said, the weather data error is actually misleading, it’s not due to bad weather data, but it’s due to the weather server not responding with the correct output. We are trying to figure out why. It seems to have to do with either cloudflare or nginx configuration on the weather server. The error has nothing to do with the firmware or Apple WeatherKit. We are working on it.
In the meantime, you could try to use the weather server hosted by our German distributor Stefan. He has generously agreed to give me his weather service url:
opensprinklershop.de:3336
To use this, you can go to:
http://your_os_ip/su
where your_os_ip is your OpenSprinkler’s IP address, this should show a page where you can change the Weather url (note: Weather, not UI) to:
opensprinklershop.de:3336
once we figure out the issue with our weather server, I will post it here and you can change it back.It turns out this isn’t actually due to invalid weather data. Instead, it’s due to the firmware not receiving any response from the server. The firmware is supposed to tag this as error -1, but I think there is a bug that it did not prefix it with the negative sign. If you take a look at the API document:
https://raysfiles.com/os_compiled_firmware/docs/2.2.0/OSAPI2.2.0(1).pdf
at the very last page, it says any error code that has a negative value indicates network related issues such as the response not received, failing to connect to the weather server etc. Because it didn’t prefix it with the negative sign, the error code becomes positive 1 and the UI interprets it as bad weather data.Now, why there was no response from the server, that I am not sure. We rebooted the weather server and it looks like things are ok at the moment. Will monitor it over the next few days and see if the problem still exists.
The current watering level applies when a program is scheduled — when a program starts, it uses the current watering level to adjust the duration of each zone. Once each zone is in the queue its time will not be adjusted again.
Yes you can set the watering level by using API. This can be done by using the /co command, and you can pass the wl (i.e. watering level) parameter through that command. Check the OpenSprinkler API document:
https://openthings.freshdesk.com/support/solutions/articles/5000716363-os-api-documents
