Forum Replies Created
-
Posts
-
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?
It’s temporary. For some reason the demo site gets a lot of DDos attacks. If you try at different times it should work eventually. You can also install the firmware on any Linux machine so you can run the demo site locally.
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.
