Forum Replies Created
-
Posts
-
Well, having an OLED display connected would be tremendously helpful to see what’s going on. You can also turn on serial debugging and that way you can watch the output from serial. This would require you to compile the firmware. To turn on serial output, just uncomment this line:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/defines.h#L27
and compile the firmware.The latest firmware no longer requires an RTC — if an RTC doesn’t exist, it will fall back on NTP syncing. I don’t think it requires PCF8574 either: without PCF8574 it will by default assume this is an AC-powered opensprinkler.
From the screenshot, it looks like the firmware is successfully uploaded. Depending on your WiFi network and the browser, after clicking on Connecting, it might not respond and may look as if it’s stuck. But what’s important is to watch the LCD screen: if it can connect to your WiFi router, then it will reboot itself (you may need to unplug and re-plug in power because ESP8266 has a well-known bug that triggers a stall if you reboot right after flashing the firmware. Power cycle it will fix the problem).
Ah, I know what happened — and this is admittedly my fault not updating the part number properly. So QB1 and QB2 originally were MMBT3904 NPN transistors, and as such they should have base resistors (anywhere between 1K to 10K should be ok). However, in the end I decided to minimize the number of different parts so these were replaced by AO3400 N-channel MOSFETs, since the board already uses AO3400. As is there is now only a 10K pull-down resistor between gate and source, there is no more base resistor. So if you used MMBT3904 then it would have no base resistor causing large current draw. I think this is probably what happened. I am sorry about the inconsistency in the schematic and I will update it in github shortly.
I tested the current draw on the 5V line using a OS 3.2 DC, and it’s definitely not 300mA. With the ESP8266 (i.e. top layer board) on, the current is about 80mA in AP mode, and about 50mA in WiFi station mode. This is the case either when no solenoid is on, or a solenoid is on. You said you have a friend who has a OS 3.2 DC, that you tested and it draws about 300mA. I am not sure how to explain that, but the one I tested definitely does not have this issue.
One thing you should be careful with is the SMBJ24A TVS diodes — these are for protection against high transient voltages. These are polarized (unlike in the AC-powered controller, which uses non-polarized TVS where the part number ends with CA and not A): the negative of each TVS diode should be connected to each zone port, and the positive should be connected to the 0.2ohm current sensing resistor. I realized that in the schematic I used a non-polarized TVS diode symbol, so it probably is confusing which direction it is. If the polarity is wrong, when a solenoid is connected, it’s basically immediately connecting the solenoid to ground, thus it will start to draw current even when the zone is off. That said, it still doesn’t quite explain the high current draw on the 5V line, because in holding state, the solenoid draws current from the input power supply, not from the 5V line, so even if the TVS diode polarity is wrong, it still doesn’t explain the issue.
I don’t fully understand the problem, but here are a few notes to begin with:
– BPE is the booster power enable pin, when it’s high, the input DC voltage is fed into MC34063 booster to generate boosted voltage.
– BVE is the booster voltage enable pin, when it’s high, the boosted voltage from the 2200uF capacitor is dumped to the COM line, to provide impulse voltage for the solenoids to engage.
– Between the input DC voltage and COM, there is a SS34 diode, this way, as the boosted voltage fades away, the input DC voltage will continue to provide holding current for the solenoids to keep engaged. As long as BPE is turned LOW after the initial impulse voltage, it doesn’t matter if BVE stays HIGH or not, because the voltage from 2200uF will eventually fall below input DC voltage, hence the input DC voltage will take over to provide current to the solenoids. On the other hand if BPE stays high, the booster will continue to try to bump the voltage, and that can be a problem.
– The only thing I can think of, regarding 7805 drawing a lot of current, is that something on the +5V line is drawing a lot of current. But if you look at the schematic, there isn’t that much connected to the +5V line: the booster is connected to the input DC voltage, so that comes directly from the power supply and not drawing from +5V. Also, as long as the input DC voltage is higher than 5V (we use 7.5V by default), the current shouldn’t flow backward from 5V to the input.
– We are aware that if the controller has a wired Ethernet module connected, it can draw a lot of current — because the wired Ethernet module itself draws 180mA, and the WiFi chip further draws 70mA, that’s about 250mA at minimum. For this reason, if wired Ethernet module is connected, we recommend the input DC voltage to be as low as possible: 7.5V is ideal, 9V is probably ok, but 12V would be too high as that will put too much heat dissipation on 7805. Even without wired Ethernet module, the DC voltage should not be higher than 12V, again, to minimize the power dissipation on 7805.What is your input DC voltage? Even at 300mA current, if the input voltage is only 7.5V, that power dissipation shouldn’t be more than (7.5-5)*0.3 = 0.75W (probably a bit lower than this because there is a diode D1 that drops maybe 0.5V). Do you have anything else connected on the +5V line?
We use Captcha v3 which does not require you to solve puzzle. It monitors your mouse movement and keyboard typing etc to detect spammer.
When you said your zone pins are at 24V, between which pins are you measuring this? Also make sure you measure AC voltage, not DC.
Currently you can tell which way it’s connected on the LCD: if it’s WiFi connected, it shows a WiFi icon (the little triangle bar icon); if it’s wired connected, it shows a small network icon (looks like 3 boxes connected via cables).
Yes we can add the indicator to the UI as well.
The reason it can only be done through WiFi is that OTA update for ESP8266 is a standard feature built-in to the core libraries. OTA update with wired Ethernet — no one has ever written that part yet. That said, I have started looking at ESP8266 core 3.x which seems to have unified the handling of WiFi and wired Ethernet, per it’s possible that OTA update can be done with both, but I have to do some research on that.
Are you using wired Ethernet? If so you need to switch to WiFi mode as firmware update can only be done in WiFi. You can power off the controller, remove wired Ethernet module, then power it back on.
You can use the internal pullup available on RPi. This is what OpenSprinkler firmware does:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/gpio.cpp#L292
it calls the system’s gpio command to enable internal pullup. This requires wiringPi to be installed.I would recommend trying a factory reset first. Make sure to keep a copy of your configurations so you can import them later.
You can just unplug the power and it doesn’t matter how long you power it down for. The next time you power it back up, it always checks and syncs with network time first, there is no need to manually set the clock, it will just work fine.
I am pretty sure these are 24VAC valves. So either AC-powered openSprinkler or DC-powered OpenSprinkler can work with these valves. Choose AC-powered if you have a pump start relay. Do NOT choose Latch OpenSprinkler as that’s not compatible with 24VAC valves.
Let’s first start with PCA9555’s behavior: if you take a look at PCA9555’s datasheet, its initial state is that every pin is in input mode with an internal pull-up resistor (about 100K). So this means right after power on all the pins will be in HIGH state. This persists until you send a command to set the pins to output mode and set them to LOW state. Normally the 100K pull-up resistor isn’t strong enough to drive a real load, but it is certainly sufficient for MOSFETs or even NPN transistors to turn them on, thus activating your relays.
To solve this problem, if you look at OpenSprinkler’s driver design:
https://github.com/OpenSprinkler/OpenSprinkler-Hardware/blob/master/OS/3.0/AC_driver/acdr_3.2.png
it has 10K pull-down resistors on each zone, this will overcome the 100K internal pull-up resistor to make sure the pins are at LOW state at power-up.Also, the initialization code:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/OpenSprinkler.cpp#L802
calls apply_all_station_bits() function, which internally calls PCA9555’s functions to set the pins to output mode and set them to low.Now, what I don’t know is whether your relay board is ‘active high’ or ‘active low’ type. Many common relay boards use ‘active low’, that means, a signal that’s LOW will activate relay. In that case, you actually want station_bits to be HIGH in order to deactivate the relay, and LOW to activate it. This is something you need to find out about your relay board because they are not all built the same.
We do sell these in our online store:
https://opensprinkler.com/product/screw-terminals/
It’s of type HT3.96-2PFirst, this thread is now off topic: the title of the thread is “OS 3.0 Lan Adapter” but now it’s discussing firmware compilation issues. It would be good if you can create a new thread with an matching title.
If I understanding correctly from your description, it sounds like you are saying your station 8 behaves differently from the other stations. This seems more of a hardware problem — the reason is that the code does not single out station 8 in any way, it does the same thing to a whole byte, which corresponds to all 8 stations. If anything, you may want to check if your station_bits (it’s an array) is of type byte (aka uint8_t) or did you declare it to be some other type, like bool. If it’s not a byte type, I can certainly see it may produce different behaviors on station 8.
Well, this is referring to pre-configured NTP servers:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/opensprinkler_server.cpp#L2146
previously it’s using just one, now the firmware can cycle through an array of servers if one fails. The user-configured NTP server is still just one, because this option is rarely used. If you want to customize the NTP servers using your own, you can modify the firmware source code and compile a new firmware.@Betterkeks: interesting, I had no idea about WMM (my router doesn’t have this option). But this is certainly worth investigating given the clear symptoms you reported. Let me know your router details and the firmware it’s running. The controller uses ESP8266, which is quite common in a lot of WiFi devices, particularly WiFi power sockets etc. I did a quick search of ESP8266 and WMM, and it seems to be an known issue:
https://github.com/esp8266/Arduino/issues/2795
I will be reading more about this and see if it can be solved in firmware.@Jaroslaw: the firmware already checks if WiFi is dropped and attempts to reconnect:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L562
Problems with WiFi may be more elusive than you think. The difficulty is that at internal testing, we’ve never observed WiFi dropping issues. We have 3 different test routers and none of them has any dropped WiFi issue. We’ve also testing unplugging and replugging WiFi router to simulate a WiFi drop, and the controller works fine after the router came back online. We suspect the WiFi issues some users experienced are during to their specific router or WiFi environment — there can be interference, the router may kick devices out for no obvious reason. In any case, if we were able to reproduce the issue we would obviously have introduced solutions to it. The fact is that during testing we couldn’t reproduce the issue so we don’t know what’s causing the wifi dropping issue.I am not sure but I suspect not — motorized ball valves usually require electricity to be applied for several seconds to give it time for the motor to move. OSBee only sends impulse voltages that last for a few hundred milliseconds. It works with typical latching valves, and I don’t think it works with motorized ball valves. I am not aware of any motorized ball valve that would work with OSBee.
On the other hand, I believe U.S. solid’s “9-24V AC/DC and 2 Wire Auto Return type” can work with both AC-powered and DC-powered OpenSprinkler (in the DC-powered case, it needs a power adapter that’s 9V or 12V, because the default adapter we include is only 7.5V).
Unfortunately we do not know why the WiFi drops off in some cases. We were never able to reproduce the issue on our own test network. I don’t think it has to do with how far the router is to your controller, rather, it has to do with the router kicking the device off its network for some reason.
We did release a new version of the firmware 2.1.9(9) just today, which contains a new feature that allows using a program to trigger a reboot on a regular basis. So if you have WiFi reliability issues, you may want to give this a try to see if rebooting once per day or maybe per 2 days etc can help.
The 2.1.9 tag on Github was accidentally deleted a while back but we’ve just released 2.1.9(9) (i.e. minor revision 9).
You can get all versions of expander from our website:
https://opensprinkler.com/product/zone-expander/On v2 there is no jumper for addressing because it uses shift register cascading, so the order of zones is completely determined by the order the expanders are linked.
V3 uses I2C IO expanders because ESP8266 does not have enough GPIO pins to talk to shift registers and I2C is the most efficient way to support expanders using only 2 signal lines.
You can probably use one of the sensor ports on OpenSprinkler as ‘program switch’. Have your water level sensor’s output connected to the OpenSprinkler as a sensor, and set it as a program switch to start a program when it’s triggered. I don’t have the full technical details since you didn’t explain what kind of signal your water level sensor outputs. If you are using a ESP8266, you can use one of its GPIO pins as output to produce a digital signal (1 or 0) to indicate the water level reaching target level. Then connect that GPIO pin to either SN1 or SN2 on OpenSprinkler, and GND to GND on OpenSprinkler.
