Forum Replies Created
-
Posts
-
It may yet be overheating. I live in a similarly warm environment (Houston, TX) and also have mine mounted outside in a sealed utility box. I added a laptop exhaust fan to the box and a simple controller for active cooling, but for the first two days after installation I ran it with the fan shut off just to see whether it was really necessary. On the second day my Raspberry Pi stopped responding to ssh, RDP and ping, requiring a reboot. I wasn’t logging temps at the time but I assume it was due to the 85°C CPU shutdown limit. After that I configured it so the fan starts any time the CPU temp exceeds 50°C and it has been trouble-free ever since (even this weekend when it was 104°F here).
If you are operating via WiFi and don’t need wired Ethernet, I would suggest that you use a Model A rather than a Model B. The A runs 15-20C cooler than the B under similar load… the LAN controller chip on the B generates a lot of heat, even when it’s not in use.
Great job, this is a really nice front end for OpenSprinkler!
When configuring my install I noticed some weirdness about the password setup, and came up with a workaround for anyone else having similar trouble. For the record, I’m running an OpenSprinkler Pi with OpenSprinkler-Controller and the interval_program both hosted on the device itself. For this one I’m using lighttpd rather than apache to keep the footprint small (if that makes any difference).
The problem I found was that when I ran the initial setup and gave it a fairly complex password (> 8 characters with some special chars), it appeared to save everything okay but then would always give me an “Invalid login” when I tried to use the app. I deleted config.php (in order to get back to the setup page) and re-did the setup several times, always making sure I didn’t mistype the password, but had no luck with this until I tried a simpler password (“test”). That succeeded and allowed me in… so for some reason it looks like either the initial setup or the validation in main.php has a problem with more complex passwords, although I examined the code and can’t see any reason why this should be so.
A secondary issue was that the app doesn’t provide any way to configure access for more than one account. I wanted to send a link to a friend to show it off and convince him to buy an OpenSprinkler Pi, but did not want to give him my credentials, so I needed a way to create a separate account for him.
To work around both of these problems I decided to try apache’s htpasswd utility to manage the accounts outside the app instead (apt-get install apache2-utils if you don’t already have it).
Usage is pretty simple, just cd to wherever your .htpasswd file is (by default it’s in the app’s root directory) and you can add new users (or change the password of an existing user) with
sudo htpasswd -s .htpasswd YourUsernameHere(It’ll prompt you for the new password. The -s switch tells it to use SHA for hashing, in keeping with what the OpenSprinkler-Controller app itself uses.)
However, that only solved one of the problems. Now I had a way to manage multiple accounts, but it broke the app’s login screen. I couldn’t even get in with my simple “test” password anymore.
I checked the .htpasswd file and saw that the Apache utility had stuffed a “{SHA}” prefix in front of the hashed password which the sprinkler app hadn’t used. So in order to make the sprinkler app understand Apache’s format I edited main.php and changed this line:
$test_pw=base64_encode(sha1($pass));to this, so it would cope with the prefix:
$test_pw='{SHA}'.base64_encode(sha1($pass));Unfortunately, this still didn’t solve the problem. I read that htpasswd does indeed base64 encode the SHA1 digest of the password, so I knew this code had to be correct unless Apache’s SHA1 implementation was different from php’s for some reason. It turns out that by default, php’s sha1() function defaults to outputting a 40-character hex number (which obviously doesn’t need to be base64’ed in order to be written to a text file), so I switched the code to use the raw bytes from the sha1 call instead (which do need encoding) by adding the optional “raw” parameter:
$test_pw='{SHA}'.base64_encode(sha1($pass,TRUE));This resolved the problem — my friend and I are both able to log in with no issues, and now I can manage all access via htpasswd without having to go through the initial setup to change anything.
Speaking of which, if for any reason I need to delete my config.php file and go through the initial setup again, the install page needs to be changed to observe this format too. This line in install.php:
$r = fwrite($file,$_REQUEST["username"].":".base64_encode(sha1($_REQUEST["password"])));just needs to be changed to
$r = fwrite($file,$_REQUEST["username"].":{SHA}".base64_encode(sha1($_REQUEST["password"],TRUE)));and Apache-style passwords will be used during setup as well.
Good going, Samer! This is a really amazing piece of work, and I am impressed by your rapid responses in getting all the bugs worked out. (And Ray, if you’re feeling generous you should send this guy an OpenSprinkler Pi. I feel bad that he’s debugging Pi-specific issues by tracing through the interval code.)
