AV UI’s With HTML5 – Part II

Table Of Contents

  • Part 1: The Browser & Web Pages
    • HTML
    • CSS and Javascript
    • The DOM
    • A Word On Frameworks
    • Resources
  • Part 2: The Server
    • Design Considerations
    • Development vs. Production
    • Number Of UI Devices
    • Authentication & Data Storage
  • Part 3: Integrating with AV Systems
    • HTTP & REST API’s
    • WebSockets
    • Design Strategies
    • Hardware Choices
  • Part 4: Case Studies

The Server

Now that you understand how to make a web page, the next step is getting those web page files into the browser. For the previous examples, you probably just double-clicked on the HTML file and it opened in your default browser.

That’s not what happens when you’re surfing the web. On the internet, pages are loaded from a web server. Using a server also makes sense for AV user interfaces; even if the AV system does not have internet access.

Design Considerations

Instead of thinking of web pages and web servers, it is a good idea to remember both the browser and the server are software applications. They are computer programs that run on one or more devices.

Where those programs run, what their responsibilities are and how they talk to each other all come together to form the design of your system.

Here are some basic things you should consider when designing for AV control with web pages:

  • Development vs. Production
  • Number Of UI Devices
  • Authentication & Data Storage

Development vs. Production

Being able to develop and test right on your laptop is one of the big advantages of web page development over traditional AV touchpanels.

You can write your code and immediately test it in a browser without having to upload to a touchpanel. Most web frameworks even support automatic reloading, so the page refreshes every-time a file is saved.

Web browsers like Google Chrome typically have useful development tools like a console, debugger, file viewer and responsive preview. Hit F12 in Chrome to see all these goodies.

When developing on your laptop, the server and browser run on the same device (your laptop). Which brings us to our first design…

Everything On A Laptop

The same design can be used in production when you have a dedicated user interface device like a touch display (in a real project the browser would be in full-screen kiosk mode with the address bar hidden)…

Everything On A Tablet

You may be thinking…

“That’s a cute way to show some buttons on a page, but how do you actually control stuff? Can I just open a TCP port from the browser and start sending comands?”

A quick detour to the OSI model will help answer that.

As powerful as browsers are, you can’t just do whatever you want. There are built-in constraints that guarantee a certain level of security.

And not being able to open TCP sockets from a browser is one of those constraints.

If you could open TCP sockets from the browser, then any website you visit would have direct access to your local network. Not good.

The browser uses HTTP to communicate with servers and most AV devices use TCP for external control. HTTP is built on TCP, but they exist on different layers of the OSI model.

So what’s a programmer to do?

There are two options.

  1. You can use websockets (covered in Part III) to connect the browser to a traditional AV control processor.
  2. Or you can use the server application as a middle-man between the browser and your AV system.

Part III goes over these strategies in more detail. For now, just keep in mind that you can do more with the server than just, uhh… serving web pages.

Number Of UI Devices

It may sound nice and clean to have one device running the server and browser. But things get messy as soon as a second user interface is added to the system.

Now you have two places to upload the same files. That kind of duplication just doesn’t scale and creates a lot of error-prone busywork.

When multiple user interfaces are required, use one central server that the browsers (aka clients) get their files from.

Central Server

Authentication & Data Storage

Dealing with databases and authenticating users are not common tasks in the world of AV programming.

Most authentication is done by physical presence – if someone can touch the UI, it is often assumed they are allowed to use it.

We need to be a bit more thoughtful with web page UI’s served over a network.

If the network is secure and unauthorized users cannot gain access to it, then physical presence may still be enough.

But if the network can be accessed through WiFi or a network jack, physical presence is no longer a viable authentication strategy because the network makes it possible for someone to control a room without being there.

In fixed installations, a token embedded in the url may be all you need. Here’s a sample URL for a server located at 192.168.1.11 and an authentication token of abc123 (please use better passwords than that)…

192.168.1.11/index.html?token=abc123

Such a URL could be entered in each touch display during system commissioning. The token should never be visible to users because the browser is in kiosk mode with the address bar hidden. The browser should also be locked as the only app allowed to run.

When the browser requests the web page, the server checks the token and only serves the page if there is a match.

A more typical username and password authentication may be a good approach for smart home control. A certain amount of responsibility can be expected of users living in the same home (it’s probably ok if someone can control a room they are not in, as long as they don’t take the last Netflix stream – then there’ll be hell to pay).

Storing users and their hashed passwords is where a database comes into play. Centralized data storage is a must when users can access your system from their personal devices.

Otherwise you’ll get a support call every time they get a new phone. (Sound familiar?)

There is a lot more to consider for BYOD control of public areas. Hotel rooms is an application that comes to mind where allowing users to control spaces from their personal devices might be useful.

You’d need to figure out how to authenticate the right people to the right rooms at the right time though.

And while that sounds like a fun project, let’s not get distracted. We still haven’t controlled anything yet.