Forum Replies Created
-
Posts
-
Perhaps you can submit a support ticket with your specific domain names (unless if you are willing to publish them on the forum here), so that we can take a further look at the issue?
To understand the issue, did you mean that neither “sprinklers.mydomain.com” nor “mydomain.com:1000” works in the app?
Yes, we are aware of this. It seems reliable and relatively low-cost weather services don’t stick around very long. They get acquired by big companies left and right. Yes we will probably have to look into another weather service. Prior to adopting DarkSky we have used OpenWeatherMap for a while — it was ok but people have complained about the data accuracy. We will have a year to figure this out and find an alternative.
Ah, I didn’t realize the device is OSPi — yes, for OSPi the time is managed by Raspberry Pi. I am not sure why it didn’t get the time correctly, possibly having to do with how your RPi was configured.
As long as there is Internet connection, the controller will attempt to obtain time automatically from online when it reboots, and also every 24 hours after that. What version of controller do you have? WiFi or wired Ethernet? You can also set time manually if you go to Settings, empty out location (temporarily, you can always put it back afterwards), and in ‘Advanced Settings’, un-check “NTP sync”. Save settings, then the ‘Time’ should become editable, so you can set time manually that way.
Look, if it’s not already obvious to you: I honestly don’t know why this issue happens on your side and I can’t explain it. I have a test OS 2.0 loaded with firmware 2.1.7, I cannot reproduce the issue you reported. I checked the code that handles RTC in version 2.1.7 vs. 2.0.4, they are exactly the same. I really, really don’t know how to explain what you are seeing. I asked you a question to check the part number of the RTC on your circuit board, you have not replied. You can beat me all you want, but if I knew anything, do you think I would hide it from you?
I am not sure why you had to open up port 123 — are you turning on firewall and blocking ports? Otherwise why do you have to open up port 123? I never had to do it and that’s not a necessary step in the setup.
As far as I am aware, firmware 2.1.7 handles both types of RTC that we’ve used previously:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/49f0c3dd8ce5501ae88b810412ecd5e157754aa3/DS1307RTC.cpp#L40
so I honestly can’t explain the symptom you are seeing. As I said, I have a test OS 2.0 and I don’t observe any RTC issue as you reported. If you suspect it’s the RTC, can you take a look at the RTC you have on your board and find out the part number?What’s the I2C address configured by your PCF8574 module? Note that it has 3 bits that you can use to set the I2C address (if I understand correctly, these would be the 3 yellow-colored jumpers on your module). It’s not clear to me whether you are following OS 3.0, 3.1 or 3.2 schematic. Only 3.0 uses PCF8574 (whereas 3.1 and 3.2 use PCF9555 16-channel IO expander). So assuming you are following 3.0 schematic, which is available here:
https://github.com/OpenSprinkler/OpenSprinkler-Hardware/tree/master/OS/3.0/AC_driver
it assumes that on the AC driver board, the three bits are A0=1 (high), A1=A2=0 (low). You need to set the jumpers correctly to match this address.These pins are defines in ‘defines.h’. You can change them to some other GPIO pins, to free up GPIO 14 and 15.
I have a test OS 2.0 loaded with firmware 2.1.7. I’ve run it for a couple of hours and I cannot reproduce what you said about timing issue. Look, the reason I said you should consider downgrading back to 2.0.4 is so that you can have a point of reference: if the timing issue is gone after downgrading to 2.0.4, then it says something about the difference between the two firmware. I didn’t tell you to abandon your efforts. Instead, doing so can help rule out the possibility that the RTC or RTC battery may be the root cause. I have no idea why you are so persist at not downgrading to 2.0.4 — this is for the purpose of debugging and isolating problems so we can narrow down the problem. If after downgrading to 2.0.4 you still experience the timing issue, then the problem is not in the firmware, it’s somewhere else.
Also, this is a community forum, this is not the support system. We sometimes don’t check the forum on a regular basis, understanding that this is a place for users to assist each other. Especially now I am sure you know there is a pandemic going on, we are short staffed and have many things on our plate, I don’t think you should expect any immediate response on this forum. However, if you have a technical problem that requires urgent response, send a support ticket. The reason it’s hard to provide support through forum is that we need to ask you for your order number, sometimes asking you to export your configurations, your shipping address, etc which I am sure you don’t want to post on a public forum.
Finally, I politely ask you to keep your post concise and to the point. That will help us get to the bottom of the issues quickly. Complaining about a bunch of stuff in a single post doesn’t help us understand what are the main problems or provide any motivation for others to help (especially since your purchase was from almost 7 years ago, which is way out of warranty).
As I said, a resistance in the range of 20 to 50 ohm is normal. Since you measured 40 ohm, it is ok and it shows your solenoid is NOT latching type (i.e. your solenoid is non-latching type). At any rate, as I suggested, you should measure voltages after solenoids are disconnected — so the resistance of the solenoids doesn’t matter in that case. When a zone is turned on, the voltage between COM to that zone port should be slightly lower than the input voltage. If not, I suggest that you submit a support ticket — a zone, when turned on, should output the input voltage minus a couple of volts; if not, I can’t explain it, and it’s best if you send it back to us for checking.
The maximum per controller is 72 zones. Regardless of whether some zones are remote or not, they all have to occupy zone and program memory, so the maximum is 72.
The advantage of using relays is that they isolate solenoids from the controller, so in case something wrong happens on the solenoid side (i.e. hit by lightening), the isolation helps protect the controller.
First, disconnects the solenoids wires from the controller (you can simply remove the common wire, which effectively disconnects the solenoids from the circuit). Make sure the solenoids are the correct type, this can be done by measuring the resistance from the common wire to each zone wire. The resistance should be somewhere between 20 to 50 ohm. If it’s too small, your solenoids may be of ‘latching’ type, which is not compatible with DC-powered OpenSprinkler.
Next, with the solenoids disconnected, and the controller powered on, measure voltage from VIN to GND, this should be 5V. Earlier you said it’s between 3.5V to 5V. If it’s noticeably below 5V, something is wrong — it should be a fairly stable 5V.
Then, turn on a zone (e.g. zone 1), and measure voltage from COM to that zone. This should be slightly before your input voltage. For example, if you use 12V DC power supply, this voltage should be maybe 10 to 11V. It’s important that the solenoids are disconnected when you measure this voltage, otherwise, if the solenoids have a shorting, or are of the wrong type, it would interfere with the voltage measurement.
Since you have DC-powered OpenSprinkler, please note that you should only measure DC voltage and DC current — because the controller outputs DC-only voltage. So “0.02V AC” doesn’t mean anything because the controller does NOT output AC voltage.
VIN always outputs 5V — the VIN pin is for powering certain sensors, NOT for solenoids. You should be using the COM (common) pin, as the user manual clearly states. So each solenoid should have one wire that goes to the COM, and the other wire goes to an individual zone port.
Also, VIN is NOT (I repeat: NOT) for input voltage — as the user manual clearly state, the input power should be supplied through the black-colored power barrel. I’ve seen at least one case where the user tried to feed 12V to VIN, that caused damage to the controller.
The way DC-powered controller works is by generating a high impulse voltage to energize the solenoid, then lower it to input voltage to provide holding current. When you use 12VDC input supply, that means after a zone is turned on, at stable state, the voltage measured between COM and that zone should be roughly 11VDC (a bit lower than 12VDC).
This frankly would be quite difficult to implement. The device key is currently authenticated on the controller. In order to manage multiple users, it would be necessary for the controller to handle multiple levels of user authentication. This would involve significant changes.
Please, stop creating new forum posts about the same issue. This only makes it difficult for us to keep track of your questions.
First of all, since you said your device is OS 2.0, make sure you uploaded the correct firmware. Firmwares for hardware version 2.0 are available here:
http://raysfiles.com/os_compiled_firmware/legacy_os/v2.0/
If you are sure you used the correct firmware file, and you suspect firmware 2.1.7 is causing the NTP problem (which I am not aware), why not try to flash it back to your original firmware 2.0.4, it’s available in the folder. You can flash the controller to any version of firmware.How do you think the UI allows you to change the attribute of a single station? It reads the current status (/jn), changes a bit of it, and sets it back (/cs). That’s how the UI does it. Rudimentary programming exercise. At the minimum, perhaps you can Google about “how to set a bit in an integer”? This is really basic programming stuff. If you insist on writing your own script to do it, then I would assume you have sufficient programming skills to implement this.
If you want to add the capability of changing a single attribute at a time, why not just change the firmware and add that feature. The source code is completely open, you can modify it any way you want.
Sure, please reply to whichever last email you are referring to so that we can continue from there and arrange for a support request.
From the result you are getting, it does seem the device password is no longer the default ‘opendoor’ for some reason. I am not sure how this is possible, especially since you said you’ve done a factory reset.
The only other thing I can suggest trying is to ignore password, and see what happens. To ignore password, use the following procedure:
– power off the controller, then hold the third pushbutton (B3) while powering it back on. Continue holding B3 until the LCD shows “Setup Options”
– click B3 as many times as you need until you reach the “Ignore Password” option.
– use B1 or B2 to change the value to ‘Yes’.
– Press and hold B3 until the controller restarts itself. At this point, the change to that option is saved and the controller should now ignore password. See if this allows you to log in.Please, take a look at the API document:
https://openthings.freshdesk.com/helpdesk/attachments/5114870617
page 5, section 10, where it explains the /cs command. It clearly says there are parameters such as q? (i.e. q0, q1, q2…). And it gave a few examples such as setting m0 (the bit fields for the first 8 zones). I don’t know how to continue explain this if you don’t read that section carefully.xx in my post just means a placeholder — it’s an integer, it could be anywhere from 0 to 3 digits long (0 to 255). It doesn’t mean two bytes.
As the API document clearly shows, the JSON variable names returned by /jn and the parameters you set through /cs do NOT have the same names. For example, the master operation bit fields returned by /jn is named “masop”, but to set this through /cs, you use m? (e.g. m0, m1, m2…). The reason they are not the same is due to backward compatibility reasons — the names were like this from several firmwares ago and we didn’t want to change them completely to break the previous versions of hardware and firmware.
In your example, the result of settings m0=1 is to set the first zone’s master operation bit to 1 (enabled), and the other 7 zones to 0. Similarly, if you do m0=255, it will sets the master operation bits for all first 8 zones to 1.
So it looks like the “loc” location string is corrupted for some reason. You said you have performed an explicit factory reset (i.e. not the reset triggered by firmware update, but rather, you manually perform a factory reset), and this is happening right after that? I am puzzled and don’t know how to explain this.
Maybe you can check the microSD card in the controller — firmware 2.1.9 stores all settings and programs on the microSD card. So if there is an issue with the card, it could result in corrupted data. The easiest way is to re-format the microSD card, or replace it with a new one. See if this helps resolve the issue.
First, I suggest that you split your command into separate commands. There is no need to put all changes in one command. You can do:
/cs?pw=xxx&sid=xx&st=xx&sd=xx
first to set the special station attribute of that zone
and in a separate command you can do:
/cs?pw=xxx&q0=xx&m0=xx
to set sequential bitfields, and master operation bitfield. Please note that the /cs command has no parameters named ‘stn_seq’. The parameter you should be using is q0, and it’s a bit-field (i.e. it sets sequential bits for a set of 8 zones at a time). Check the API document to see the available parameters:
https://openthings.freshdesk.com/helpdesk/attachments/5114870617You said you “cannot figure out how to enable the master1/master2 flags”, can you be more specific about what’s the symptom? What’s the result you get when you run the command. If it’s successful, what did it end up changing and how does it differ from what you intended?
