Forum Replies Created
-
Posts
-
Our German distributor, Stefan, does still have a few latch expanders. Latch expander MUST be used with latch main controller — non-latch main controller does NOT have the internal circuitry to operate latch expanders. You can contact Stefan to see if he has a latch main controller that you can swap with, or as I said, you can send a support ticket to us and we can sell you a latch driver board. You just need to replace your main controller’s driver board and it can become a latch controller.
1) You can submit a support ticket at:
support.opensprinkler.com
and arrange to purchase a Latch driver board. It’s a lot cheaper than buying a new controller and you can replace the driver yourself. This way you can reuse the same logic board and enclosure.2) There is no easy way to modify the DC driver board for latching valves. Latching valves require an H-bridge to operate because you need to be able to reverse the polarity when opening vs. when closing, which the DC driver doesn’t have. At best, some latching valves have 3 wires in which case it can take 2 ports on DC controller to operate. Still, even that requires a firmware update, which is probably not worth your time.
3) We no longer sell latching expanders — the demand for latching controller is very small to begin with. It make no economic sense to carry latching expander any more. You can NOT use DC expander for latching valves, again, because the way they work is quite different.
That’s a good call: stn_seq has been removed since it has been replaced by stn_grp. I will fix the document.
Allowing arbitrary reordering of zones in a program would require substantial changes to the program data structures as well as the UI design. This is not something that’s easy to do at the moment, not because it’s technically difficult, but because it involves a lot of changes to the program data structure and UI, and making them backward compatible is hard.
But, some limited support for reordering is coming up in the next firmware, as I explained here:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/issues/232#issuecomment-2256420560
it’s not arbitrary reordering, but it give you a few options to run zones in forward or reverse order of zones indices, forward or reverse order of zone names, alternating (i.e. program’s first run in forward order, second run in reverse order etc.), and completely random ordering.If you have been looking for an arbitrary reordering of zones feature in a sprinkler controller, that means it’s not a common feature — on traditional sprinkler controllers, you just name a set of zones and the water time of each zone, and it waters them in the order of the station index. I haven’t seen a sprinkler controller that allows arbitrary reordering of zones.
Although the firmware code is written in C++, it mostly uses C only features.
In addition, you can always use a script to send command to OpenSprinkler to run zones in any way you want.
The PoE support issue is a hardware issue — it’s because the wired Ethernet module, which is an off-the-shelf part, uses a Ethernet jack that’s not compatible with PoE. This is not something updating firmware can resolve.
One issue we see once in a while is switches or routers that have PoE(Power over Ethernet) turned on. The OpenSprinkler wired Ethernet module is apparently not compatible with PoE so make sure it’s not turned on at the router/switch that OpenSprinkler is plugged into.
You want to use DS1307 or PCF8563? With DS1307, it has dedicate battery backup pins, so the backup battery voltage doesn’t have to be the same as the supply voltage. In fact, you don’t need to use a supercap, you can use a 3V lithium coin battery, connect the positive to DS1307’s VBat pin, and negative to ground. That way you don’t need the diode and the super capacitor.
Can you be more specific about ‘to operate from higher voltage’ — as in to power the RTC chip from a higher voltage? How high?
At the homepage swipe left to right to open the side menu then click About. It shows the firmware version including minor.
Also you can open defines.h in the source code folder and it shows the firmware version at the beginning of the source code.
Do you know which minor revision are you on? The currently released firmware 2.2.1 is minor revision 0, and GPIO23 is still in the free pin list:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/defines.h#L444If you are somehow on the 2.2.1 minor revision 1 branch: that’s an un-released firmware, where pin 23 is used for a button so is no longer in the free pin list.
To verify if it’s indeed the issue with diode D2, you would have to desolder it from the board and test its forward voltage drop. The diode is very robust so it’s quite rare for it to fail. I suspect the issue might be somewhere else, like a shorting somewhere else that’s causing an over-current situation with D2 and hence it becomes hot. I recommend you to measure VIN (i.e. +5v) to GND resistance. It should be a minimum of 4 to 5K ohm. Otherwise something on the +5V line is shorted.
1) What firmware are you using? The OpenSprinkler firmware, or your own program?
2) Is your super capacitor charged to at least 2V, so that it can keep the RTC chip going when power is off?I just verified that with the current OpenSprinkler firmware, power on, NTP sync, then power off, keep the unit away for 1 hour and power it on again, the LCD shows the correct time right away before NTP sync. So it’s working as expected.
Well the Remote Station (IP) is never intended to be used with secure port, because it’s generally used for controllers on the same network. In this case it’s usually not necessary to use secure connection unless if you are worries someone is logged onto your network and sniffing traffic (which would seem a bigger issue if they managed to get your WiFi password).
If the master and remote controllers are not on the same network, the Remote Station (OTC) type would be more appropriate as it goes through the secure cloud server — that is intended for controllers NOT on the same network hence secure connection is necessary.
The firmware already does this. Handling of rain sensor is in a function called process_dynamic_event, it applies to all programs regardless of whether it’s a program that just started or a program that has started for some time:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L1200
However, it will be ignored if the program is a manually started program (i.e. not a program that automatically started by its start time), and it will be ignored for zones that are set to ‘Ignore Sensor’.You can implement this feature. There is no technical barrier: you can write the log information to a file, and have a http end point similar to /jl and /db to print out the log information. Probably the biggest constraint is that there is not much flash memory space: there is only a total of 2MB spare flash memory, which has to be shared by the data files, regular log files. The more debug log file takes, the less space it is there for the regular log files.
Another option is to send debug information through MQTT: as the firmware already supports MQTT, just set up a MQTT broker on some computer, and send debug information through that. This takes no flash memory space and is relatively fast.
You can send a support ticket at
support.opensprinkler.com
and ask for a version of the OpenSprinkler logic board that has external antenna plug. It will come with ESP-07S WiFi chip:
https://www.rfsolutions.co.uk/downloads/6253e9bcb090a456DS-ESP07S-1.pdf
and you can buy a WiFi antenna yourself and plug it in. Please note that ESP-07S has no PCB antenna, which means it must use an external antenna, otherwise it won’t be able to connect to your router at all.Other than the WiFi signal reported as poor/unusable, are you experiencing problem connecting to the controller? If you can still connect to the controller, I don’t think you need to bother with the antenna.
Normally when you use the remote controller feature, you have one controller dedicated as master controller, the other remote controller. That way you can map all zones on the remote controller to virtual zones on the master controller. For example, in your case, you can set your master controller to have a total of 8+24=32 zones, even if it only has 8 physical zones. Then you defines its zones 9 to 32 as remote zones on the remote controller. This way, all zones are operated from the master controller, and since the pump zones is also on the master controller, when any zones opens, the pump zone opens as well.
The way you have set up is also fine. Yes, it seems a bit awkward to carry the password and explicit duration. But that’s mainly because you are not use the remote zone feature, which would have managed the password and duration implicitly (by requiring the master and remote controllers have the same password, and the duration is sent automatically when a zone opens).
Another way, which we haven’t tested rigirously but should also work in your case, is to define your second OPSi’s master as a remote station, which maps to the first controller’s phantom master zone. The UI would set the first controller in remote extension mode when you set this up, but later you can access the first controller and simply remove it from remote extension mode. The good thing about this approach is that since it uses remote zone feature, password and duration are sent automatically. The downside is that if the first controller is independently running the master zone, while the second controller is sending a command to do something different, it may lead to master zone status that’s different from what you expected.
The limit was only an issue on OSPi, because the previous firmware had a poll function that uses a 50ms timeout. On OS 3.x and 2.3, there is no such poll function, so it doesn’t affect them.
Ah, sorry for not being clear: email is NOT supported on OS 2.3 (AVR microcontroller). This is because email notification requires secure HTTP connection, which is beyond the capability of OS 2.3.
The firmware can already accepts BSSID. At the WiFi configuration page, you can see it has an input for BSSID, which is automatically filled when you select a detected network, or you can manually type it in, or you can leave it empty so it will automatically connected to one of your routers that share the same SSID and password
To be honest, to address your issue you might want to consider having a secondary router that’s dedicated to OpenSprinkler, with a different SSID than your main network. Or, you can use wired Ethernet connection which can eliminate WiFi issues completely.
Attachments:
The firmware does NOT log the reason why a program was skipped. It only logs actions that have happened, not those that did not happen.
If your program was set to ‘Use Weather Adjustment’ and the watering percentage happens to be 0, then the program won’t run. It sounds like your program initially was set to Use Weather Adjustment, and you subsequently removed that options. So perhaps it didn’t run because the watering percentage was 0 that day.
I am really confused by your description. You said “It ran as expected, at the expected time” — that sounds like after you changed the time and disabled weather adjustment, the issue is fixed, is that correct? Or did you change the time before you discovered the issue?
1. I am not sure how a program is supposed to log a record if it didn’t run — in your case, if the time was incorrect, it would not be running the program at your set time. This is not because the program was skipped for any reason. It’s simply because the device time was different from your wall clock time. How is the program supposed to log a record in this situation?
2. The firmware checks if the current minute matches the program’s start time, so it has a full 60 seconds to detect if a program should run at this minute or not. Even if the WiFi signal is weak, it won’t take more than 5 seconds (the http request has a 5-second timeout) to get back a result, either success or failure. Also, weather update is disabled if a program starts running, so as soon as the program starts running, weather update will wait till the program finishes running.
“UserManual says it logs “zone runs as well as rain delay, sensor status changes, and watering percentage changes.” .. which makes this all the stranger (to me)” — can you articulate which part of it is strange to you? ‘Zone runs’ are logged when a zone finishes running. If a program didn’t run, that means zones didn’t run, so it won’t log any record, right?
The LCD icon just indicates it’s connected to WiFi, it doesn’t indicate the signal strength. That icon would be either 4 bars (indicating it’s connected to WiFi), or 4 bars with a cross (indicating it has no WiFi connection).
The signal strength is a dynamic thing, it may not stay the same all the time. Does it persistently report Poor/Unusable? It may improve over time.
You can get an OpenSprinkler top-level logic board with a WiFi antenna plug, if you want.
