Forum Replies Created
-
Posts
-
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-documentsWhat’s the error message? If you check System Diagnostics it should show Last Response, there should be an error message there. It’s possible Apple changed some API we can figure that out.
Instructions can all be found at:
https://support.opensprinkler.com
for example, OSPi firmware instructions are here:
https://openthings.freshdesk.com/support/solutions/articles/5000631599You can install the firmware in any directory of your choice. The one in the instructions is just an example.
About your second question: what firmware are you on? The latest firmware 2.2.0 has a new feature which allows you to select whether you want to move the remaining zones in the same sequential group when you stop one zone. The user manual:
https://raysfiles.com/os_compiled_firmware/docs/2.2.0/OSUserManual220(1).pdf
page 10, section 4.3 shows it.The internal pull-up is relatively high, probably somewhere around 100K ohm. I didn’t know it wasn’t sufficient for some cases. Can certainly add a strong pull-up in the future version,.
The internal pull-up is always on — the firmware turns it on right at the initialization step. You can verify this by checking the sensor port to ground voltage (assuming no sensor is connected to interfere with it). The voltage should be around 3.3V, if so that means the internal pullup is on.
Each program has a ‘Use Weather’ flag that you must turn on if you want watering percentage to be applied.
The wire-in resistor is for current limiting — believe it or not, we’ve had customers who mistakenly plugged in 24VAC to the sensor port, without a current limiting resistor, it will burn out the microcontroller.
There is no external pull-up resistor because the microcontroller has built-in pull-up resistor that can be turned on in firmware, which is exactly what the firmware does during initialization:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/OpenSprinkler.cpp#L840OK, if I understand correctly, you mean you have openhab and OpenSprinkler firmware both running on the same Pi? You can edit the default port number in the OpenSprinkler.cpp file:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/OpenSprinkler.cpp#L332
then recompile the firmware. You need to delete done.dat in the firmware folder so it triggers a factory reset and applies the default port number.Is there any reason you don’t want to go to the web app to make setting changes? You don’t need a display or keyboard, all you need is a browser that can access the OSPi, then go to Edit Options -> Advanced, and change the HTTP port there.
The test tool returns raw log data. It may look something like this:
[[3,17,616,1413511817], [0,”rd”,86400,1413511845], [254,1,5,1413512107], [1,3,2700,1413552661], [5,3,1200,1413559201]]
this allows us to identify if something may be corrupted in the log data.
