Forum Replies Created
-
Posts
-
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.
I forgot to mention: if you run
git log
in the firmware repository, what’s the first few lines that’s displayed?Can you check if this file exists on your system:
/sys/class/gpio/gpiochip512Basically the build script uses this file’s existence to check if it needs to link with the gpiod library (which is needed for gpio operations in bookworm):
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/build.sh#L41C11-L41C38From the picture, it looks like you have OpenSprinkler 3.0 AC-powered. You can point them to the OpenSprinkler support website:
support.opensprinkler.com
which has videos, user manuals, and answers to common questions.Please follow the instructions here to update your firmware to the latest:
https://openthings.freshdesk.com/support/solutions/articles/5000631599-installing-and-updating-the-unified-firmware-on-ospi
Bookworm made breaking changes about how GPIOs are operated and we’ve updated the firmware to address that issue.Make sure the SD card is formatted to FAT32 and not other format. You can always reformat the SD card and try again.
Ah, ok yes, version 3.3 top board does have a 24C02 EEPROM, but it’s only used in order for the firmware to distinguish between versions 3.2 and 3.3, it’s not used to store any data. What’s going on is that 3.3 and 3.2 are otherwise the same except the pin ordering for the wired Ethernet jack are different (3.3 is for W5500 module and 3.2 is for ENC28J60 module). Without any ‘signature’ the firmware will not be able to tell these two apart. So I added a very cheap I2C EEPROM as a way for the firmware to detect which version it is. There are no other spare GPIO or analog pins for this purpose. So an I2C chip would be the easiest.
OTA update itself doesn’t reset WiFi and configurations, what does is the firmware change across major revisions, such as from 2.1.9 to 2.2.0. If you are updating the firmware within the same revision (i.e only the minor revision changes), then it doesn’t reset WiFi and configurations. For example, updating from 2.2.0(1) to 2.2.0(3) will preserve all settings. The main reason updating across major revisions wipes out flash is that usually these major revisions involve major flash memory changes or partition table changes (for example, the file system on earlier firmwares used SPIFFS, now it’s LittleFS), as a result, a flash memory wipe-out is necessary and cannot be avoided.
For that reason, we try to keep new firmware updates within the same major revision, until it becomes necessary to change the flash layout again.
There is no EEPROM on ESP8266 — all files and data are stored in flash memory. The module (ESP-12F) has 4MB flash, among which 1MB is used for the firmware, 1MB is for OTA update buffer, and 2MB are left for data.
Minor revisions (4) and (5) are on Github but they are not officially released/announced. (4) addresses the issue caused by breaking changes in GPIO controls with Raspbian Bookworm; (5) fixed an issue introduced in (4) that only affects OpenSprinkler 3.x and it’s not relevant to OSPi/RPi. So neither of these two versions changes the HTTP API which remains the same with minor revision (3).
MQTT instructions can be found on our support website:
https://openthings.freshdesk.com/support/solutions/articles/5000859089-how-to-use-mqttIt currently only supports outputting information through MQTT (i.t. MQTT publishing). You cannot yet use MQTT to trigger an action on OpenSprinkler (i.e. MQTT subscription). It’s quite easy to modify the firmware code to implement subscription. The last time we tried to do this, the developers did not agree on the APIs to use so we stalled there (then the pandemic happened and things got slowed down dramatically). So if you want to trigger an action, at the moment you need to either use the HTTP API, or implement MQTT subscription yourself.
