1000² Control panel horror

Intro

I have been making some slow progress with my smart home project. I have completed a small assembly run of motion sensors, there are plenty of things that are working and I shifted some focus on making a control panel.

What I normally want is a control interface that works well from both a PC and a phone. Bonus if it can look nice on a tablet to have one real control panel on the wall. Plus, I should design the interface only once and maintain the same structure and format on all devices. Easier said than done…

V1: Node-RED

This first iteration of control panel was in Node-RED. This is where I hit the first row of problems.

It looks totally different on computer vs mobile.

The problem stems from how different devices render fonts of the same size. After a lot of playing around I found a solutions that is feasible within some limitation. With an appropriate number of columns (i.e. 8) per tab, I can get one tab to fit in the width of a modern phone, while on the PC I can have multiple tabs visible side to side. Note: the mobile look will depend on screen resolution, but most smartphones are at least full HD nowadays. This gives you a rather different order. For example the data logging tab I use will look like this on a PC:

while on a phone it looks like this

I found this setup acceptable, considering how easy Node-RED makes creating these graphs and widgets for the web interface.

Graphs load slow.

While I could accept the results above, the next thing has puzzled me for a long time. I am running Node-RED (+mosquitto and a few other things) on a raspberry pi 3b+. Whenever I load the page showing the data logging of different parameters it takes a long time. I am talking about 5-6 seconds on a full PC, 10-12 seconds on a high end phone (note 9). This is unacceptable considering how few data points there are in each graph (1000 per plot).

I looked at

• CPU usage on the raspberry pi: small, not even 10%.
• Disk usage on the raspberry pi: almost nothing, no wait time.
• Moved the pi to SSD (for disk endurance as well)… still no change.
• Checked network bottlenecks, used both wifi and cabled on all devices. No difference.
• Checked amount of data exchanged for that data log page: just 1.4MB.
• Checked memory limitation of Node-RED (it was already done).
• Checked using an older phone: time loading is much higher there.

Aha! It has to do with the processing power of device displaying the charts. After some investigation, it turns out it has to do with the way Node-RED renders charts and other software would be better at this. Source here: “The performance of the charts is very bad comparing with CanvasJS that I use in my applications. Can draw 100.000 points in a few milliseconds. With node red I have to limit at 1000 points in order to have a acceptable experience.”

So, unless something about Node-RED changes, it’s a dead end for charts, unless using some other software.

V2: open HAB

My intention towards the home automation was to use Node-RED for a lot of logic and custom hardware and use something like open HAB for nice panel displays and integration with multiple off the shelf devices. open HAB offers multiple web interfaces.

• Paper UI lets you do the technical part, configuring the devices and managing open HAB.
• Basic UI is the classical web interface they have. It requires manually writing site maps. Similar to Node-RED, this interface can show one column on mobile and multiple columns on desktop. I don’t really like it because it has small graphs, text and pictures, while the majority of the screen is empty space.
• Classic UI is just an older looking Basic UI.
• HABPanel is the new modern interface. It can be easily designed directly on the target device using drag and drop widgets. See this video.

So off I went to HABPanel thinking it will be the end solution. Oh, I was sooo wrong. Here as well, you cannot create one interface that looks good everywhere. (Sorry for bad quality pictures, I forgot to take screenshots and changed the design afterwards).

This UI as well, was designed to look good on only one type of device at a time: “The issue is that some sizes (text, icons) are fixed in the widget’s settings, and this demo configuration wasn’t designed with phones in mind but tablets in landscape orientation. For phones in portrait orientation, Basic UI does a good job adapting the display of sitemaps according to the screen width. HABPanel doesn’t do that (so-called “responsive design”) on purpose because it led to more problems – although there’s an experimental option to enable at the dashboard-level in the latest snapshots.“ Source.

Wait, it gets more annoying

I settled on having two interfaces, because the HABPanel will look good on a tablet and I need to use Basic UI for mobile. Following an imaginary time-lapse of some coding, i got a basic one room interface working in Basic UI. Only to find out that some elements do not update, which is reportedly known, but downplayed to a browser problem. However, none of the browsers I tried (and I tried a few) seemed to work. So, there is this then….

Conclusions (for now…)

In random order of importance

• The web interface will appear differently based on device size, screen size, screen orientation and browser.
• It takes an incredibly long time to create a panel that you will like, there is plenty of fiddling.
• Hierarchy of elements shown in the interface is not trivial. I found that location is not always the best.
• Node-RED sucks at graphs, will try Grafana later.
• I am stuck designing multiple interfaces or heavily compromising.
• It does seem like OpenHab might be a fruitless detour, with Node-RED on its own still doing best.