[Ray]

We use Captcha v3 which does not require you to solve puzzle. It monitors your mouse movement and keyboard typing etc to detect spammer.

[Ray]

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.

[Ray]

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.

[Ray]

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.

[Ray]

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.

[Ray]

I would recommend trying a factory reset first. Make sure to keep a copy of your configurations so you can import them later.

[Ray]

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.

[Ray]

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.

[Ray]

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.

[Ray]

We do sell these in our online store:
https://opensprinkler.com/product/screw-terminals/
It’s of type HT3.96-2P

[Ray]

First, 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.

[Ray]

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.

[Ray]

@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.

[Ray]

@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.

[Ray]

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).

[Ray]

The missing tools folder is an oversight on my part — I’ve now committed it to the respository.

[Ray]

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.

[Ray]

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).

[Ray]

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.

[Ray]

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.

[Ray]

a) Remote editing of programs through Blynk is NOT supported at the moment, this is mainly because the program editing interface is quite complicated and would require a lot of Blynk widgets to make it work, probably not worth it. At the moment you can start an existing program remotely through Blynk but not editing it.

b) If there is a power failure while a zone is open, Bee will not be able to turn it off because Latching valves can stay in the same state indefinitely. For that reason you can consider using a USB power bank or something that can provide backup power when there is power break. All program settings are saved in the flash memory so they will always be preserved over power break. The question really is if a program was running and power was cut off, it would not be able to stop the zone until the power comes back. Everything else, like WiFi settings, program settings, are all saved on flash memory.

c) You cannot mix latching and non-latching on the same controller. But, you can mix and match if they are on different controllers, by using the ‘Remote station’ or ‘HTTP station’ feature. This way you can have a non-latching OpenSprinkler 3.0 control a latching OpenSprinkler 3.0 or OSBee.

d) I am not sure what you mean by ‘can only use one valve at a time’ — you can open multiple zones simultaneously.

[Ray]

A quick update that DarkSky seems to have extended their API support by another year to the end of 2022:
https://blog.darksky.net/

[Ray]

Sorry, the change hasn’t been made yet, it requires both firmware changes and app/UI changes to go together. Also, rev 8 is mainly for adding support for OpenSprinkler Latch 3.2.

[Ray]

I’ve seen a few reports of iOS app having this issue, but not heard of Android having this issue. What’s the version of your Android operating system? I suspect this is an app permission issue. You can always set location by using a web browser, either your mobile phone’s web browser or a laptop/desktop browser. The location only needs to be set once.

[Ray]

How many times did you set it to repeat? If the first start time is 23:00, it’s likely the second run will go over to the next day. Depending on which firmware you have, the earlier firmwares may not support repeating start times that go over to the next day.

[Author]

Posts