Forum Replies Created
-
Posts
-
Attached is a notional schematic. The LEDs are shown without resistors; this is simply because I may purchase panel-mount devices with internal current regulators, possibly bipolar.
LEDs 1-8 are red, indicating the corresponding fuse (1-8) is blown or missing.
LEDs 11-18 are green, indicating that the corresponding zone (1-8, in order) is active.
LEDs 19,20 are red or yellow, indicating the corresponding fuse (9 or 10, for zone Com1 or Com2 respectively is blown. (Yes, these could be merged, and probably should be LEDs 9 and 10 anyway.)Fuses F1-F8 are 1A (ideally, about 0.5A), one for each solenoid.
Fuses F9, F10 are 2A (or as appropriate for your load configuration – the idea is that these would blow before the board fuse blows.I’m going to give this a try with blade fuses; I found a block with 0.250″ tab terminals. I can crimp the indicators into the tab terminals; I’ll just need a mounting strip for panel-mount snap-in indicators, and relatively bright indicators if the ones I find are not bipolar.
Attachments:
40 years ago early in my career I got to design both my radio circuits and my test equipment circuits. The standard for the test equipment power was a crowbar circuit- basically a zener is used to trip a triac to short the circuit, blowing the fuse. This works for overvoltage (and most references describe this), but if you put the trigger upstream of a resistor inline with the load, you can set it to trip due overcurrent – the incremental voltage drop across that inline load sets the overcurrent limit.
These were all DC circuits. So for the OS with 24VAC, it would probably need to trigger the crowbar off the current-measurement rectifier.
I am considering inline fuses for the solenoids. Ideally I’d have one 0.3-0.5A fuse per solenoid, and a 1-2A fuse per com line. The former fuses protect the individual triacs, and the latter allow a multiple fault situation (solenoids operating in parallel) to not (usually) blow the onboard fuse, and thereby allow the control to continue to operate.
With the above, if no current flow (or the wrong current flow) is detected when a triac is closed, it means either no solenoid is connected or one of the fuses is blown. This means a simple diagnostic program could be run (as I was running to test my installation). If it shows no current flow when a zone is switched on, you know that either a wire is disconnected or the zone fuse is blown. Furthermore, the OS could log the lack of current during the program.
Ideally these could be placed in a closed fuse block I’d mount adjacent to the OS. I’m not finding one online for 5×20 glass fuses, although they are common for the blade fuses. Unfortunately, the blade fuses are only available down to 1A ratings (and only in the full-size blade package), so the margin gets a lot lower. Blade fuses are designed for DC automotive application but they are rated for 24V DC busses, which means they are actually rated to 32V. I’d want to test, but in a clean environment I think they’d be okay with the ~ 37V peak that might be across a blown fuse in a 24Vac nominal system.
For the glass fuses it looks like I’ll need to either create a bundle of inline fuse holders or mount some PCB sockets to protoboard and put it in a case. Once I put it on a circuit board, I might as well add a couple of LED indicators to each circuit – one is parallel to the fuse, the other goes from the switched port to COM. The latter will illuminate if the board fuse and triac are okay when the zone is switched on, the former will illuminate if the fuse is blown due to a short.
I had a similar issue (the burned triac part) with my shiny new v3 OpenSprinkler. Installed, set it up, created a test program to sequence through the stations as a quick test. First two stations (numbering in order of test program, not zone #s) worked fine, the third station never started. Went back inside to the controller, and was met by an acrid smell and a blank display. Unplugged it, noticed transformer was quite warm.
Opened the case and the culprit was obvious – zone 2 triac (which was the third station in the test program).
All of the solenoids connected to the corresponding COM wire (two boxes, two COM wires) show as open. I’d say I also melted the COM wire, but (a) the fuse on the board seems to be intact (it measured about 1 Ohm), and (b) AC supply is rated at 1A. How is possible to blow the triac without blowing the fuse?
I’ll be running new wires to the valves, but I’m trying to puzzle through what actually happened to be sure I address the root cause. As I understand it, the fuse is on the COM ports, and since the current is sensed relative to DC ground, this effectively makes COM the hot AC line, and the switched port of the triac will tie the individual solenoid wire to board ground through the sense resistor. Is this correct?
I should also note: my purchase of the new Opensprinkler was triggered by the demise of the OsPi we’d been using for the last five or six years. I don’t know really when it died – maybe a week prior to the order. When my wife pointed out that the plants were dying I realized the OsPi was dead and being misled by some troubleshooting errors I ordered the new one (the WiFi performance with the OsPi was abysmal so connection was never a sure thing – while the v3 was alive it was much better!)
When I let the smoke out of the new one, I opened up the case of the defunct OsPi. And found the Zone 2 triac toasted there also. But in this case, the fuse had blown.
No error messages were produced at the command line, none in log files I could think to check at the time.
Used this process:
https://openthings.freshdesk.com/support/solutions/articles/5000631599After the install, no OpenSprinkler-related processes ran (that were obvious to me) or exposed via http. This included after a reboot. Dmesg showed no failures at startup, which would suggest the install failed silently.
Any suggestions on debugging? I’m reasonably literate on Linux = I was a part-time Unix System V admin in the 80’s when IT was a side job for engineers, developed Linux apps and managed Linux installations for some startups cerca 2000, and have used Linux as my primary OS since ’95.
The git-pull included a viable SIP install, so I manually installed that from within the release and have control, but it no longer is functional with the OpenSprinkler web app. Is the OpenSprinkler API,and how it interfaces to SIP documented somewhere?
Tried to upgrade my OSPi this afternoon ia accordance with the instructions. Pi had the latest rasbian updates.
This was unsuccessful, and I now have a non-functional sprinkler system. I can ssh to the Pi, but I see no useful log messages anywhere.Debugging (or reversion) tips?
Moved an Access Point to the vicinity of the garage and all is well. Wifi scan now that I’m connected with it in the proper location shows the “new” AP at “Quality 100/100 Signal Level 98/100”, whereas the original AP shows “Quality 97/100 Signal Level 44/100” Not sure what the metrics are (the man page for iwlist doesn’t say) but I’ll deduce the Quality metric is not particularly useful.
Moved the Pi out of it’s cubby (a panel on a cabinet in the garage), and all is well. Nothing in the syslogs to suggest a fault. I’ve concluded my issue is poor wifi at that location. I did test run it for a while there before installing it, but something has changed – either the sensitivity of the receiver has degraded, or perhaps one of my neighbors has added an access point. (I didn’t move anything into the wireless line-of-sight.) I took my laptop out to that location and scanned the wifi, and was surprised both at the low power of my network, and that I could see 6 neighbours networks, all at power levels comparable to my network. I’ll have to rethink my networking approach. A remote or higher-gain antenna, or use powerline networking. I have a couple of other WiFi dongles to try, in case it is degraded transceiver sensitivity.
What I should have done: prior to mounting the OSPi, I should have scanned WiFi and captured the networks and signal levels. Had I done so, I’d have some data to quantify the change, and possible have known I was on the edge of reasonable performance.
Here’s the linux scan command I used:
sudo iwlist wlan0 scan
Thanks. Yes, I’ll try that this weekend. This morning I tried to connect to the default webpage (at port 80 rather than Interval at port 8080) from a different computer, one from which I’d never accessed that page, and it timed out. So I think my assertion that I was successfully connecting to the Pi was wrong – it must have been a cached page on the other PC.
It occurs to me there was another strong clue, of perhaps something starting to go south – I recall now that the last time that I was successfully connecting to the Pi, there were some intermittent delays communicating with it. For example, I had ssh’d into it to do some browsing (looking at the OSPi code), and every once and a while I’d get a delay – in the ssh terminal, there’d be no echo of the typed characters for several seconds, and then they’d all echo back at once. This occurred not long after I’d installed avahi, and I was thinking “that single core processor just can’t keep up.” But that could have also been a symptom as you suggest of the SD having intermittent errors.
Will I find linux system logs on Raspbian?
More later…
