Forum Replies Created
-
Posts
-
OK, so I was blind to the obvious …
SIP uses the physical number of the header pin rather than the OperSprinkler convention of using the logical GPIO number. See attached diagram for the mapping.
This also explain the constant high/switching on physical pins 11, 13 and 15 as these are used by OS to control the onboard shift register hardware.
So before you try any of the above tests, just re-connect the relay board to a set of pins marked with GREEN arrows and use the corresponding GPIO number in the Station settings.
Fingers crossed,
PeteAttachments:
@kabbak, my Zimmerman method is working on 2.1.6. Would you be willing to post your zimmerman option settings and the Weather Underground station’s pws ? Happy to check to see if I get the same results.
A couple of quick questions:
1) Can you tell us the exact version number of the firmware i.e. 2.1.6 (1) or 2.1.6 (2).
2) When you say “the adjustment method options don’t seem to accept my changes” do you mean one of the following: 1) you change the options, press submit and then restart OpenSprinkler but the changes have not been remembered, 2) that changing the settings is remembered but seems to have no impact on the watering % or 3) there are options in the UI that you cant edit e.g. baseline temp/rain/humidity.OK, so I wired the same setup here to test that all was well with my OSPi and a Sainsmart (active low) relay board and all is good. So this might need some diagnosing…
So to confirm your situation, when you say that the relays connected to 11, 12 and 13 are constantly high, do you mean that the relays are activated and open when OSPi is running. I also assume that opening/closing the station via the UI has no effect on the relay i.e. it stays open regardless of whether OpenSprinkler has turned the station on or off.
A few quick questions:
1) what type of relay board are you using and do you know whether it is active high or low ?
2) when you say that “higher pin numbers do nothing” do you mean they were also constantly high with relays open ?
3) did you try any of the other pins particularly pins 5-8 as curious if this made a difference ?A few quick tests:
1) Can you try switching the GPIO Station settings between “active high” and “active low” to see if that makes a difference and double check the pin numbers are set correct. This will make sure there isn’t a mix up around polarity for the relays (I know many sainsmarts are active low whereas other manufactures are more intuitively active high). This should rule out any problems with the settings.
2) If you have a voltmeter, it would be really handy to test the gpio pins without the relay board connected to confirm whether the pins toggle when OSPi turns the associated station on and off. This would rule out a software problem with the GPIO Station functionality.
3) A bit of a hail mary but can you start a fresh with a clean install of Raspian and OpenSprinkler. I don’t know the SIP programme and although very unlikely it could be some config/setting idiosyncrasy. A long shot but worth checking to rule out an operating system problem.
4) If you can reboot the Raspberry Pi without starting up OpenSprinkler then we can check to see what state each of the relays is by default. I am interested in both the relay led, if one is present, and the relay itself. Note that following a system reset, each of those GPIO pins are by default INPUT pins rather than OUTPUT and each has a pull down resistors connecting it to ground. On an active high relay board this should mean all the relays (and associated status leds) are off. On a active low board, like my sainsmart, this results in the relay leds being on but the relay itself being off i.e. there is enough current going through the pull down resistor that the led shows a dim light but not enough to activate the relay. This would rule out a hardware problem (but leave us with more diagnosing to do !)
Lastly, GPIO15 is used by OSPi for RF Stations and so it is not made available for GPIO Stations via the UI. By default OSPi sets this pin low during initialisation so it is odd that connecting it to your relay board caused “chattering”. It should have resulted in either a constantly “on” relay (if active low) or a constantly “off” relay (if active high). The only reason I can think that it was chattering is if you had an RF Station enabled and it was sending the RF code to that GPIO pin. I ran into this when developing the GPIO Station functionality and it was very unnerving to hear the relay chattering away every minute or so hence I removed GPIO15 from the selection list to avoid a possible pin conflict.
Let me know how you get on as it would be good to sort this out. The GPIO Station stuff is pretty new and hasn’t got the mileage of the rest of the system so I’m very interested in discovering the root cause to your situation.
Pete
OK, so this is what I did.
1) Build OSPi Firmware as per normal but select “No” when prompted to auto-start OpenSprinkler.
$ sudo ./build.sh OSPI2) Create a Systemd configuration file to control the start-up of OSPi
$ sudo nano /etc/systemd/system/ospi.service3) Add the following lines to the ospi.service file and then save the file
[Unit] Description=OpenSprinkler Server # After=weather.service apache2.service [Service] # ExecStart=/usr/bin/stdbuf -oL /home/peter/OpenSprinklerGen2/OpenSprinkler ExecStart=/home/peter/OpenSprinklerGen2/OpenSprinkler WorkingDirectory=/home/peter/OpenSprinklerGen2 Restart=always RestartSec=10 [Install] WantedBy=multi-user.targetNote that in my setup, I need OSPi to wait until I have started the web server and weather service as I host these on my local RPi. Also, I use “stdbuf” to set the output from OSPi to be line buffered (i.e. -oL) so that diagnostic output is written immediately to the journal log file. Both of these may be unnecessary for you so have commented out. You will need to adjust the directories to your OSPi directory location.
4) Initialise the service and set to auto-start
$ sudo systemctl enable ospi.service $ sudo systemctl start ospi.service5) You can check that the service is running successfully with the systemctl command
$ systemctl status ospi.serviceThat should be it.
PeteA quick thanks to Ray and Samer, configuration of GPIO Station and Zimmerman baseline conditions can now be accessed via the latest version of the App. You will need to download the latest version of Firmware 2.1.6(2) from Ray’s github and do a ./build.sh to enable. Cheers, Pete
David, the Raspberry Pi also uses 3.3v logic on gpio pins. This is generally sufficient to trigger standard 5v logic (or at least it works with all the relay boards that I have). I think BBB also provides a 5V rail if you need to power as well as trigger a relay board. Curious which relay board you are looking at and how your testing went. Pete
David, the GPIO Station feature is only written for Raspberry Pi GPIO pins and will be enabled on OSPi once Ray has checked over my code. The OSPi changes are pretty straight-forward and it might be possible to extend for Beagleboard. But I dont have access to an BB/OSBO for developing/testing ao it is a bit out of my reach. I know the aim of OpenSprinkler is to have a consistent set of features across the supported platforms so happy to collaborate on this if you – or perhaps another OSBO owner – are able to help develop. Pete
Hey Richpuch, on the second point, the GPIO Station stuff (and an extension to the Zimmerman algorithm) is currently disabled in the App as it needs a Firmware update to work safely with the arduino based OpenSprinkler. This will be activated once Ray has a chance to check over some of my code and include in Firmware. If you really need to enable this on OSPi now then you can git clone the latest Firmware, increment the OS_FW_MINOR number in defines.h from 1 to 2 and rebuild the Firmware. But please make a backup of your settings before you attempt this 8) Cheers, Pete
Jan
So it took me a while to understand the /cs api call, particularly, when trying to set multiple “special” stations. The easiest approach I found was to break it down into discreet steps. Firstly, set the required stations to be “special” and then configure each of those stations to the desired gpio pin.
As an example, lets say we want to set both S01 and S05 (i.e. sid 0 and 4) to be gpio stations using pins 7 and 8 respectively with active low relays. Then firstly, we use the /cs api call to set the p0 variable to the bitwise OR of the multiple stations i.e you would set p0 = 17 (which is 00010001 in binary) to turn the special flag “on” for sid 0 and 4. You can then follow this with two /cs calls to configure the gpio pins.
So the full sequence of api calls in this example would be:
http://rp2:8080/cs?p0=17
http://rp2:8080/cs?sid=0&st=3&sd=070
http://rp2:8080/cs?sid=4&st=3&sd=080To ensure that you have things set correctly then you need to call:
Note that I have set “Ignore Password” through the UI, you may need to include your MD5 password hash to the above api calls.
Hope that help,
PeteKristoffer,
The GPIO functionality requires both the latest Firmware and the latest UI. You have downloaded the functionality to control the GPIO pins in the Firmware but you really need the latest UI web pages to easily access and configure the functionality. I know Samer and Ray are looking to package this up in a future release so the two options below are a bit of a work-around until then.
1) You could upgrade to the latest UI from Samer’s GitHub (OpenSprikler-App) but would need to host the webpages on your RPi rather than relying on the version that is provided from the OpenSprinkler server. The instructions for doing this are on the OpenSprinkler support page: (here). This is non-trivial and requires a certain level of Debian/web knowledge.
2) An alternative, given that you have already updated the Firmware, would be to configure the station directly in the Firmware by sending an api command. The api documentation is on the OS support pages: (here).
As an example, the command http://ospi_ip:8080/cs?pw=PASSWORD&p0=16&sid=4&st=3&sd=080 can be sent to the Firmware via a web browser and will set Station 5 to be a GPIO Station using GPIO08 and active low logic. In the example, we first enable the “special” flag on Station 5 with the parameters p0=16 noting that the 0 after the p refers to the first board of 8 stations and the 16 is binary for the 5th Station on that board; we then use sid=4 to tell the firmware that the following st and sd parameters refer to Station 5 (i.e. sids go from 0-7 and are therefore one less than the station’s labels); st=3 specifies a GPIO Station type; sd=080 specifies GPIO pin 08 and active low.
You would also need to substitute ospi_ip with the IP address of your RPi and PASSWORD for the MD5 hash of your OS password (or turn off password checking by selecting Edit Options/Advanced/Ignore Password from your OSPi homepage).
Happy to help get this working for you if you need any assistance.
Cheers, Pete
So I figured out how to add imperial/metric detection and conversion and seems to be working. I’ll put to Samer to see if he is interested in taking into the weather and app master branch.
I have written this as an upgrade to the existing Zimmerman adjustment method rather than adding a new Zimmerman2 to the pick list. I could change the approach and implement this as a new method if that would be preferred. I guess it depends whether current Zimmerman users believe this is a natural enhancement or an unnecessary complexity 8) Thoughts?
Attachments:
That’s correct. I am really glad Ray and Samer agreed to include the GPIO Station stuff as that along with the Remote Station functionality makes the ecosystem very extensible and opens up new control scenarios. I have three setups at home:
1) Main Controller in the back garden: I wanted to add two more stations to my main back garden OSPi controller that already had 8 valves and a flow meter connected. I did this by wiring up a sainsmart dual-relay board that I had lying around to a couple of free gpio pins. I use the GPIO Station functionality to get OS Firmware to control the extra relays and connected valves.
2) Remote Station in the front garden: I live in a terrace block and needed a way to irrigate a small front lawn but can’t run a cable to the main OSPi controller in the back garden. So I wired up a single mechanical relay to a RPi Zero and run OS Firmware with GPIO Station functionality to control a single valve. The RPiZ has wifi usb to connect to my network and is setup as a Remote Station on the main OSPI controller in the back garden so that I can keep all of my programme scheduling centralised.
3) Indoor Station: I wanted to control my Claber Oasis indoor watering system in the same way as my front and back garden setups so I have combined an ESP8266 with a motor shield to drive the 9V DC latching valve on the Claber. I have custom code running on the ESP that mimics the OpenSprinkler Remote Station api so that the main OSPi controller in the back garden can turn the Claber valve on/off using the Remote Station functionality. Again, keeps all the programme scheduling together.
Cheers, Pete
I have been using the Zimmerman method for a while now but the baseline weather conditions (Temp = 70F, Humidity = 30% and Rain = 0) aren’t a great match for London, UK where average temp is 50F and Humidity is up around 80%. I have been using a 0% sensitivity setting on temp/humidity to pretty much ignore any weather fluctuations except for rainfall.
But over the weekend, I modified the UI and weather server script to accept a custom baseline for my location. In essence allowing me to set the reference temp/humidity/rain to average London conditions. This means that I can set my program duration to an “average day” scenario and have Zimmerman adjust for daily offsets in all three variables.
Be interesting to see how it works out in practice but back testing on a year’s worth of historical data suggests a much better fit. The code changes are pretty minimal and backwards compatible. Curious, if this is of interest to others ?Attachments:
@Ray/ @Samer, thanks to you both for integrating this into the master branch. I couldn’t find the api and user manual on github so have included below the documentation changes to reflect the GPIO Station functionality. happy to make the changes if you point me at the source documents. Cheers, Pete
1) OpenSprinkler Firmware 2.1.6 API Document – Add following bullet in section 8 Get Special Station Data
• (OSPi only) st=3: gpio station. sd stores the gpio number and active state for the attached relay in the following order: gpio number in zero-padded, ascii format (2 bytes) and active state as either ascii “0” or “1” (1 byte) e.g. sd = “051” for an active high relay attached to GPIO5.
2) OpenSprinkler v2.x User Manual – Replace the word “two” with “three” special station types
Station Type: the default type is Standard. Beyond that,
twothree types of special/virtual stations are supported:3) OpenSprinkler v2.x User Manual – Add following to Section 3.2 Station Attributes/Station Type
• GPIO station: (OSPi only), A GPIO Station allows you to connect your own switching hardware to one of the many Raspberry Pi GPIO pins available on the OSPi motherboard. This allows you to extend the number and type of stations you can control from an OpenSprinkler main controller. GPIO Stations simply send “on” and “off” signals to the selected GPIO pin and rely on the connected hardware to physically switch the downstream station. A GPIO Station is specified by a GPIO pin number and whether your hardware is active HIGH or LOW i.e. requires a +3.3V or 0V signal to switch on.
4) OpenSprinkler v2.x User Manual – Substitute picture on Section 3.2 Station Attributes
Replace image with one attached
Attachments:
I have an OSPi controller wired up in the garden and wanted a way to include the indoor system into the same UI.
If I was doing this again, I might use the new RPi Zero with a wifi dongle instead of an ESP8266. I could have saved myself the coding and used OSPi firmware on the Zero in remote/gpio station mode. But the RPiZ wasnt out and the ESP + Motor shield was really cheap (~£10). It was also a fun project and having push notification when I need to fill the reservoir is nice.
I think I saw another thread were someone was looking to port OSPi to an ESP8266 but didnt see any results?
@Ray/Samer, I have done a pull request on both Firmware and App. Appreciate any feedback via github. Peter
Sakos, I have taken the SD card and WiFi dongle from my RP2 to get a new Pi Zero up and running without problem. I would note that the RP2 installation was a very recent build from the latest NOOBs and OS github. As such it was based on Jessie version of Debian.
Following was from Adafruit site (https://learn.adafruit.com/introducing-the-raspberry-pi-zero/setting-up-your-sd-card):
Raspbian Wheezy 5-15 or earlier do not support the Zero! Try Jessie insteadHope that helps, Pete
The default root directory moves from /var/www to /var/www/html when you upgrade the Debian operating system from Wheezy to Jessie (rather than as a result of upgrading to apache 2.4).
So mission accomplished and everything up-and-running as I had hoped. A few things tripped me up along the way – namely moving to Debian Jessie and the latest version of apache at the same time – so a few notes below in case others run into similar.
I chose to have the OSPi itself as the local UI server and installing apache was very simple using standard “$ sudo apt-get install apache2” via the command line. This did bring down a newer version of apache 2.4 that was a bit different to what I was familiar with.
After installing, I needed to enable mod_headers – an apache module that OpenSprinkler needs to support secure resource sharing between websites – as this appeared to be disabled by default. The command “$ a2enmod headers” will do this.
Another change in 2.4 is that .htaccess files are now ignored by default. I used these in the past to store website specific config and had placed the OpenSprinkler specific configuration in /var/www/.htaccess file. The preferred approach – thanks Dave for the steer – is to add the lines to the end of /etc/apache2/apache2.conf:
# Added following lines to support OpenSprinkler Header set Access-Control-Allow-Origin "*" AddEncoding x-gzip .cgz .jgz AddType text/css cgz AddType text/javascript jgzAnother small change with apache is that the web files now need to go into /var/www/html rather than just /var/www.
Initially, I thought I would use the latest web files from the OpenSprinkler App github. But it seems the github version doesn’t included app.cgz and app.jgz – at least I couldn’t find them – so I humbly went back and used the version of UI.zip referenced in the instructions provided by Ray and Samer!
For the final step, I think the instructions may have a typo, as I needed to browse to http://os_addr:8080/su rather than http://os_addr/su in order to replace the cloud UI address (https://ui.opensprinkler.com/js ) with the local UI server address (http://os_addr/js).
Now that the local website is running on port 80 and the firmware on port 8080, you need to be a bit careful as to which page you pull up as you have the choice of
– http://os_addr will take you to port 80 and directly to apache serving the OS App – useful if you want to manage multiple OS sites for example.
– http://os_addr:8080 will take you directly to the OS Firmware but now with a locally served UI.All good.
OK, so new year’s may have killed off a few crucial brain cells and now stumped at getting a locally hosted UI successfully up and running on a RPi2 that has been faultless with OpenSprinkler 2.1.6 (1) for the last few months.
Have used the steps from “Use a Different Remote Server for UI Assets document” and latest UI.zip. All seemed to install/configure fine but browsing to http://RP2:8080 just gives me a black screen on Chrome. In developer tools, I see the following errors on the console.
– Resource interpreted as Stylesheet but transferred with MIME type application/x-gzip: “http://rp2/css/app.cgz” – home.js:58
– Uncaught SyntaxError: Unexpected token ILLEGAL – app.jgz:1Changing back to https://ui.opensprinkler.com/js gets everything working again. Not seeing any errors in /var/logs/apache2. Hoping I’ve just missed something obvious and someone can help get me back on track.
Just for the record the install went as follows:
1) New install of both raspian(wheezy) and OSPi 2.1.6(1) on RP2, all working good and sound over the xmas/new year break.
2) Installed apache with “sudo apt-get install apache2” and added an .htaccess to config the additional file types. No problems browsing default webpage.
3) Copied down UI from the instructions link and copied into /var/www, made all files accessible and did the swap to “http://RP2/js” via the su page.
4) Used Chrome on Win10 box to access http://RP2:8080 hoping to get the UI served up but stuck on black screen and error messages above.Cheers, Pete
Thanks Ray for the insight and totally get where your priorities needs to be.
I managed to cobble something together over the weekend using a spare h-bridge chip (L293D) and some unholy hacking on the various code examples out there. To be honest, the hardware was the easy bit compared with getting your head around html and json! Works a treat with my main OSPi controller now sending commands to the indoor watering system.
I agree that the ethernet shield is a bit overkill and makes the unit tethered so will take a look at moving to RF as next step.
Thanks for the response Ray. I suspected that the Arduino shield would not be hardware compatible with the Raspberry Pi and thanks for confirming.
So now I am wondering if a networked Arduino with an OSBee Shield could be made to look like a “remote IP station” to my main OSPi controller. This way the Arduino with OSBee Shield could drive the latching valves of my indoor system and my OSPi could drive the outdoor valves and act as the combined central control system.
I know the new “remote IP station” functionality is meant to allow one OS to control another OS. But looking at the 2.1.6 firmware code, the Master appears to be sending just the “cm” command to the Slave. Is that right ? The OSBee web server and sprinkler timer examples look to have all of the component parts of the logic needed to listen for a “cm” command and drive the latching valves. But maybe I’m missing something ?
I’ll admit a somewhat convoluted (and expensive) way to integrate an indoor watering system but maybe I can rationalise it as a learning opportunity !
