Forum Replies Created
-
Posts
-
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.
The first thing to check is at the homepage, see if the time displayed there matches your local time. If not, make sure you set the location correctly. Go to Edit Options -> System, there you can set your location.
Next, check if you may have a rain sensor enabled. If so it’s possible that the program got skipped because the rain sensor was activated at the time it was about to start.
It’s relatively common to wire a rain sensor in series / inline on the COM wire. A typical rain sensor is normally closed, and it opens / breaks circuit when rain is detected. So when it’s put in series on the COM wire, it will break the circuit when rain is detected.
So I looked into this issue, and it seems that if you have 1) provided a WUnderground API key, and 2) selected a specific PWS station; 3) chosen ETo as the algorithm, then you will get a WUnderground Method Not Supported Error. But if you didn’t select a specific PWS station, instead, you just selected a GPS location, then it will fall back to WeatherKit and calculate ETo using that. This is indicated in the System Diagnostics, where it will say the weather data is powered by Apple.
We will be looking into getting ETo and PWS supported. If I remember correctly, partly the issue in the beginning was solar radiation is not guaranteed by PWS, in fact, I just did a few tests, and it’s true that some PWS stations don’t provide solar radiation data (the value is null). But I agree that for those that do provide this data, it should be possible to use ETo. We will look into this.
As described in the release notes:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/releases“The event when a master zone is turned on has been added to MQTT, IFTTT, and Email notifications.”
Currently it does NOT send notification when master is turned off. There are two reasons: 1) this is added mainly to address some customer’s requests that they want the ‘master on’ event to be sent on MQTT in order to trigger other actions; the ‘master off’ event doesn’t matter; 2) it was easy to change the firmware to add support for ‘master on’ event while ‘master off’ requires significant more changes. This is mainly because the way master zones are implemented are different from regular zones, and unlike regular zones, master zones don’t appear in the running queue, nor do they have scheduled duration, their on or off status is completely determined on the fly by other zones’ statuses. For that reason, we didn’t add ‘master off’ but this can be added in the future.This is a v3.3 board you bought from us or did you make it yourself? Do you have the 32.768kHz crystal connected to your PCF8563? Without the crystal the time will not move.
We plan to address this in the next version of OTF library. Currently the incoming request is read into a 2K buffer, which is more than sufficient for most requests. Of course if Cloudflare adds a lot of extra header it can quickly exceeds the buffer size, we just didn’t know it could be a very large buffer.
