Forum Replies Created
-
Posts
-
We have addressed this issue. You can try again. Reboot your controller, or temporarily change the weather algorithm to a different one and change it back to ETo. See if it works.
We just switched to Apple Weatherkit as DarkSky is no longer available and we are aware ETo is not working properly. We will be fixing it asap. Thanks for your understanding. In the meantime you can temporarily switch to Zimmerman method.
That’s really strange. It sounds like the power adapter is failing and cannot provide enough current. You can try a different DC power adapter. Anything that outputs a DC voltage that’s between 7.5V to 12V and can provide at least 1amp current should work.
This is usually a sign of a solenoid problem. Such as a shorted solenoid or a shorted wire. To diagnose, remove the common (COM) wire and see if this still happens.
Which javascript bundle are you referring to?
In most cases you don’t need to change the javascript url anymore. You can download the app repository, unzip it, then open index.html in the www subfolder. This is how we test and debug the app UI.
We’ve already switched to Apple Weatherkit. Apple bought DarkSky. It’s fairly easy to make the transition.
It’s clearly a 24VAC system. So go with AC-powered OpenSprinkler.
If you just have sprinkler valves and no pump start relay, the DC-powered OpenSprinkler should also be able to work with your sprinkler valves.
OpenSprinkler 3.x uses ESP8266. ESP8266 doesn’t have quite enough GPIO pins that’s why OpenSprinkler uses PCA9535 IO expander chip.
1 -> go to Edit Options, Advanced tab, make sure the ‘Special Station Auto Refresh is turned on’. The refresh is every 2 minutes I believe.
1. If you turn on 4 zones at the same time, chances are due to network traffic issues some of the remote commands may be lost. That’s why the firmware has a feature that periodically refreshes the command to make sure the remote is in sync with the master. If you can stagger the simultaneous zones that would improve the situation.
2. This is expected: once a controller is set as Remote, you are NOT supposed to turn zones on or off on the remote controller — the communication from master to remote is one-way, the Master controller cannot see changes you made on the Remote controller directly.The only types of soil sensors supported are ones that are dry contact type — they are basically like rain sensors, when the moisture level exceeds some threshold it outputs high (or the contact switch closes) and otherwise it outputs low (or contact switch opens). If you have an analog sensor you can use a LM393 analog comparator module like this:
https://www.amazon.com/HiLetgo-Moisture-Automatic-Watering-Arduino
which takes in analog signal and compares it with an adjustment threshold and outputs a digital signal.The pins defines are all in the firmware code defines.h:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/defines.h#L388
assuming you have OpenSprinkler version 3.2 (previous versions use different pins, and they are all defined in the file as well). IO_EXP + ? means it’s pin number ? on the PCA9555 IO expander.Q1: please take a look at the OpenSprnkler user manual. It explains and has a diagram showing how sensors should be connected:
https://openthings.freshdesk.com/support/solutions/articles/5000716364-opensprinkler-user-manualsQ2: I am not sure how to answer this question since I don’t know how the sensor works internally. I believe as you said, when rain reaches a certain level, its contact will break and OpenSprinkler can detect the change in the sensor status.
Rain delay and using rain sensor are two different things. Rain delay is a manually triggered event, you as user can trigger a rain delay. Rain sensor is automatic: as long as the rain sensor is activated, OpenSprinkler will respond to the rain sensor status until its status changes again.
Have you watched our tutorial video:
https://openthings.freshdesk.com/support/solutions/articles/5000860920-videos-introduction-to-opensprinkler-v3
it shows how to use the controller in AP mode.If your valve does not have polarity (this is the case with AC valves), it doesn’t matter which goes to which. If you valve has polarity (i.e. there is a positive wire and negative wire), then positive should go to COM, negative goes to zone 1.
About monthly watering: please submit a support ticket with your configurations attached so we can check. We’ve internally tested it and it should be working, but maybe your monthly percentage values weren’t saved correctly.
About weather service provider: DarkSky has become Apple Weatherkit. We’ve been working on integrating Apple Weatherkit. At the same time, we’ve also been working on using AccuWeather, and also we have a contributor who implemented using open-meteo.com. So we have plenty of backup options once DarkSky is offline.
About usb serial: well, each version of OSX seems to change something and it’s always a headache to prepare the documentation to cover all possible OSX versions. I apologize for the confusion.
dun4cheap: unfortunately I haven’t used Windows for like a couple of decades… Is that really your only option? Can you not use like Javascript or something more modern?
I suppose you can access the controller with the mobile app or in a web browser, is that correct? That means the HTTP GET request is working. Why it has an issue with your msWinsock osx, I really have no idea.
Well, you are not providing enough information for us to help you. Yes, the firmware is different, of course, but I don’t know how to debug to help you. Maybe at least you can take a look at the header that your winsock control is sending out? Also the firmware code is publicly available, so you can compile it yourself and debug it on your side.
There are two places where the OTF library may throw out the 413 error:
https://github.com/OpenThingsIO/OpenThings-Framework-Firmware-Library/blob/master/OpenThingsFramework.cpp#L102
https://github.com/OpenThingsIO/OpenThings-Framework-Firmware-Library/blob/master/OpenThingsFramework.cpp#L120If you try the request in the browser, do you still get the 413 error? I feel it may have to do with you using a socket for the GET request.
Firmware 2.2.0(1) has a restriction where the incoming request header cannot be more than 2048 bytes long. Typical request headers are way less than 2048 bytes. It’s possible whatever script you are using to send the request is imposing a long header. You can check that.
I am not sure what
get /cv?pw=md5password
does. It seems to call cv with only a password but no other parameter.I honestly don’t know if there is one correct way to implement this. A slightly easier version is probably to get the watering percentage every day and calculate an average across several days and use the average number for the day watering is enabled. Another way is to calculate the average of weather parameters and compute ETo using the average weather parameters. I am not an expert in ETo, so I honestly don’t know if there is one correct way to implement this.
@Ant: yes I aware of that. It turns out that because the firmware will immediately start to connect to MQTT server when that part is imported, it will stop responding to the rest of the import request. So I am aware of why this is happening. One way to fix this is to require a reboot before enabling MQTT, but I feel probably only a small number of users would encounter this so I decided to leave it as is and let them know the work-around if this happens.
