Home Assistant 读取 ESXi温度

目录一、先把走不通的路堵死顺便说清楚风扇转速为什么没戏二、用 vsish 读 MSR两个容易踩的点顺手做个压力测试三、数据怎么送进 Home AssistantHA 侧配置四、网络上的两个坑坑一ESXi 防火墙默认丢弃出站流量坑二用 IP 访问会被 nginx 拒绝五、采集脚本六、让配置扛住重启七、验证八、这个方案的局限小结家里那台 ESXi 用的是消费级主板一直想把 CPU 温度接到 Home Assistant 里看看曲线。本以为是个半小时的活结果从温度到底怎么读到数据怎么送进 HA连着踩了四个坑折腾了小半天。这篇把过程完整记下来包括那些走不通的路——知道哪条路是死的比知道哪条路能走同样有用。先说结论消费级主板上ESXi 的风扇转速读不到但 CPU 温度可以读办法是绕过主板、直接读 CPU 内部的 MSR 寄存器。环境ESXi 6.7主板 MSI MS-7A74B250 芯片组CPU Pentium G46002 核 4 线程Home Assistant 2026.7HAOS装了 NGINX SSL proxy 插件文中 IP 均为示例ESXi192.168.1.10HA192.168.1.20域名ha.example.com一、先把走不通的路堵死服务器主板的温度监控一般走 IPMI 或者厂商的 CIM provider。消费级主板这两样都没有。我把四个可能的通道全试了一遍结论是全军覆没IPMI / BMC[rootesxi:~]esxcli hardware platform get Platform Information Product Name: MS-7A74 Vendor Name: MSI IPMI Supported:false[rootesxi:~]esxcli hardware ipmi bmc get Retrieve IPMI Baseboard Management Configuration failed:No BMC Device found[rootesxi:~]esxcli hardware ipmi sdr list 空一条都没有CIM 健康传感器[rootesxi:~]vim-cmd hostsvc/hosthardware|grep-icEnumericSensorInfo|fan|rpm0一条传感器信息都没有。这个接口在服务器主板上会列出一堆温度、风扇、电压项这里是空的。WBEM 服务[rootesxi:~]esxcli system wbem get Enabled:falseCIMObject Manager PID:0服务本身没开。而且就算开了也没用——它需要厂商提供 CIM provider 来喂数据消费级主板不会有。vsish 的 IO 端口节点[rootesxi:~]vsish-els/hardware/port/ size/只有一个size/不是能读写 IO 端口的接口。顺便说清楚风扇转速为什么没戏很多人包括当初的我会想温度能读转速应该也能吧不能。风扇转速是由主板上的 Super I/O 芯片常见的是 Nuvoton NCT6xxx 系列通过 0x2E/0x4E 这两个 IO 端口提供的需要nct6775这类 lm-sensors 驱动去解码。ESXi 是闭源的 VMkernel既不带这个驱动也不开放用户态的 IO 端口读写能力——它的设计里风扇监控只走 IPMI/BMC 或者厂商 CIM那是服务器主板才有的东西。所以在 ESXi 上消费级主板的风扇转速就是读不到。想监控只能走物理外挂把 4pin 风扇的转速信号线第 3 根接到 ESP32用 ESPHome 的pulse_counter组件读 RPM。那 CPU 温度凭什么能读因为它压根不经过主板。温度传感器在 CPU 硅片内部读数通过 CPU 自己的 MSRModel Specific Register暴露跟主板有没有 BMC、有没有 Super I/O 完全无关。二、用 vsish 读 MSRESXi 自带vsish可以直接读 MSR。用到两个寄存器0x1a2MSR_TEMPERATURE_TARGET里面存着 TjMax也就是这颗 CPU 的温度上限0x1b1IA32_PACKAGE_THERM_STATUS存的是距离 TjMax 还差多少度注意它是差值不是绝对温度实际操作[rootesxi:~]vsish-eget /hardware/msr/pcpu/0/addr/0x1a2 0x641400[rootesxi:~]vsish-eget /hardware/msr/pcpu/0/addr/0x1b1 0x88390000换算规则TjMax (0x1a2 的值 16) 0xFF 温度 TjMax - ((0x1b1 的值 16) 0x7F)代入上面的数TjMax 0x641400 160x64 100 °C差值 0x88390000 160x8839再 0x7F0x39 57温度 100 − 57 43 °C两个容易踩的点第一只用 package 温度0x1b1别用单核的 0x19c。0x19cIA32_THERM_STATUS是每个核心自己的温度。问题在于核心进入 C6 深度睡眠后它的数字温度传感器会停止更新读出来是 34 °C 这种明显偏低的假值。我一开始同时采了单核和 package画出来的曲线单核那几条在 34 和 43 之间反复横跳看着像散热出了问题实际上只是核心在睡觉。package 温度是整个 CPU 封装的温度不受单核睡眠影响稳定可靠。第二pcpu 编号别越界。[rootesxi:~]vsish-eget /hardware/msr/pcpu/4/addr/0x19c VSISHCmdGetInt():Get failed: Not foundG4600 是 2 核 4 线程所以只有 pcpu0~3读 pcpu4 报 Not found 是正常的不是故障。顺手做个压力测试温度能读了正好验证一下散热。用md5sum /dev/zero起 4 个进程压满 CPU纯计算不涉及磁盘 IO# 注意这会让宿主机上所有虚拟机卡顿生产环境慎用Pforiin1234;domd5sum /dev/zero/dev/null21P$P$!;done# 一定要加个看门狗兜底防止 SSH 断开后进程留在后台(sleep200;kill-9$P2/dev/null)用vim-cmd hostsvc/hostsummary | grep overallCpuUsage确认真的压满了我这里从空载的 1039 MHz 涨到 6845 MHz满载 95%。实测数据室温 27 °C工况package 温度空载跑着 n 台虚拟机42~44 °C满载稳态50~52 °C停止负载 5 秒后47 °CTjMax100 °C满载和空载只差 9 °C停载后 5 秒就掉 4 °C说明散热器接触良好、导热路径通畅。如果硅脂没压开或者扣具没锁紧这个温差会明显放大停载后的回落也会变慢很多。三、数据怎么送进 Home Assistant温度能读了接下来是怎么把它变成 HA 里的一个实体。对比下几种方案Webhook选用MQTTREST API凭证权限只是一个随机 ID泄露最多能伪造温度读数需要 MQTT 账号全权限token实体质量有 unique_id可 UI 管理重启不丢同左无 unique_id重启短暂消失HA 侧配置在configuration.yaml里确认有这行大多数人的配置里已经有了template:!includetemplate.yaml然后在template.yaml末尾追加-trigger:-trigger:webhookwebhook_id:!secretesxi_temp_webhookallowed_methods:-POSTlocal_only:true# 只接受内网请求公网打不进来sensor:-unique_id:esxi_cpu_package_tempdefault_entity_id:sensor.esxi_cpu_tempname:ESXi CPU 温度state:{{ trigger.json.temp_c | float }}unit_of_measurement:°Cdevice_class:temperaturestate_class:measurement# 加上它才会进入长期统计能看月/年趋势attributes:tjmax:{{ trigger.json.tjmax | int }}raw_msr:{{ trigger.json.raw }}secrets.yaml里加一行值用随机串openssl rand -hex 24生成esxi_temp_webhook:你生成的随机字符串改完不用重启 HAreload 一下 template 集成就行。在 SSH 插件里SUPERVISOR_TOKEN是现成的ha core check# 先验证配置语法别改坏了curl-XPOST-HAuthorization: Bearer$SUPERVISOR_TOKEN\http://supervisor/core/api/services/template/reload四、网络上的两个坑这部分花的时间比前面所有加起来都多。坑一ESXi 防火墙默认丢弃出站流量脚本写好一跑就超时urllib.error.URLError: urlopen error timed outping 得通但端口不通。查了一下防火墙[rootesxi:~]esxcli network firewall get Default Action: DROP Enabled:trueESXi 防火墙的默认动作是 DROP而且对出站同样生效只有被规则明确放行的端口才能出去。实测[rootesxi:~]nc-z-w3192.168.1.208123# HA 默认端口不通[rootesxi:~]nc-z-w3192.168.1.20443Connection to192.168.1.20443port[tcp/https]succeeded!8123 被丢弃443 通。我没有去改防火墙规则。ESXi 加自定义规则要往/etc/vmware/firewall/写 XML重启和升级之后都会丢失得额外维护一套恢复机制不值当。443 是现成的通路上面跑着 HA 的 NGINX SSL proxy 插件它会把请求转发给 HA core。如果你的 HA 没装 SSL proxy 插件也可以考虑在别的机器上做转发思路是一样的别跟 ESXi 防火墙较劲。坑二用 IP 访问会被 nginx 拒绝改成https://192.168.1.20/api/webhook/xxx换了个错误ssl.SSLError: [SSL: TLSV1_UNRECOGNIZED_NAME] tlsv1 unrecognized name原因是 nginx 按 SNITLS 握手时携带的域名来分流。用 IP 直连时SNI 里带的不是ha.example.comnginx 找不到匹配的 server 块直接在 TLS 层就拒了。解决办法是用域名访问但让它解析到内网 IP。注意 ESXi 6.7 没有esxcli network ip hosts这个命名空间[rootesxi:~]esxcli networkiphosts list Error: Unknowncommandor namespace networkiphosts list直接写文件echo192.168.1.20 ha.example.com/etc/hosts这样既走了域名SNI 正确又不依赖内网 DNS 能否解析到内网地址。至于证书校验脚本里关掉了。ESXi 6.7 自带的 CA bundle 不含 Let’s Encrypt 的根证书验不过。考虑到是同一个交换机下的内网直连而且 webhook_id 本身就是凭证这个取舍可以接受。五、采集脚本ESXi 上没有curl也没有base64但自带 Python 3.5urllib 够用了。/vmfs/volumes/datastore1/scripts/esxi_cputemp.py#!/bin/python3# -*- coding: utf-8 -*-importjsonimportsslimportsubprocessimporturllib.request HA_WEBHOOKhttps://ha.example.com/api/webhook/你的webhook_idVSISH/bin/vsishTIMEOUT10SSL_CTXssl._create_unverified_context()defread_msr(addr):读 pcpu0 的指定 MSR。vsish 输出形如 0x883a0000。outsubprocess.check_output([VSISH,-e,get,/hardware/msr/pcpu/0/addr/addr])returnint(out.decode().strip(),16)defmain():tjmax(read_msr(0x1a2)16)0xFFrawread_msr(0x1b1)temp_ctjmax-((raw16)0x7F)payloadjson.dumps({temp_c:temp_c,tjmax:tjmax,raw:hex(raw),}).encode(utf-8)requrllib.request.Request(HA_WEBHOOK,datapayload,headers{Content-Type:application/json})urllib.request.urlopen(req,timeoutTIMEOUT,contextSSL_CTX).read()if__name____main__:main()脚本放在 datastore 上/vmfs/volumes/datastore1/那是 VMFS重启不会丢。权限给 700。cron 条目写进/var/spool/cron/crontabs/root* * * * * /bin/python3 /vmfs/volumes/datastore1/scripts/esxi_cputemp.py /dev/null 21六、让配置扛住重启这是 ESXi 特有的麻烦crontab 和/etc/hosts在重启后会被重置。要靠/etc/rc.local.d/local.sh在开机时重建。编辑local.sh在末尾的exit 0之前插入grep-qha.example.com/etc/hosts||echo192.168.1.20 ha.example.com/etc/hostsgrep-qesxi_cputemp /var/spool/cron/crontabs/root||echo* * * * * /bin/python3 /vmfs/volumes/datastore1/scripts/esxi_cputemp.py /dev/null 21/var/spool/cron/crontabs/root改完用sh -n /etc/rc.local.d/local.sh验证语法这是开机脚本写坏了影响启动。不需要重启 crondbusybox 的 crond 每分钟会检查 crontab 文件的 mtime有变化会自动重新加载。还有最后一步容易漏local.sh和/etc/hosts这些改动要写进 bootbank 才算真正持久化。ESXi 自带的 cron 里有一条1 * * * * /sbin/auto-backup.sh每小时会做一次。如果你改完就打算重启 ESXi先手动跑一次/sbin/auto-backup.sh否则改动会丢。七、验证ESXi 侧手动跑一次正常情况下无输出、退出码 0python3 /vmfs/volumes/datastore1/scripts/esxi_cputemp.pyecho$?HA 侧查实体curl-s-HAuthorization: Bearer$SUPERVISOR_TOKEN\http://supervisor/core/api/states/sensor.esxi_cpu_temp返回{entity_id:sensor.esxi_cpu_temp,state:43.0,attributes:{state_class:measurement,tjmax:100,raw_msr:0x88390000,unit_of_measurement:°C,device_class:temperature,friendly_name:ESXi CPU 温度},last_updated:2026-07-30T15:17:00.37648300:00}验收看三点state是合理温度、last_updated在一分钟以内、多查几次raw_msr会变证明是新数据不是缓存。八、这个方案的局限ESXi 宕机时实体会一直保持最后一个温度值不会变成 unavailable。trigger-based template sensor 没有 TTL 机制收不到新数据就一直显示旧值。也就是说如果 ESXi 挂了你在 HA 里看到的还是它挂之前那个温度看起来一切正常。要做数据过期检测得再加一个基于last_updated的 binary_sensor配合一个心跳实体比如time_date集成提供的sensor.time来触发重新计算。我暂时没做先记在这里。小结几个可以直接拿走的结论消费级主板跑 ESXiCPU 温度能读走 MSR风扇转速读不到别在后者上浪费时间。读温度只用 package 的0x1b1单核的0x19c在核心睡眠时会给假值。ESXi 防火墙默认 DROP 出站8123 这类非标端口出不去别去加自定义防火墙 XML重启就没了走现成放行的 443 更省事。nginx 按 SNI 分流所以要用域名 /etc/hosts静态映射不能用 IP 直连。ESXi 上没有 curl 和 base64但有 Python 3.5。crontab 和/etc/hosts重启会丢要靠local.sh重建再靠auto-backup.sh落盘。整套跑下来HA 里就有了一条每分钟更新的温度曲线还能进长期统计看趋势。对于家里放着的这种没有带外管理的机器算是补上了一块比较重要的可观测性。