I’m setting up a large Home Assistant installation (19 tablets with tileboard, 42 Aeotec multi sensors, over 100 Leviton Wifi dimmers, etc) running on Ubuntu 18.4 & Docker.
My question: does Home Assistant support full multi-threading? With other words: should I choose a processor with many cores, high clock-speed or even multi processors (eg 2 x E5-2670)?
It is threaded (you can see this in the logs) but you don’t need to go nuts. A decent i3/i5/i7 will run really well.
I have a large system with over 100 light switches (Lutron Caseta on a pro hub) and about 120 z-wave/z-wave+ devices. A i7 NUC handles this no issues at all.
One place to spend some time planning is on what protocol to use for your devices. I am a big fan to use several to spread it across several different technologies.
The reason is all these radio networks like Zwave, ZigBee, etc, are half duplex and SLOW. When you have >50 or so devices off one link you start to see things get bogged down. At 100+ devices it becomes unusable.
I originally had all my devices on zwave but moved to Lutron for lights/switches to get another radio technology running in parallel. This was a huge win for performance.
I also strongly suggest you use wired stuff where you can fo doors, windows, etc.
Good to see that we were thinking along the same lines. I have chosen wifi for all my switches, and will use the new Konnected! Pro boards for the (wired) window and door sensors.
I’ve done some testing with 10 constant-on, wall-mounted tablets running tileboard, and have noticed that they can become unresponsive when the server is not sufficient. I’m running on a Lenovo T140, i.e. a Xeon E3-1225. That’s mainly where my ‘power demand’ came from.
Home Assistant is single threaded (because Python is). So you should go for the high clock speed rather than extra cores.
However, Home Assistant usually does not need very much power. When things are slow it is often due to misbehaving integrations that can block everything else. So picking well-supported devices is also important.
Do you connect directly or via some reverse proxy?
I only have 2 tablets and don’t notice a slow down, but with 10 nit sure what limitation you maybe hitting.
Also I think thinks like mqtt2zigbee and QT-Zwave (when it comes out) will help scalability as you push some of the device management overhead onto other systems that technically won’t need to be restarted often so state should always be known.
Lets see what @amelchio responds over the threading as I was pretty sure some stuff was from the logs showing SyncWorkers_1 to _8. But if wrong then you may want to re-think your approach.
The delays that I experienced are not really delays, more time-outs in Tileboard. A simple ‘refresh’ in Fully did the job, but I’m trying to avoid that. My thought was that it had to do with some timeout on the websocket with Tileboard (so just a simple webservice). That’s why I thought adding more power could do the trick. I assume whatever service is Tileboard is not running on Python? Does anybody know what webserver is running here? Will it profit from multi-threading or multi-processors?
I wouldn’t worry about HA general requirements but look into requirements for things like image processing if you plan to use that. This is where you will kick yourself for not getting correct hardware.
I dont agree with you. Im using a 10th gen Nuc i7 which has an average of 40% CPU load. Due to the image processing of 7 cameras and running frigate. I tested this with shutting down one core in the bios of the NUC and the CPU load went up to 50% load. when disabling another it ran up even higher. So more cores are surely doing something.
Also something to take in account is the heat. My NUC runs at around 50 - 70C at the moment. I ordered a custommade watercool case for it. I really wonder if this is going to help me get the temps down.