UI Assets on MicroSD

[dbrack1]

Hello,

I have hardware version 2.2 and software version 2.1.5. I am trying to use the MicroSD to host the UI Assets, but when I put in a ./ on the http://ipaddress/su page and save it, it just to a blank screen when I try to go to the home screen of opensprinkler. I have used this before with no troubles and the opensprinkler sees the MicroSD card so I know that is not the propblems. I have also searched the web and this forum to no avail. I unzipped the UI.zip to the root of the card is that the right place? Anyone out there that has run into the same issue or have any ideas?

Thanks

[ShawnHarte]

Have you tried just the slash with no dot for root directory. Seems to work fine on mine.

[Samer]

Hosting the UI files off the SD card is no longer supported in the newest firmware and moving forward will no longer be supported.

You are welcome to host the files on your local network or elsewhere but we don’t believe there is a need for this feature in the Unified firmware.

Thank you for your understanding

[dbrack1]

*Sigh* I really liked that feature, it was especially nice when you have an unreliable internet connection and it seemed to be more responsive too. Is it because of a fundamental change in coding that prohibits it or is it just that you don’t want to support it anymore?

[Samer]

There really is no reason for it with the available apps for all platforms. The apps include the files needed to render the UI and therefore do NOT need an Internet connection. This alone is enough reason to remove the option which allows new features to fit in the firmware (due to limited memory and storage space).

We also had too many support requests regarding this item and was no longer worth dealing with. For reference, here are the supported platforms and links to the app. If you want additional platforms supported please let us know and we can make an effort to get it supported:

• Amazon Appstore
• Apple App Store – iOS
• Apple App Store – OS X
• BlackBerry AppWorld
• Firefox Marketplace
• Google Play Store
• Google Web Store
• Windows Phone Store

Please note the Google Web Store and Firefox Marketplace support all platforms that the browser supports. For Firefox, this installs as an app with a shortcut simulating an installed app.

Update: We also documented how to host the UI files on your own web server locally, if you wish to do so. The document is located here: https://opensprinkler.freshdesk.com/support/solutions/articles/5000164006-using-a-different-server-for-ui-assets

[ipilcher]

I strongly suggest that you reconsider this decision. In fact, I strongly suggest that you host the UI elements on the controller by default. (If 3MB of content is too much for the SD card, it’s arguably already too small.)

As it stands, you’re one DNS hijack plus a browser vulnerability away from being a vector for compromising your users’ systems.

And no, a mobile app is not always a viable alternative. My mother, who is the main “plant person” in our household, doesn’t have a smartphone or tablet. If I were to need remote access to the controller it would currently be done via SSH, VNC, and a browser. Given the lack of SSL/TLS support, I can’t see myself ever exposing this thing to the Internet.

[Samer]

I understand what you are saying but first, I’ve already outlined available apps for the desktop which means it’s not restricted to mobile phones and tablets. Please refer to the list of apps that I have linked.

Second, not sure how a user managing his own DNS would be more secure than our DNS. We take every security precaution with our DNS hosting accounts and use CloudFlare for added protection.

The issue isn’t the size of the SD but the speed of the processor and Ethernet controller. These make it very slow and incur a high failure rate. Furthermore, not all devices have an SD so depending on that cannot work.

Regarding the SSL/TLS support, no Arduino could support this and instead depends on other measures for security. We are looking at cloud access instead of port forwarding in which case we will use AES 128 for communication. In the mean time, you may setup a reverse proxy that adds SSL and even BASIC auth if you wish, as the app does support this.

Thank you

[ipilcher]

I understand what you are saying but first, I’ve already outlined available apps for the desktop which means it’s not restricted to mobile phones and tablets. Please refer to the list of apps that I have linked.

Aah. I didn’t realize that the app could run in a desktop browser. Interesting.

Second, not sure how a user managing his own DNS would be more secure than our DNS. We take every security precaution with our DNS hosting accounts and use CloudFlare for added protection.

The issue is that a users controller/browser could be fooled into downloading malicious versions of the UI elements. SSL (with certificate validation) would prevent this, since the attacker (presumably) wouldn’t have the private key for the server certificate.

Regarding the SSL/TLS support, no Arduino could support this and instead depends on other measures for security. We are looking at cloud access instead of port forwarding in which case we will use AES 128 for communication. In the mean time, you may setup a reverse proxy that adds SSL and even BASIC auth if you wish, as the app does support this.

Does the controller download the UI elements and then send them to the client, or does it just embed links into the HTML it sends to the clients? If it’s the latter, is there a reason that https://ui.opensprinkler.com/js wouldn’t work?

I was actually thinking about going the reverse proxy route, but I wasn’t aware that the “mobile” app supported SSL. (Why would it if the controller itself doesn’t?) That’s really good to know, and it wish that it were stated more prominently (although I have no idea where it should be so stated).

I guess the other option is to go the Rasberry Pi route. Decisions, decisions.

Thanks for the response!

[Samer]

For the record, the UI is served over a valid SSL. The relevant code define can be found here:

https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/defines.h#L112

[ipilcher]

Ah, cool. I was going by the URL from the Using a Different Server for UI Assets article. You might want to update that.

[Samer]

Finally updated the support document (although screenshots may still be incorrect).

Thanks for pointing it out.

[davethomaspilot]

I think I prefer to use a local server for the UI.

The documentation for this:

https://opensprinkler.freshdesk.com/support/solutions/articles/5000164006-using-a-different-server-for-ui-assets

looks excellent. Thanks!

Will the UI code in:

UI.zip

always be up to date? If not, how does one get the latest?

Thanks!

[davethomaspilot]

Looks like the directory structure under www is identical to what’s in the UI.zip file.

So, I’m thinking the latest ui code will always be here?

https://github.com/OpenSprinkler/OpenSprinkler-App/tree/master/www

BTW, I got it working on a local Windows 10 web server no problem after I used http: instead of https.

Never could get it to work with https, but that’s probably due to my lack of skill in dealing with SSL certificates, etc.

I really want the web server on the pi that’s driving the opensprinkler hardware–that’s next.

[Samer]

The zip is always updated on release however the Github link is the “bleeding edge” release which also works.

The SSL is is an issue in the apps if it’s not valid (self-signed). Try using a free certificate like start-ssl.com.

[davethomaspilot]

Ah, thanks. I’ll stick with the released version in the .zip file.

It worked painlessly (still using http, not https) on an apache server running on the same rpi that’s hosting the opensprinkler firmware.

So, on an rpi, other than automatically getting the latest released js, why would one want to have the UI served in the cloud rather than locally?

Just want to make sure I’m not missing something important…

[Samer]

For the Raspberry Pi, it can certainly be a part of the distribution however the way the firmware evolved, Pi was not the first platform for it. Now that support exists, it still functions like the Arduino (depending on the cloud). But as you have said a local Apache can accomplish the same thing however manual updates would be required to stay updated.

[Peter]

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:1

Changing 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

[davethomaspilot]

You said you added a .htaccess “to config the addition file types”. But maybe you have a typo?

I have the following at the bottom of /etc/apache2/apache2.conf on my rpi:

Header always set Access-Control-Allow-Origin “*”
AddEncoding x-gzip .cgz .jgz
AddType text/css cgz
AddType text/javascript jgz

I’m not very skilled in js, just monkey read, monkey do. But it work ok with those chants.

[Peter]

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 jgz

Another 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.

[davethomaspilot]

Good update–

I too had to do the “a2enmod headers” and stumbled on the “http://os_addr/su ” typo. Sorry that I forgot to mention that!

Another small change with apache is that the web files now need to go into /var/www/html rather than just /var/www.

I added everything to /var/www not /var/www/html and it worked fine.

But, I did not use the <Directory> </Directory> tags. I assumed that when you specify a directory to “limit the scope” of the commands, the commands would apply to all child subdirectories of the specified directory also. So, adding <Directory /var/www/> wouldn’t narrow the scope at all, so might as well leave it out.

I think that if I added additional .js or .html files for something unrelated to OpenSprinkler then it would be better to have the OpenSprinkler stuff down in in its own directory. Then I could use the <Directory> tag to make the commands specific to OpenSprinkler.

[Peter]

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).

[Author]

Posts