Forum Replies Created
-
Posts
-
I honestly have no time to work on this. During the pandemic we lost all employees, and I have a new born baby, so life is busier than ever before. The entire project is open-source. If you can, you could find a programmer to help you implement any new feature you want.
US Solid make a variety of motorized ball valves. Some of them are AC/DC auto-return 2-wire type, which can be directly used with OpenSprinkler.
Sorry, I think I misunderstood your question. Well, you can see each part of the calculation from this article, which explains how Zimmerman algorithm works:
https://openthings.freshdesk.com/support/solutions/articles/5000823370-using-weather-adjustments
the ‘Summary of formula’ under Zimmerman method shows the sub formula for each of temperature, humidity, and precipitation.You can check this information in System Diagnosis. At the homepage, swipe left to right to open the side menu, then ‘System Diagnostics’. It will show the weather data used for calculating watering percentage.
5V is the highest that can be tolerated on the sensor pin. Normally it should be 3.3V but the hardware has current limiting resistor and zener diode on the sensor pin to clamp the voltage to 3.3V.
Please report your hardware version and firmware version. Without the information it’s difficult to help.
What’s your firmware version? Please always report the firmware version as different firmwares have different configurations.
You can just delete your existing firmware folder, and follow the instructions to install firmware from scratch.
The weather scale is never calculated on the OpenSprinkler controller itself. It is always calculated on the server. As you said, the server call itself was successful as it returned information, but BadWeatherData means parts of the weather data for your location is missing. For example, if it needs 24 hours of data and the weather data contains less than 24 then it will trigger such error. You can try to change your location slightly and try again.
I don’t think you can have it pre-configured because each power socket has a different RF code and no commercial product will have the RF code marked on the product. If you don’t want RFToy, you can use an Arduino and RF receiver to assemble your own RFtoy.
@v1pr: as I said, those functions in OpenSprinkler::start_network only create various objects and initialize them, AP does not need to be started at that point. In any case, I’ve never observed ESP8266 crashing due to this. Is this causing ESP32 to crash?
@v1pr, you said “Logically this should not work on the original esp8266 either…” — I don’t understand what this is referring to. Did you mean some line of code should have appeared before some other line of code? If i had to take a guess: note that creating ESP8266WebServer merely creates the object, it doesn’t do anything yet and certainly does not require having WiFi ready at that point. Same with creating the OpenThingsFramework object. The WiFi AP started at this line of code:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L463
The otf->loop() function does the house keeping of responding to WiFi web requests. AP needs to be started before that, which is the case with the code.I have not followed this thread closely because I haven’t compiled the firmware for ESP32. But the OTF library is designed to support ESP32 as well.
A lot of our customers run fairly big facilities that need more than 16 zones. If you just want to control sprinkler solenoids and have no need for sensors or wired Ethernet it’s certainly possible to compile a version of the firmware to control 4 zones. But our controller is designed to accommodate two independent sensors and support wired Ethernet, so there aren’t even 4 spare GPIO pins left on ESP8266. You might be thinking moving to ESP32 saves some cost? But ESP32 itself is more expensive than ESP8266. The only thing ESP32 would save is an IO expander (PCA9555) and thats not that expensive.
If the service is running currently, you cannot run ./OpenSprinkler as it will report failure to initialize network. You will need to stop the service from running, then you can run ./OpenSprinkler (you need to either be root, or use sudo ./OpenSprinkler).
Are you trying to do this for ESP8266 or Rasbperry Pi? OpenSprinkler 3.x which is based on ESP8266, already support PCA9555/PCA9535, which is an I2C expander similar to MCP23017 but cheaper.
Can you give more specifics? What do you mean by adding I2C support? OpenSprinkler 3.x already supports I2C. Did you mean a specific I2C device?
The OpenSprinkler firmware currently does not use I2C for OSPi at all. There is no hardware conflict — the I2C pins are free to use by any I2C device. You may want to write a small and separate program just to test the I2C functionality, such as using wiringPi to detect MCP23017 to make sure the wiringPi I2C functions are working properly. I have no experience with using wiringPi for I2C so I don’t have any advice. Also, make sure I2C is enabled in your RPi configuration.
Ok, I see what you mean. Honestly this is going to be quite complicated to implement, because each different weather algorithm has their own set of parameters, so to account for all of them that would require keeping track of different sets of parameters for each zone. It can be done it’s just complicated and not sure how many users need this.
Probably the easiest workaround is to split your program into multiple programs. Those that should be affected by weather algorithm are in their own programs, and those that should not be affected are in a different set of programs.
