前言

为什么要搞一个HomeLab呢，其实想想也就是两方面需求：自托管服务和学习折腾

从本站建站起，大概是16年的样子，摸索着在阿里云购买了一台1核1G的小主机，就开始慢慢熟悉Linux系统了，博客所在的宿主服务器也经历了至少4次的变更，直到去年生日的时候，收获了一台心心念的Home Server，或许这次就是服务器折腾的终点了吧（也不一定）

总览

截止到2025年3月，差不多折腾了半年的时间，基本的功能都已经搭建好了，大致介绍下HomeLab的结构：

背景

HomeAssistant默认使用SQLite作为数据库，虽然对于小规模的家庭智能系统来说，SQLite已经足够了，但是随着设备数量的增加，SQLite的性能会逐渐变差，所以有必要考虑使用其他数据库来承载这些日益增长的数据。

HA支持多种数据库，包括：

• SQLite
• MariaDB
• MySQL
• PostgreSQL

废话

好久没怎么写博客了，最近在沉迷Homelab/HomeAssistant，所以就想着把这个过程记录下来，开个大坑。

安装部署

安装方式

HomeAssistant支持多种安装方式，包括：

• HAOS
• Container
• Core
• Supervised

其中Core和Supervised不是很常用，首先排除，HAOS和Container的选择我纠结了很久。

准备折腾一套极客范满满的智能家居系统，过程记录整理如下

没有超链接的就是计划中还没写，后期随时可能会变动

• 安装部署，以及相关重要概念
• 使用TimeScaleDB替换默认数据库
• 配置文件拆分整理
• 外网访问
• 米家设备接入
• 其他第三方设备接入
• ESPHome
• MQTT服务器搭建
• NodeRed
• 灯光控制方案
• 窗帘控制方案
• 环境（暖通空调）控制方案
• 墙壁控制面板
• 监控
• Frigate
• 语音助手

前言

新家打算做个骚一点的全屋智能，打算全部尽量自己手搓。由于距离开始装修还有挺长一段时间，手有点痒，再加上之前买的青萍的空气检测仪开不了机了，于是决定自己动手做一个可以检测多种空气指标的检测仪。

先来成品图~(没错，这玩意其实4月份就做出来了，博客愣是被我拖了大半年hhh)

使用方式

文件存储

作为一台NAS，最基础的功能便是文件存储了，得益于新买的8T硬盘，我可以把之前十多年攒下来的所有数据资料都存起来了。

最先遇到的问题是如何创建划分共享文件夹。在上一篇文章发布后，我又重装过一次系统，把系统盘从机械硬盘变更到了新买的一块2T固态上，8T机械盘纯当作数据盘来使用。我原本打算还是跟重装系统之前一样，用Multimedia文件夹来存放所有的多媒体文件（照片，音乐，视频），但是在数据盘新建文件夹时，总是提示我文件夹名称无效，如下图（图里是Web，实际上Multimedia是一样的）：

需求背景

讲道理NAS是今年的618买的，折腾完就想写篇博客记录下，结果就愣是拖到了双十一😂

迫于自己的个人文件越来越多，一直想把2011年拥有手机以来拍过的所有照片系统性地整理起来，再加上现在台式机已经换成了全固态，买一台NAS放到家里就提上了日程。

其实两年前装修的时候就已经在考虑了，只不过那时候资金正紧张，算了笔帐，NAS加硬盘的成本还是有点高，就暂时搁置了。

时间来到了2021年，购物车里一直躺着西数HC320和群晖920+，结果4月份突然冒出个奇亚币，矿老板们疯狂买硬盘挖矿，眼睁睁看着硬盘从1300涨到了接近3000……果断放弃，继续等硬盘回归正常价格。

后来的事情已经知道了，奇亚币崩盘，硬盘逐渐开始降价，差不多618的时候终于降回了21年4月的水平，果断下单。

要点

地块渲染主要使用了RenderBatchGroup来避免过多的GameObject，并辅助以有BurstCompiler加持的裁剪函数以加速渲染。

细节

需求分析

目前有个需求是，我们可以在地图上绘制若干片不同类型的区域，对于每种区域，地块需要有不同的颜色叠加，我们需要给每个地块设置一个颜色属性。

所以目前就无法使用SRP Batcher来辅助合批了，因为这玩意目前并不支持通过MaterialPropertyBlock来设置PerObject的属性（给同一批次的每个渲染对象设置不同的属性）。当然SRP Batcher支持设置PerMaterial的属性，因此遇到使用同一个Shader的不同材质时，就可以对其进行合批，我会在之后其他元素的渲染时利用到这个特性。

我最终使用的还是传统的GPU Instancing的方案，这样就可以满足目前的需求了。

过去的整理和总结

自从18年刚开始有这个想法到现在已经差不多两年半了，然而连一个Demo都没拿出来😂总结了一下，项目的进程大概分为了三个阶段：

一周目

18年5月，决定自己做一个模拟经营类的游戏。最初的想法是用尽量新的酷炫的技术来开发，当时Unity的DOTS刚出来（当时还没有DOTS这个名字），简单了解了下发现ECS的设计模式很适合于模拟经营（我设想的方向是类似《监狱工程师》这种场景种同时存在着大量单位在运动的感觉，而不是《边缘世界(Rimworld)》这种只有少量角色但每个角色的行为都有精密的设计，总之就是“大规模”）。当时已经有Entitas这个第三方的UnityECS框架了，不过既然Unity官方在推，即使还是早期预览版，我还是对官方框架的前景非常看好的。

18年5月到11月，平时工作也比较忙，也没啥时间做项目，所以进度推进还是很慢。然后最致命的是，Entities库在早期的更新频率非常快，API的变更也非常快，经常过一个月更新一下新版发现各种API都改名了或者直接取消了，写起来就很痛苦。

这倒不是Unity的锅，人家在论坛里一开始就强调过，现在还处于早期预览阶段，对于某种需求，目前存在着多种实现方式。官方会观察各位开发者的反馈，最终只会留下一种方式，其他的会被取消（在这里有持续讨论有关API的易用性）。

再加上ECS的配套功能非常缺乏，而且思维还没来得及转换到面向数据的设计思想，进度推进就更慢了。

前言

接触Unity的DOTS其实已经有差不多两年时间了，当年刚开始研究的时候甚至还没有DOTS这个说法，期间其ECS库的API各种变化，不过到目前来看基本上稳定了，所以决定今天把自己的理解整理出来，便于回顾查阅。。。

什么是DOTS

DOTS全称Data-Oriented Technology Stack，官方中文名叫多线程式数据导向型技术堆栈（来源于官网），顾名思义这是个“技术栈”，这里面包含了多个技术：

1. Entity Component System(ECS)
2. C# Job System
3. Burst Compiler
4. And more(Physics, NetCode, Tiny…)

需要我们编写业务逻辑代码的部分都在第一项”ECS”里面，所以之后的介绍大多都会围绕如何（以面向数据的思想）书写基于ECS的代码。