Forum Replies Created
-
Posts
-
To start, is this an OpenSprinkler or OpenSprinkler Pi? They have slightly different designs regarding where the fuse is placed etc.
Under the suggestion of @Water_my_lawn, I substituted EthernetENC with UIPEthernet (version 2.0.12) and recompiled the firmware, numbered 2.1.9(10) (i.e. 2.1.9 minor revision 10). So the only difference between minor revision (9) and (10) is the Ethernet library. The firmware is available for OpenSprinkler hardware 2.3 and also 3.2 with wired Ethernet connection. (It’s irrelevant if you use OpenSprinkler 3.2 only in WiFi mode). In any case, if you are on 2.1.9(9) and having frequent lockups or disconnections, give 2.1.9(10) a try and see if it solves the issue. The matter of fact is that we don’t know why some users are encountering problems with (9), we have not been able to reproduce the issue ourselves so without seeing the problem happen we can’t really debug it. I think it’s unlikely the same firmware works for all users (I am sure some users would have problem with (10) as well), so while no single firmware works for everyone, hopefully between (9) and (10) one of them will work for you.
Generally the master and remote controllers should run the same firmware because the firmware APIs are not always the same across different firmwares. They must also have the same device password. Also, the communication is one-way: that is, only the master controller sends command to the remote controller, the remote controller does NOT send status update back to the master. So you can only turn on zones on remote controller from the master; if you turn on zones on the remote controller itself, it cannot send the status update to the master, so it won’t be reflected on the master controller.
If you have access to both gateways, one solution is to set port forwarding on both. For example, if OpenSprinkler is connected to router 1, which is connected to router 2, you can set port forwarding on both router 1 and 2.
So you mean running the version with debug code has fixed the issue for you? That sounds puzzling to me: how does adding some debug code fix the issue?
@Water_my_lawn: I apologize for not being able to stay up to date with this issue. Long story short, I’ve been dealing with with severe health issues and haven’t been able to work on the firmware. I’ve got a bit more energy now to come back and look at this issue. Based on what you described, it sounds like UIPEthernet has fixed the issue for you — does the current version of UIPEthernet (2.0.12) work as is, or did you need to fix some code to make it work for you? I’ve been reading the github issues thread but I am confused whether the fix that made it work for you is in the current UIPEthernet branch or has it been reverted.
In other news, a little while back I’ve made the first version of the firmware that uses lwip which is available in the ESP8266 core 3.0.2. We’ve been testing it and it seems relatively reliable. While this will probably solve the hanging issues for wired Ethernet on OpenSprinkler 3.x, it’s only for ESP8266-based OpenSprinklers, so for OpenSprinkler 2.3 we still need to use either UIPEthernet or EthernetENC.
In any case, let me know what has worked for you and we can obviously make a version of the firmware based on that for any user who is seeing the same problem.
Sorry, because of the rather small demand of OSBo in the past, we’ve discontinued OSBo for several years and do not plan to restock them.
This might be due to the sensor falsely triggering. You can set a larger sensor delayed on time to see if it solves the issue.
Thanks for the pointer. Has anyone already started integrating open-meteo to OpenSprinkler weather code?
Check your app version: at the homepage, swipe left to right to open the left side menu, then ‘About’. What’s the app version?
Generally you can update firmware by using over the air firmware update, so there is no need to connect anything to the board. However, if you have to use your usb-serial connector, then as I said above, you can solder pins onto the serial pins. The connector we use is a 2×3 goldfinger connector. But you can certainly just solder pins onto the connector pads. On the front side, the pads are TX (i.e. ESP8266’s TX), +5V, GPIO0, on the back side are RESET, GND, and RX.
If you install Eagle CAD software, you can open the circuit files and check the property of each component, which contains the SMD size.
Because ACRET is basically the circuit ground (well, it’s connected to a current sensing resistor which is very small so it’s practically the ground of the circuit). For that reason, ACRET is basically 0V. In a circuit all voltages are measured against the ground, so if that point is ground, then it’s always 0V.
The traic is not that much different from a transistor or MOSFET for switching DC devices. A logical level control signal applied between its gate and MT1 (equivalent to base-emitter in NPN transistor, or gate-source in MOSFET) allows current to flow through MT2 and MT1. Why would you think this will destroy the MCU? This is the basic mechanism of how transistors work.
The firmware change is independent of UI/app change — at the time of the release, the firmware already supports 1 day as the program’s interval day, but the UI (i.e. front end will reject it if you input 1). The analogy is: your computer (including its hardware and firmware) may support 4K resolution, but let’s say your TV’s mobile app (if it has one) does not give 4K as an option. Now it does. Does this make sense? I already sent you the link to the line of code in the UI that accommodates 1 day.
Yes I believe it’s already integrated into the UI, assuming your controller runs firmware 2.1.9(9) (the UI detects the firmware version and applies different parameters depending on which firmware version you have).
https://github.com/OpenSprinkler/OpenSprinkler-App/blob/master/www/js/main.js#L9136The expander has never used PCF8574 because it only has 8 channels and expanders have always had 16 channels. The first version of OpenSprinkler used two PCF8574s on the main controller, one on the top board and one on the bottom/driver board. The bottom/driver board is not expander.
The code that handles expander is here:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/2b293a1c8712a05a95799bb3efa290ff771f4f46/OpenSprinkler.cpp#L1131
because it uses dynamic typing (i.e. expander[i] itself carries the type of the I2C chip), you will have to modify code in gpio.cpp:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/gpio.cpp#L118
the simplest hack is to remove the second Wire.write:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/gpio.cpp#L123
see if it works for your PCF8574.I2C address at 0x24 is assumed to be the first expander, and by default all expanders have 16 zones. The OpenSprinkler expander first version used PCF8575 which is a 16-channel GPIO expander; the current version uses PCA9555, also 16-channels. Because these chips along with PCF8574, all have the same base I2C address, there is no easy way to tell them apart from the firmware’s point of view (although PCA8575 and PCA9555 can be distinguished from each other because PCA9555 has certain registers that PCA8575 doesn’t have). This is the reason why if you hook up another PCF8574 at I2C address 0x24, the firmware assumes it’s a PCA8575 instead, so assumes it’s 16 zones. Because of this, it will always send 2 bytes to that chip (16 bits) instead of 1 byte. If PCF8574 receives 2 bytes, I think the second byte overwrite the first byte, that explains why your 0x24 board drives zones 17-24.
There is another forum thread that also discusses PCF8575:
https://opensprinkler.com/forums/topic/driving-14-valves-or-12-main-pump-from-os-3-0/#post-71927I would recommend you to consider using a PCF8575 board if possible (or PCA9555). If not, you will need to modify the firmware code so that it only sends 1 byte to the expander instead of 2.
Hmm, I am not sure. When using PCF8575, as I mentioned above, since it uses weak pull-up by default all channels are HIGH at start-up, so what I did was to use a PNP transistor per channel to reverse the logic, such that at startup the output becomes low. For this to work I think you will need a pull-down resistor at the output, otherwise the output will be in high-impedance state instead of low.
The UI (javascript) is not part of firmware. The way this works is that these javascript files are stored on opensprinkler server, when you type in the IP address of the controller in the browser, the firmware returns code to the browser to reference the javascript code on opensprinkler server. And if you use the mobile app, these javascript files are embedded in the app.
Since you are going to customize the UI, what you should do is to download the UI code, unzip, and run the index.html in a browser. If you type in the IP of opensprinkler in a browser, or use the mobile app, those javascript codes are not your customized code so it won’t work.
Hi, what you did sounds correct for the firmware part. But you will also need to modify the UI if you want those pins to show up in the UI. In the UI code, the free pins are hard-coded, and not transferred from the firmware to the UI, hence you have to modify the UI code:
https://github.com/OpenSprinkler/OpenSprinkler-App/blob/master/www/js/main.js#L5038You can download the UI code, unzip it, and run it locally in a browser.
