Forum Replies Created
-
Posts
-
OTA update through wired Ethernet will be supported in the next firmware, once we move to ESP8266 core 3.0.2, which unifies wired Ethernet and WiFi. Currently wired Ethernet is done through a separate library, and it doesn’t support OTA update.
While debugging this, I found the root cause of the issue: weather.opensprinkler.com is now proxied by Cloudflare (CF), and as a result, the return of the weather script has additional header data added by Cloudflare. This makes the result (including header) larger than 512 bytes. The EtherCard library used in early firmwares such as 2.1.7 apparently has a limitation which does not allow it to handle received packet larger than 512 bytes, therefore the weather query fails. We are looking into how to address this issue, one possibility is to see whether the additional headers added by Cloudflare can be reduced or removed; if that’s not possible, the only viable option is to launch a weather service elsewhere (you can set up a weather server yourself, using a raspberry pi for example), and change OpenSprinkler settings to point to your new server which is not proxied by CF. This should be able to solve the problem.
Coincidentally, the larger result data might also affect OpenSprinkler 2.3 and 3.0 running 2.1.9(9) or (10) — what happens here is that although the Ethernet library is able to handle any size incoming data, it still splits the packet into chunks of no more than 512 bytes each. When I wrote the firmware, I did not anticipate the weather query result can be larger than just a few hundred bytes, so the current code will result in later chunks overwriting earlier chunks. So what it’s getting is not the complete weather query result, rather it’s the last chunk. Fortunately because most of the data is header data, the actual weather data needed by the firmware is in the last chunk, so after peeling away header, in most cases it still has the correct weather data. However, there is clearly a problem in that this leaves the firmware vulnerable to variations in the header data or weather query result, in some cases it can lead to failure of parsing the weather result. In any case, I have fixed this issue and will shortly make minor revision 2.1.9(11) available. If you are observing your OpenSprinkler getting weather status ‘Offline’ it is very likely due to this bug, whether you are using WiFi or wired Ethernet. I will make a separate post shortly.
I am surprised you were able to get the firmware compiled with core 3.0.0. It has been a while but I remember when I tried to compile the firmware with 3.0.2 I had to make a number of significant changes to even get it to compile. The main advantage of core 3.0.x is that it unifies the handling of WiFi with wired Ethernet (using lwip2). Since both use the same WiFi API functions, OTA update works with wired Ethernet as well (currently with firmware 2.1.9 OTA updates only works with WiFi as wired Ethernet uses a separate library). I will probably check in the changes I made to a separate branch on github. I made the changes as an initial step to prepare for firmware 2.2.0, but it’s quite far from being completed.
I am glad to hear you’ve figured it out, although I am still puzzled why newer ESP8266 platform would result in such difference. Do you know the esp8266 core version that these newer platforms use? The current OpenSprinkler firmware is compiled with ESP8266 core 2.7.4 (as shown in the Makefile and build instructions). I’ve compiled it with the latest core version 3.0.2 as well but have not fully tested it. I am not sure what core versions platformio uses.
Well if you are using WiFi, I really have no idea. Perhaps try a different nodemcu? You said you compiled the firmware yourself. Did you try the stock firmware that we compiled?
Honestly I really don’t know what’s causing it. We’ve tried everything we can, including changing the Ethernet library and released 2.1.9(10) which you’ve tried. We have never been able to reproduce the issue internally, so without observing the issue happening we can’t debug it. Also, what zsolesz79 was asking is a separate issue — it has to do with a corrupted flash memory string, this has nothing to do with losing Ethernet connection.
This is definitely not a known issue for firmware 2.1.9(9). I am not sure whether it has to do with your Wemos. Probably the easiest way to set the parameter is to go to:
http://raysfiles.com/os/TestOSAPI.html
type in your OpenSprinkler’s IP, port number, password, choose the ‘Change Option (co)’ API, then
Option name: wto
Option value: {}
this will set an empty string for wto. Hopefully it works.The corrupted json doesn’t seem to have to do with the firmware. You may want to perform a factory reset and try again, or use the HTTP API to directly reset that particular corrupted string.
The current firmware does not support setting host name unfortunately. This can be added by modifying the firmware code and using mDNS.
In some cases you can make use of the OpenSprinkler HTTP API:
https://openthings.freshdesk.com/support/solutions/articles/5000716363-os-api-documents
to provide customized need. For example, you can write a small script to disable a program and later re-enable it and modify its ‘start in’ parameter. This may help achieve what you want. We have an example test script:
http://raysfiles.com/os/TestOSAPI.html
which shows selected examples of the API.If I understand correctly, you want the start day to be a specific day (e.g. Sep 23, 2022). This change is not as trivial as you might think — just deleting the modulo operation will not work. To start, the ‘start’ day being a modulo is not my invention, on traditional sprinkler controllers, this is basically how the parameters are set. Say if you have a program that runs every 5 days, and you don’t want it to run on the day the program was created, instead you want it to start in 4 days, and then every 5 days from then. The ‘start’ day parameter will change dynamically, for example, tomorrow when you check the program, it will say start in 3 days, and the day after tomorrow it will say start in 2 days etc. The way this is implemented is to modulo today with the interval day (5) and compare it with the remainder and that tells whether today is when the program will run or not. As you can see, if the ‘start’ day is more than the interval, this comparison will not work.
What you want is for the program to record a specific day (say, Sep 23, 2022) and that you want the program to start on that day and every x days from that. This is all doable — it will need to involve both firmware changes (including changes to the program data structure because each program has to store a specific day), and also UI changes. This is nothing complicated, but what I am saying is it’s not as simple as deleting the modulo operation.
I am not sure if there is one correct way to implement the rain delay. The issue with your proposal is: what happens with the other programs which should run normally and that fall after the rain delay period? If we keep pushing them back and queuing them, you can quickly get into the situation where there is simply not enough time to catch up with so many queued programs. For example, let’s say a program is supposed to run every day, and there is a rain delay that happened on Monday and Tuesday. If you queue those programs to run on Wednesday (i.e. after rain delay ends), what about programs which would normally run on Wednesday? Besides, stop watering during rain delay is partly to avoid wasting water, since the rain will irrigate the lawn anyways. So delaying those programs after the rain delay ends seems to over-water the lawn still.
Using one of the weather adjustment method can partly address this issue: instead of doing manual rain delay, let the weather adjustment method to figure out the watering percentage automatically. I know the weather adjustment methods are not perfect, but my point is that no matter how you implement the algorithm, there will always be some situations where the implementation doesn’t work perfectly. So I don’t think there is one correct way to implement the rain delay.
Without load, the voltage you are measuring would be floating, so it’s normal to see 24VAC. You need to connect a load, like a solenoid or a high value resistor at least.
For opensprinkler firmware, have you looked at the instructions here?
https://openthings.freshdesk.com/support/solutions/articles/5000165132-how-to-compile-opensprinkler-firmwareThe ‘starting in’ days is always a remainder of the interval days, for that reason cannot be larger than (interval-1). Basically this is not used to delay the program by some arbitrary number of days, instead, it’s used to set when the programs should start within a cycle of interval days.
Etekcity power sockets generally work. The limitation of the firmware is that it only works with power sockets that use protocol 1 (this is also the most common type). I am aware of some sockets which use other types of protocols. In theory the firmware can handle any types of protocols, but at the moment the RF code does not indicate the protocol type and defaults to use protocol 1.
The firmware manual is the OpenSprinkler manual. It includes wiring diagrams and how to connect to sensors.
The sensor’s manual says white goes to COM because on Irritrol and similar controllers, COM is the common wire for sensors. On OpenSprinkler, the design is different: the sensor’s common terminal is GND, as explained in the OpenSprinkler user manual. This is different from the COM terminal, which is the common terminal for sprinkler valves.
I don’t think the white wire should be plugged into SN2 — SN2 is for a second sensor, it’s not for the common wire of the first sensor. If you checked the user manual, a sensor should be connected between SN1 and GND (or SN2 and GND if you have a second sensor). I don’t know how this particular sensor works — I would assume if you measure the resistance between the brown wire (normally closed) and white wire, it should be 0 when no rain is detected, and should be open circuit (infinity) when rain is detected. If this is the case, then the white wire should be plugged into GND.
Have a fuse for each zone would take up a lot of space. I don’t know if you’ve seen the existing fuse, it’s big. The current enclosure has no space for such fuse per zone. But you can certainly add per-zone fuse yourself.
Yes, the fuse is connected inline with the COM wire so all solenoids will go through the fuse since all are connected to the COM wire. I can’t explain the burn out. The circuit already has a number of protections in place: each zone has a RC snubber circuit to absorb sudden voltage/current changes, it’s protected by a TVS diode for transient high voltage, and there is an inline fuse on the COM wire. The fuse rating should be higher than 800mA because all triacs can sustain a quite high impulse current (up to several amps) in the event of transient high current. Generally, in the event of shorting, a very high amount of current would flow through the fuse, hopefully burning it out to protect the circuit. So exactly how the traic is burned, I don’t know. Is the expander completely unusable or is it that just the first zone is not?
