Another RPi alternative: The Rock64

[TerryE]

I've got the first iteration of my House system up.  It's really too modest to call a Home automation system, as the whole concept is a bit of an anathema to Jan.  If I try to have a conversation about any of this with Jan, then her eyes start drooping and her chin dropping in under a minute -- far more effective than sleeping pills or hypnosis.  What she wants is a big nob on the wall.  (Anyone heard that before?)

 

By way of context my overall approach currently is to use SBCs as headless servers to do the serious processing. These have no realtime I/O functions as this is handed off to dedicated ESP modules to handle the IoT stuff (in my case, though you could just as easily use Atmel/Arduino, RPi0 or equivalent off-the-shelf modules for this).

 

All of my IoT devices are isolate from the House Enet and internet.  There is no routing path between.  They are on a dedicated private IoT Wifi service which is not advertised and has a nasty password that even I can't remember.  There is however a Node Red /broker SBC connected to both networks and its HTTP based UI is access path to the IoT devices.  I don't use TLS on the IoT Wifi, as I am not concerned about eavesdropping, however any sensitive data elements are encrypted and all packets digitally signed to prevent injection.

 

But the main thing that I'd like to discuss here is the SBC side.  To be honest I am a little dissatisfied with the RPis in this role.  I currently split the work between 2 RPis, but since this is a 95:5% split, having the second RPi just complicates things.  It is a lot easier just using one server to host Node Red, the MQTT broker and a database.

 

Node Red is an amazing package, but this is really the subject of another topic.  But can be a resource hungry if you are not careful, and if I want to store all historic data then I need a decent database and HDD / SDRAM capability.  The problem here isn't so much the speed of the RPi CPU, but its limited RAM and the USB2 constraint.  I already use a headless configuration on the SBCs using a stripped down Jessie server configuration, but I need a reasonable amount of RAM to run a MySQL InnoDB engine and the node.js pool. And it world also be nice if HDD/SDD performance wasn't USB2 limited.

Having reviewed the options, I am going to try a ROCK64 4GB single-board computer which costs £57 including shipping as compared to the RPi at £35, but the Rock64 has 4× the RAM, a USB3 port and it benchmarks at roughly 10× the speed of an RPi3.  The CPU speed isn't so much of an issue in this case, but the RAM and USB3 just gives me so much more headroom.  It can also boot off eMMC which is faster and more reliable than microSD (though I'll probably just stick with microSD as the root partition will be on the HDD anyway). 

 

This Rock64 does have a few downsides: the support and community isn't nearly so strong as for the RPis, but for a basic headless server, it should be fine.  There's no on-board Wifi,  but there is a second Gb Enet port brought out to the second on-board header so I can just directly connect it to both my main house hub and my IoT Wifi hub.  Anyway I'll keep you posted if anyone is interested. 

 

Some background context, which can be skipped if you aren't interested

• I use Wemos ESP8266 modules for all of my I/Os and sensors.  These are cheap  (<£2 each) so I buy them in lots of 10.  This £2 module includes USB power/serial port, Wifi, an embedded flash-based file system and a decent amount of I/O.  This is for a few of reasons:
  • I am one of the core developers one of the runtime systems (Lua) for this device as a hobby, so for me it makes sense to use it. 
  • When you are breadboarding I/O stuff it is quite easy to fry a GPIO buffer or other board component. At £2 when you've got a dozen spare, this is a shrug; toss the chip and reach for another.  RPis cost ~£40 so I don't hold may spares and crisping £40 makes me cringe. 
  • Sonoff also do a range of devices, plugs and switches which use the ESP8266 internally so I can buy these and reflash the firmware with my own build.
  • All ESPs are served by a provisioning system, so I can update their Lua applications code as needed (hands free; the chips have embedded Wifi).
• I currently use 2 RPI3s:
  • one to act as a Node Red / MQTT broker.  This has a USB attached HDD.
  • one to control the two ESPs which drive all of my CH and DHW sensors, flow meters, relays, etc. This is second is battery backed. 
• My maintenance policy is centred around keeping a full spares inventory of any modules and SBCs so I can do a quick cold-swap on failure.

Overall, I am happy with this approach.  It is low cost and very flexible. The ESP mother boards (my equivalent of custom PiHats) are current Beta revs, and I have some changes planned.  For example I use two ESPs for my DHW/CH control, but I have decided to consolidate all I/O onto a single ESP as one can handle this comfortably.  I also implement a set of safety rules at the ESP tier that are independent of the Node Red Flows; for example: The Willis heater won't turn on if the pump isn't running; it is automatically turned off  if any slab return is > 30°C or the Willis chamber itself is >35°C.

[MikeSharp01]

That is quite some post Terry! I started responding before heading off this morning and kept returning to it in then end here is my penny worth.

 

A few things / questions spring to mind. 

1. Is there a schematic of it all somewhere that might make it more accessible to mortals.

2. How much data is being pushed onto the HDD and as you mention headroom how much do you anticipate on a minute by minute basis when it is running flat out.

3. Although you say there is no routing path you seem to  have devices that are connected on both networks are these not a potential weakness?

4. The rock looks interesting but I cannot help feeling that you are going to end up with such a wide array of technologies that should anything happening to you, heaven forbid, would render the house control system somewhat impenetrable.

5. Have you looked at the HIVE protocols to see if compatibility might be possible I wonder or one of the commercial, albeit often proprietary, BMS protocols?

 

I need to think this through as I will have the same basic issue but I was going to have all nodes as Web servers with some sort of domain majordomo bringing it altogether as another Web site. Speed I think is not a problem, we won't need Ghz sampling rates. Although I also played  with the idea of a distributed intelligence mesh with heuristic / genetic opportunities to devolve processing once a pattern emerges. I almost had this in another life with a bitbus network where each node could see every other and track variables as proxy settings or readings but getting the intelligence to migrate was never a success although the system worked without it. I have better ideas on how to make it work now, with today's technology, by providing a set of high level commands that can be built as programmes on the nodes by themselves to replicate the control regime in the pattern. At the very least I would want them to tune. The other thread on the DS temp sensors is also of interest alongside the challenges of solar gain. I came up with a sensing plan, see attached so I could monitor the slab temp near the pipe and near the surface thus giving me the chance to see Solar gain getting ahead of the UFH and the gradient when heating and or cooling. I would put these on a 1m grid in the front three quarters of the main space (9m x 9m) as the rear portion gets almost no direct solar.

 

[TerryE]

@MikeSharp01 Mike, if I could summarise my architecture, it is:

1. Do any H/W connecting with off-the-shelf (OTS) components / devices that can talk MQTT if cost effective.
2. Do any custom stuff using ESP modules sitting on a largely passive board which does wiring to connectors and keep at least one spare for cold-swap on failure.  In the case modules like the ESP at least half a dozen.
3. Have a dedicated IoT Wifi service for all remote devices ESP or OTS, or json over USB virtual serial in the case of essential services where I don't want the WiFi dependency.
4. Use Node Red, MQTT, and a MySQL InnoDB database as the main applications platform to glue everything together.
5. Use a minimal headless Linux server to run [4].   This has to be connected to the both the Home Network and the IoT network.  This is the only device connected to both networks and routing between them is not enabled.
   • The Node Red UI only listens to the Home Network on a non-standard port
   • MQTT listens serves both.  This one I don't like and need to thin about.
   • MySQL only listens on a Unix socket and so is not available off server.
   • I have a small number of web scripts on another non-standard port.
   • The only other open port on the server is SSH on a non-standard port; certificate only, no password-based logon. 

Because of [2], the server really only needs RAM, USB and networking to work reliably.  I don't make use of any fancy hardware such as graphics acceleration, GPIOs, etc.  I also use a very stripped down version of Debian server.  For example no Apache2, Samba , FTP or the like.  If I could get a 2Gb RPi then I'd use that, but really the hardware is a detail and moving to a new SBC pretty trivial.

 

BTW, I would prefer to use HTTPS on my Home network, but certainly Android / Chrome doesn't have a simple and robust way of allowing you to self-certify for your own server on 168.192.1.250, say, for access from 168.192.1.* only.  Google really want you to use the cloud for everything, so chrome doen't play nice with self certificates.

 

With enough InnoDB pool, the server will does bugger all I/O (just like the VM running this forum), mainly just flush updates through the file system, but IMO its just easier not to have to denormalise schema for performance.  If I am taking temperature samples every minute then that's  ½M rows a year per sampling stream. Seems to many to me, but ... Need to ponder more.  I might need to move to a different no-SQL DB for the raw historisation data.

 

7 hours ago, MikeSharp01 said:

should anything happening to you

 

Well as I said in the intro Jan and computers don't mix; she a pure user.  I need (i) a backup who understands my system; (ii) a cold-swap spares inventory to cover the expected life of the system.   My son-in-law was a sysadmin before he became a manger of the same, but he still gets his hands dirty and is into this sort of stuff so my aim is to have it so he understands the system.

 

I really don't think that moving to a commercial system such as Loxone helps.   For example, citing one one member here that I know uses it, does @jack's wife understand enough about his Loxone setup to maintain his system if he fell under a bus, and what happens with his system in even 5 years time and  when there are no spares are available for this generation of system?

 

Can I take your other point on the DS18B20 thread?

 

On reflection, I've also decided to try the single RPi3 config to see if I have any performance issues before swapping to a higher RAM SBC. 

[jack]

6 hours ago, TerryE said:

I really don't think that moving to a commercial system such as Loxone helps.   For example, citing one one member here that I know uses it, does @jack's wife understand enough about his Loxone setup to maintain his system if he fell under a bus, and what happens with his system in even 5 years time and  when there are no spares are available for this generation of system?

 

No, my wife wouldn't be able to maintain it. But the system is standardised, and the way the software works means that it's more or less self-documenting, and very easy to understand due to the visual programming language it uses. For example, here's the programming page for the blinds in the study:

 

 

Inputs are on the left, outputs on the right. FYI, Auto Blinds Up is a memory flag, which can be used to share values and signals between pages.

 

I'd expect a Loxone consultant to be able to come in and get the gist of most of the important stuff in a matter of minutes.

 

As for spares, when we get to the point where there's no longer going to be compatible hardware, I'll buy an additional spare. Also, the way everything is wired means that any of a number of other solutions would be virtually plug and play on the hardware side, and I don't do any crazy stuff that would be a lot of effort to replicate in another system.

 

I also presently don't have my MVHR or ASHP controlled by Loxone. At the moment, the only integration plans are to get the ASHP under Loxone's control, but that will simply be a call for heat signal, so again, pretty standard.

[TerryE]

@jack this looks a bit like Node Red to me

[jack]

Yes, it does, although Loxone appears to pre-date Node Red  

It looks like someone's written a Loxone/Node-Red interface: https://allgeek.de/2017/10/05/node-red-in-verbindung-mit-loxone/

[SteamyTea]

How have I managed to miss Node Red, seems my idea of making a fairly simple controller has already been done.  Good, I hate all that poxy coding.

[readiescards]

Hows it going with the TheRock64?

[TerryE]

5 hours ago, readiescards said:

Hows it going with the TheRock64?

 

It isn't.  In the end I had  just too many other things to do to buy one of these and have a play, so I am running on an RPi + SSD config as discussed here:

I am still unhappy with the RPi -- only 1Gb RAM, no USB3 or SATA.  I run my SBCs as a minimal server instance (e.g. dietpi).   The main outstanding issue is the SSD support over USB in Linux, as the USB drivers don't currently pass through the ATA TRIM command to the SSD controller. 

[SteamyTea]

37 minutes ago, TerryE said:

I am still unhappy with the RPi -- only 1Gb RAM, no USB3 or SATA

In all fairness to the RPi, none of that was a surprise, the spec is well known.

 

I admit there are things I would like on it, RTC and a few ADC/DAC pins, but it is what it is.

 

In 2013 we could never have imagined the RPI at 30 quid.

Edited December 27, 2017 by SteamyTea

[Jeremy Harris]

The closest I've found to a RPi, in terms of price and performance, but including a SATA port, is the Banana Pi, or the Banana Pi M2 if you want a SATA port and WiFi/BT, like the RPi3,

 

To all intents and purposes the Banana Pi is about the closest any of the cheaper SBCs come to emulating the RPi, and will run Raspbian, if that's your preferred flavour of OS.  Still no RTC, though, but adding one via I2C is as easy as it is on a RPi, or you can just use a time server if the unit happens to have an internet connection.

 

TBH, just having a SATA port makes the world of difference, as it means getting away from having to boot from an SD card, or via a slow USB 2.0 interface, and allows better control of the filing system.  At £32 inc VAT for the Banana Pi, or £35 inc VAT for the Banana Pi M2, there isn't much of a price difference with the RPi 3 either.  The main snag is that the board is physically a different size, so won't fit in cases designed for the RPi.