Forum Replies Created
-
Posts
-
1. yes, it should work with OpenSprinkler. The output of this soil clik sensor is a relay which is a dry contact type.
2. no, this soil sensor is not a dry contact type, it requires an additional microcontroller to ‘interpret’ the result of the soil moisture value. It cannot be used directly with OpenSprinkler.
3. please read the OpenSprinkler user manual to understand how sensors work with the controller. Soil sensor and rain sensor work in the same way — when a program is scheduled to run, it checks the sensor value and if it’s activated then the program will not run. More specifically, zones that are set to be affected by sensor will not run if the sensor is activated.I want to explain that the reason we stopped selling latch expander is that there are fewer than 5 orders of latch expander each year… So it makes no sense for us to continue stocking it. One work around is to buy another latch controller and set it in remote extension mode so it basically works as an expander for your main controller, albeit not physically attached to the main controller. Hope this makes sense.
The web version of the app is hosted at ui.opensprinkler.com
When you access the controller directly in a web browser, it returns a homepage that contains re-direction link to the above site, so the browser can load the web UI from there.
The mobile app is the same Javascript code that is wrapped into a native app. The appearance is the same.
The UI looks different with different firmware because each firmware supports different sets of features and the UI detects your firmware version so that it enables or disables certain UI elements accordingly. For example, OpenThingsToken (OTC) is only supported from firmware 2.2.0, so it doesn’t make sense to show this option for firmwares earlier than 2.2.0.
The firmware itself provides HTTP API to interact with the app / web UI. You can go to support.opensprinkler.com and check the OpenSprinkler HTTP API to check the details.If I remember correctly, flow volume is the flow count multiplied by the pulse rate (basically number of clicks multiplied by volume per click). Flow rate is the flow volume per unit time. In this case, the flow rate is flow volume per minute:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L1422I would say 50 pulses per second is really quite high. A lot of the 2-wire water meter probably only generates 50 pulses per minute, not per second. Due to the way the flow count interrupt routine is implemented, ideally the click count should be less than 10 clicks per second. Not sure if you can get a different sensor that generates less clicks. Usually those that are meant for higher volume flow rate will produce less clicks per second.
The unit doesn’t really matter. By default it uses metric I think, so you can just ignore the unit and thus only the number itself matters.
One issue with using all GPIO pins is that some pins must be held at certain state during power-on, while others can have a moment of glitch during power-on. For example, GPIO2 must remain high at power-on, GPIO15 must be low, and GPIO16 starts as high but flickers for a couple hundred milliseconds. So these GPIOs, when connected to relays, can produce moments of false action of the relays, albeit this only happens at power-on or reboot. If this can be tolerated, then you can use all GPIO pins.
Ah, ok, I will check, it’s probably part of the code that sends data to IFTTT. Again, this is usually a sign the click count is excessively high.
Yes, I do have plans to switch to ESP32 at some point. The ample GPIOs won’t make a huge difference because we will always need to have expanders, therefore how much GPIO the main controller has is irrlevant as the expanders cannot use GPIO pins from the main controller. The extra GPIOs do help with enabling more sensors especially analog sensors.
ESP8266 also has versions with external antenna plug (ESP-07S).
We haven’t moved to use ESP32 mainly because it takes time to develop, test, and get familiar with a new microcontroller. With ESP8266 we are familiar with it, know the quirks. Also, since the firmware files for both have extension name .bin once we switch to ESP32, there needs to be a good way to make sure users download the correct firmware (i.e. they need to know whether they should download the one for ESP8266 or ESP32, since the files have the same extension name). This is rather difficult to make sure as uploading the wrong firmware can jail the controller.
Regarding expander: NO, you can NOT use a AC expander attached to a DC controller. It won’t cause any hardware damage but you will find that zones on AC expander can only turn on but not turn off. This is because of the way AC transistors work.
There are ways to make a universal expander that works with both AC and DC. That is by using solid state relays (SSRs). But solid state relays are significantly more expensive than traics or MOSFETs, I mean the price difference is in the range of 20 to 100 times. I don’t think it makes economic sense to go with that option.
Sorry, still trying to track down the problem. We’ve got a surge of orders and several other things (including OTC connection) so we are a bit overwhelmed at the moment and things are progressing slowly. To be honest, I was hoping someone with programming skills can take a look at the weather code and perhaps point out something they find. My suspicion is that either it’s due to the ET part of the code pulling different API from weatherkit, or its a unit conversion problem. We will try to resolve it as quickly as we can.
The main OpenSprinkler (ESP8266) code has been changed to adopt platformio, which makes compilation a lot easier. Just install platformio, install the extension, and compile. The ESP32 version could also use the same approach.
Unfortunately the three wire sensors are difficult to read reliably. Part of the problem is they generate too much click counts per minute. Also there are too many different types we can’t possibly test the controller with all of them.
Negative values are probably a UI bug, because the read count is stored in a unsigned integer variable so cannot possibly be negative. It must be the UI when its displaying the data changed it to signed integer hence negative.
The 2 wire type sensors are more expensive but are more reliable because they generally much less click counts per minute.
Sure, this can be easily changed to provide an option for you to switch. I just didn’t think the OLED display is that important since most of the time users just look at their mobile app or web UI, most won’t go to the controller physically to check it.
Can you point to me where you mentioned snubber, antenna improvements? I saw that you mentioned DS1306, interesting, I didn’t know the existence of DS1306. DS1307 has always been the most popular RTC, though I’ve changed to use PCF8563 due to its lower cost.
Well, if I had a RPi 3b or 4 I can test. But I don’t know anywhere to buy them. So I rely on users to report. So far I haven’t seen any report of issues.
I am pretty sure it works. There was an issue with sensors not working due to wiringPi discontinued, but that has been fixed. I am not aware of any other issue of the firmware with Rpi.
Can you file a support ticket with your configuration file attached? We need a specific location to track down this.
1. The sensor/switch only triggers a program to run once and the duration depends on the program’s duration multiplied by the weather adjustment if weather adjustment is selected for that program. After the program finishes running, if the sensor/switch is triggered again it will run again.
2. I checked the code
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/OpenSprinkler.cpp#L1314
I am pretty sure the program only triggers when the sensor/switch goes from high to low (or low to high if the reverse logic is selected). So unfortunately the program does NOT continue to run if the sensor remains activated. It’s only triggered when the switch has a status change.The main reason we made everything open-source is so that users can customize the firmware for their own need. Many users have all sorts of different need and it’s impossible to design one firmware to fit everyone’s need. I understand not everyone has coding skills, but there is only that much we can do. We can’t possibly address everyone’s need.
To modify the program to fit your need, that ‘detect_programswitch_status’ function is basically what you need to modify. So instead of detecting sensor status changes, probably just detect if the sensor remains in one state.
This line is where that function is being used to trigger a program to run:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L686We will check, but I guess Zimmerman and ETo pulls different data. Zimmerman uses today’s weather data, ETo uses history data, which could explain the difference.
The sensor/switch function is independent of weather algorithm. Sensor/switch controls whether a programs runs or not. The weather algorithm controls the water duration. Currently the firmware does not support what you need (i.e. program starts when sensor 2 turns on and ends when sensor 2 turns off). You can certainly implement this function yourself, the entire code is open-source.
