Forum Replies Created
-
Posts
-
Looking at the picture of the board here:
https://opensprinkler.com/product/opensprinkler-pi/
I see neither an SMT nor through hole footprint for a fuse (F1?) on the board.
Maybe the fuse was eliminated entirely in the latest design? Maybe the reason was that a blown fuse that requires rework of the board to replace isn’t much value over having no fuse at all?
So, four choices, I guess:
1. Use jumper in the footprint for the through hole F1.
2. Use only the through hole fuse
3. Use only the SMT fuse (like the board that died last fall
4. Populate both (like the board with the burnt F2 that died over a year ago)Can anyone help?
I opened a ticket on this, but still haven’t got an answer. So, I thought I’d try again here.
I ordered up both through hole and SMT versions of the fuses. Should I populate only one, or both? If just one, which one?
The reply I got from the ticket asked me to send a photo of the board. I replied with a photo of both and got a response that F2 was clearly blown on one of them. (That was pretty obvious).
The ticket also said to measure resistance across the supply nets to verify no other parts were shorted (that’s pretty obvious too). But, what I’m looking for:
1) Should both the SMT fuse and through hole be populated? Probably not, but the first board that failed had both populated.
2) Is a schematic available that matches these boards? (the schematics I’ve found show neither an SMT nor through hole fuse).Dave Thomas
Ok, so now I’m really confused.
On the pcb, I found what looks like what might be an 1812 PTC between one pin of the 24VAC connector and D1. Nothing is shown on the schematic for a part there.
I checked with a DVM–that part is open. It also appears to be cracked at its midpoint. If it’s a PTC, it’s now open.
I have another OSPi board that died before I replaced it with this one. On that board, F2 was completely burned off the board and there was lots of charring in the F2 area of the PCB (which isn’t close to F1) I found that board, thinking I could check use the “F1 PTC” from that board. If it was indeed zero or very low resistance, it’s probably a PTC. I could use it to replace the bad one on the newer card.
But, in addition to the (maybe) PTC, the original failed card had a parallel fuse F1 populated. On the newer card, there are holes for the fuse exist, but there is not one populated. The silkscreen says F1, but there the holes for the part are empty.
So, it appears on the first card that failed due to F2 blowing had a fuse (F1) in parallel with a PTC at the 24VAC connector. The fuse F1 was not populated on the replacement PCB.
But, why would there ever be a PTC in parallel with a fuse? That seems crazy. Maybe the designer hadn’t decided whether to use a PTC or a fuse, so had a footprint on the pcb so that either could be used? And the first pcb had both populated by mistake?
And why are neither of those parts in the schematics?
Both cards say OSPi v1.42+ on their silkscreen.
It’s going to get expensive if I have to keep replacing the card every year or two, especially since I have four different OSPi’s spread across the property. Interestingly, the location of this OSPi is the only one that has failed, and it has failed twice now. But, maybe the second failure occured because F1 was missing?
The first time, the RPi was also damaged, but this time only the OSPi pcb seems to be damaged, maybe only the PTC is open.
Ray, if you read this, please help! What should I do to fix the card? Can you explain what you’re trying to do with F1 and the part that looks like a PTC?
Thanks!
If I’m running the UI locally on the same ospi that’s running opensprinkler, is there a way I can save the images locally instead of in the cloud? If not, could I hack the UI to do that?
That OSPi was using the earlier version of the UI (I’m hosting the UI locally).
Updated all the pi’s to use the latest UI.zip and everything (almost) is working fine now. (I still have to figure out how to get the zone images to show up.)
Great stuff!
It’s working flawlessly now.
I was going to dig into a bunch of new stuff to try and figure out how to interface OpenSprinkler to Google Assistant. I’m so glad I searched these forums first!! I have no desire to re-invent the wheel.
One comment–you are charging way to little for your app. I’m sure I pretty sure I could figure out how to do it myself, but I’m equally sure it would have taken days (if not weeks) to get something working that would just be a tiny subset of what your app provides.
Thank you!
Got “turn on the pathway lights” and “turn off the pathway lights” working! Thanks!
Once the delay as several seconds. I’m testing by looking out the window at the lights to see if the command was received by OpenSprinkler. Perhaps I was looking away too soon when I testing before lunch and incorrectly concluded things weren’t working.
Yes, I’d done the bridge update.
But, I just tried again. I’ve changed NOTHING since I tried a couple of hours ago, but now it’s working.
turn pool off
and
turn pool on
work fine!
No clue what was going on.
Previously, I’d uninstalled and re-installed the voice for iot app to get rid of the “pathway lights” and added pathway instead (it didn’t work). I’ll also add a location and try pathway again–in your tutorial you said a location wasn’t needed since there was only one “zone X”?
I have three unique OpenSprinkler Pis around the property that control irrigation zones. I also have three (soon to be six) Pi Zero W’s controlling an SSR for outdoor lighting automation.
I think each different Pi (url) should be a “hub”. Is that correct?
.Even though I deleted (and deleted all) linked voice commands, I couldn’t set up a “pathway” instead of “pathway lights”. I kept getting complaints about it already being defined. I tried exiting the app and re-entering, but that didn’t fix it.
So, I just used “pool” instead. I tried
Turn on pool
and
Turn pool on
neither work from Ok google, but both work from the voice for IOT app. I get a message on the phone like Uknown: Text:<on pool>
Should I post any fix (or other issues) I find here, or on your website somehow?
Thanks!
Doing the recipes on the PC is easy!
I think I’m almost there… I get a text message after saying “Ok, Google. Turn pathway lights on”:
Pathway lights on
But, the voice command wasn’t recognized.
When I say the same thing after clicking the microphone icon in the voiceforiot app, it corrects “turn pathway lights on” to “turn pathway_lights on”. This works.
So, I’m thinking I should just use “pathway” instead of “pathway lights”. Or, maybe figure out how why the same correction isn’t being done when I use Google Assistant and all the stuff in between it and voiceforiot app.
Do I have to set up the recipes on the Android phone(s) that will be running Google Assistant, or can I somehow do it on my pc?
It’s a bit of pain to use my fat finger to overwrite the variable part of the URL text that’s customized for each recipe.
Maybe I can answer my own question.
So, if I just create a Google Assistant shortcut, I’d first have to say “launch Voice control…”, before issuing a command like “Turn on Pathway Lights”?
If that’s the case, I’ll continue down the path of setting up AutoRemote and IFTTT.
Thanks for the quick reply, Javier.
I was using the instructions on your website
for using IFTTT with Autoremote when I read your reply. I was to the point of getting the URL that was on my laptop to the Webhooks service.
All you would have to do is create a shortcut (for example “talk to my home” which has the Google Assistant “launch Voice Control for Voice for IoT
This sounds much simpler. Why wouldn’t I just do that rather than what’s documented on your website?
Can you point us to a tutorial for setting up setting up Google Assistant with a shortcut?
Thanks!
Easy setup and works great!
Is there a way I can use “Ok Google” then speak the command instead of having to open up the voiceforiot app?
I’m guessing I’m just ignorant of how that’s done?
Just what I want! I’m ready to give it a try.
How has the testing been going? Is it in production yet?
How will you charge for the paid version?
I found that I must set the duration before the start time, if I want to use a Sunset or Sunrise start time, but DON’T want to use Sunset to Sunrise or Sunrise to Sunset duration.
Otherwise, the hour, minute, second entries are disabled in the duration field and only Sunset to Sunrise or Sunrise to Sunset options are available for the duration.
Seems like a bug, but an easy work-around once you know it.
The UI code doesn’t seem that easy to modify to add fixed off time instead of a duration. I’ve haven’t give up, but my motivation went down quite a bit after figuring out the trick to get a program for a start of Sunset with six hours duration. Also, after spending several hours reviewing the app.js code…
An alternative would be to write a trivial script that would update the station durations using the firmware api. The station durations would be based on the desired turn-off time and each day’s sunset (for what I want).
But, I haven’t figured out what the UI code is doing to schedule the sun based times indefinitely. The script might have to be executed once a week.
Samer, do you have any hints?
Confirmed that the only issue was where the apache directives were placed in the apache2.conf file. Placing them at the end of the file no longer works. Putting them inside the <directory> </directory> block for /var/www allows the UI.zip to be used unmodified.
I moved the Header set Access-Control-Allow-Origin to be between
<Directory /var/www/>
and
</Directory>
Now I’m up and running. Probably if I move the AddEncoding and AddTypes I can stick with the zipped version of the js and css–not that it matters on a pi, but I’ll check to be sure and post what I found out.
The way it worked on the older apache release (or maybe it was wheezy vs. Jessie Stretch Lite) was that the directories applied to ALL directories if not inside a directory block. Maybe that changed.
I’m going to try adding the ability to schedule a fixed off time instead of a duration. Turn on at sunset and off at 10:00 pm, for example. Which I think means the UI needs to have an field for the off time and the firmware needs to calculate duration based on each day’s sunset. There are some fragments for calculating the duration when sunset to sunrise is used for the duration, so I should have enough for “monkey see monkey do”.
This is for the deck, pathway, and front entrance lighting. Already I can control them using the same UI as I use for my sprinkler systems. But, for the lighting, I don’t want a fixed on time and it’s really not necessary to run them all night long (dusk to dawn IS currently supported).
If there’s an easier way than hacking a locally hosted copy, I’d appreciate a hint. I have no problem sharing the modified code, once I get it working (if anyone else is interested).
Thanks!
So, for some reason the AddType or AddEncoding doesn’t seem to be working.
I hacked main.js to reference the .js and .css files instead of .gjz and .cgz files. Now, I get much farther before I get a different error:
(
index):1 Access to Font at ‘http://192.168.0.187/css/lato.fnt’ from origin ‘http://192.168.0.187:8080’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://192.168.0.187:8080’ is therefore not allowed access.
14:47:33.001 (index):1 This page includes a password or credit card input in a non-secure context. A warning has been added to the URL bar. For more information, see https://goo.gl/zmWq3m.
I’m thinking the “Header always set …” directive isn’t being recognized either.
Maybe the newer apache release needs the directives to be in a different file than /etc/apache2/apache2.conf?
I’m going to try researching that next.
My /etc/apache2/apache2.conf file is attached:
These lines are at the bottom of it:
Header always set Access-Control-Allow-Origin "*" AddEncoding x-gzip .cgz .jgz AddType text/css cgz AddType text/javascript jgzI followed all the steps on the web page. And, posted a few more to the relevant thread a couple of years ago.
https://opensprinkler.com/forums/topic/ui-assets-on-microsd/
So, the headers are enabled.
I’ll compare what happens when stepping through the java on the opensprinkler website, unless someone has a suggestion.
I’m using start time of dusk, and duration of six hours on one host. Not exactly what I want, but about the best that can be done.
On my second setup, the schedule preview makes it look like OpenSprinkler thinks dusk is around 12:15 pm instead of something like 5:15. I’ve deleted and re added several times with always the same result.
Location is set correctly and the pi’s timezone is correct.
Looks like support has pretty much gone away for this stuff? I plan to take a look at the Java scripts to figure out what’s going on with the sunset confusion. Maybe I can add support for a sunset/sunrise based off time instead of a duration.
