Forum Replies Created
-
Posts
-
The first thing to check is at the homepage, see if the time displayed there matches your local time. If not, make sure you set the location correctly. Go to Edit Options -> System, there you can set your location.
Next, check if you may have a rain sensor enabled. If so it’s possible that the program got skipped because the rain sensor was activated at the time it was about to start.
It’s relatively common to wire a rain sensor in series / inline on the COM wire. A typical rain sensor is normally closed, and it opens / breaks circuit when rain is detected. So when it’s put in series on the COM wire, it will break the circuit when rain is detected.
So I looked into this issue, and it seems that if you have 1) provided a WUnderground API key, and 2) selected a specific PWS station; 3) chosen ETo as the algorithm, then you will get a WUnderground Method Not Supported Error. But if you didn’t select a specific PWS station, instead, you just selected a GPS location, then it will fall back to WeatherKit and calculate ETo using that. This is indicated in the System Diagnostics, where it will say the weather data is powered by Apple.
We will be looking into getting ETo and PWS supported. If I remember correctly, partly the issue in the beginning was solar radiation is not guaranteed by PWS, in fact, I just did a few tests, and it’s true that some PWS stations don’t provide solar radiation data (the value is null). But I agree that for those that do provide this data, it should be possible to use ETo. We will look into this.
As described in the release notes:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/releases“The event when a master zone is turned on has been added to MQTT, IFTTT, and Email notifications.”
Currently it does NOT send notification when master is turned off. There are two reasons: 1) this is added mainly to address some customer’s requests that they want the ‘master on’ event to be sent on MQTT in order to trigger other actions; the ‘master off’ event doesn’t matter; 2) it was easy to change the firmware to add support for ‘master on’ event while ‘master off’ requires significant more changes. This is mainly because the way master zones are implemented are different from regular zones, and unlike regular zones, master zones don’t appear in the running queue, nor do they have scheduled duration, their on or off status is completely determined on the fly by other zones’ statuses. For that reason, we didn’t add ‘master off’ but this can be added in the future.This is a v3.3 board you bought from us or did you make it yourself? Do you have the 32.768kHz crystal connected to your PCF8563? Without the crystal the time will not move.
We plan to address this in the next version of OTF library. Currently the incoming request is read into a 2K buffer, which is more than sufficient for most requests. Of course if Cloudflare adds a lot of extra header it can quickly exceeds the buffer size, we just didn’t know it could be a very large buffer.
Go to:
support.opensprinkler.com
click the support article on “OpenSprinkler Remote Access using OpenThings Cloud (OTC) Token”Can I ask you why you are trying to compile Linux firmware in VSCode? As the instructions in the README say clearly:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware
For OSPi/OSBO or other Linux-based OpenSprinkler:
https://openthings.freshdesk.com/support/solutions/articles/5000631599You should use the bulid.sh script to compile it for Linux.
If you try to access:
https://demo.opensprinkler.com/
do you get the same error? The demo runs firmware 2.2.1(0) currently. The request too large error is usually due to the request header larger than the buffer size. This shouldn’t happen unless if you have a firewall or proxy that inserts additional data to the header.I didn’t design the bottom part. The top enclosure is designed to be mountable alone, without a back panel. I noticed that our German distributor has their own design which has both the top and bottom parts:
https://opensprinklershop.de/en/product/ospi-gehaeuse/
not sure if the 3D files are publicly available but you can send a query to them if you want to find out.The poll timeout has been reduced to 5ms, so theoretically it can handle 200 polls per second, and accounting for the sampling theorem, it can handle pulse rate of 100 clicks per second. The 5ms timeout can be further reduced, but I assume the ability to handle 100 clicks per second is probably more than sufficient.
The email notification is synchronous meaning the controller will wait till the email has been sent out before it can proceed to the next step. Obviously if you generate a lot of notification events to the point, say it produces 2 notification events per second while the email takes 1 second to send each, then it will never be able to catch up. But in most cases there aren’t so many notification events, at least not so many events persistently.
greiman/SdFat @ 1.0.7 is a SD card library required to compile for OpenSprinkler 2.3 (based on AVR microcontroller). Are you trying to compile for OpenSprinkler 2.3? That version has been discontinued close to a decade ago. If not, you can comment that section out in platformio.ini so it will ignore that part.
It’s hard to tell without seeing your schematic. The firmware writes the current UTC time into RTC every time it gets a successful time sync from NTP server. The firmware maintains a system time. When the controller reboots, it will first retrieve the system time from the RTC. If it subsequently gets a successful NTP result, that will overwrite the system time (and writes that to RTC). The firmware does time keeping on ESP8266, which is pretty accurate, so it only needs to perform NTP occasionally to ensure the time is still accurate. The involvement of the RTC is pretty minimal here — it primarily covers the situation when the controller has rebooted but can’t access NTP yet (e.g. because the router hasn’t finished booting). Normally if the controller has NTP access (which is the common scenario), it will get time from that.
The current OpenSprinkler design uses PCF8563. The firmware can auto-detect the chip:;
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/I2CRTC.cpp#L46
so you can use any of PCF8563, DS1307, and MCP7940.You are right that DS1307 requires at least 4.5V VCC. So the previous version of the OpenSprinkler that used DS1307 has its VCC tied to +5V, whereas PCF8563 can work with 3.3V so its VCC is tied to 3.3V.
We got our RPi 5 today and found the issue. Basically RPi 5 has changed the gpio chip name. So this line:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/gpio.cpp#L475
the name “gpiochip0” should be changed to “gpiochip4” on RPi 5. We will be working to address this and make the firmware compatible with all RPi versions. In the meantime, you can modify the name yourself and recompile the firmware, and see if this fixes the issue for you.You can easily test this by disconnecting the wire of that zone from the controller. If the area continues to be wet, that means it’s a valve / leaking issue.
Current draws below 100mA are usually just noise and they do not indicate solenoid runs. AC signals can be noisy. If a solenoid is running the current draws would be around 200mA.
We’ve ordered a RPi 5 and will have it next week so we can test.
What I meant to say is that having your actual hardware at hand would allow us to make sure it’s working before sending it back to you. Chances are we will get our RPi 5, and the firmware will pass all tests, but then it doesn’t give us any information about why it doesn’t work on your end. It’s not that we can’t afford to buy an RPi 5, it’s pretty cheap and affordable, the issue is reproducibility: that if it works with our RPi 5, it won’t give us any information about why it doesn’t work for yours.
Everything seems fine on the firmware side. Honestly, I don’t know. We currently don’t have a RPi 5 for testing. We did test the firmware under RPi 4 with Bookworm and the GPIOs are all working. Not sure if something is different with RPi 5. If you want you can send a support ticket at:
support.opensprinkler.com
and arrange to send us your RPi 5 so we can diagnose the issue and make sure it works then send it back to you.At the minimum you need four pins: FTDI’s 5V to +5V, TX to ERX (ERX stands for ESP8266’s RX pin), RX to ETX, and GND to GND. GP0 (GPIO0) and RST are for the auto-reset circuit, which you don’t need. Auto-reset allows the controller to automatically enter programming mode based on signal sequence from FTDI, but without the auto-reset, you can still manually enter programming mode by pressing the second pushbutton (B2) while plugging in power. That will tell ESP8266 to enter programming mode.
If you want you can send a support ticket at support.opensprinkler.com and arrange to get a programmer like this one:
https://rayshobby.net/wordpress/wp-content/uploads/2021/10/ch340_cardedge_programmer.jpg
it can plug directly into the PCB edge connector so it’s easier than soldering wires onto the programming pins.In the firmware, turning on the #define ENABLE_DEBUG at the beginning of defines.h will enable all the debug functions. You can also add additional debug functions. The firmware doesn’t use gdb — when debugging we just use the debug output to check variable values.
