微秒级和纳秒级，如果一个语言标准库 hash 表才有读 redis 的速度，那这语言太废了，没有 4 个数量级的差距说不定都是你用的有问题

@hero1874 我是在手机上安装了 gps 记录器给 hss 提交经纬度记录，然后 hss 在地图位置那建个位置圈一个半径 3 公里的范围，手机进去这个位置就是到家附近就好了，gps 记录器 5 分钟提交一次并且设置读取位置超时 2 秒也并不耗电，灵敏度也够了

@shaunn #5 其实我就是搞了个 hss 的自定义组件写了算法来依据室内外温度湿度和风速来计算体感温度，然后再通过这个算出来的体感温度通过 hss 的自动化来控制空调，自动化里又添加了时间和是否在家、是否即将到家等其它条件再开关空调且设定不同温度

https://github.com/snower/homeassistant/tree/main/custom_components/apparent_temperature

算体感温度的算法就是这个

sensor:
- platform: apparent_temperature
name: "室内体感温度"
unique_id: "sensor.shi_nei_ti_gan_wen_du"
temperature_sensor: "sensor.v1_cloud_9ad320_temperature"
humidity_sensor: "sensor.v1_cloud_9ad320_humidity"
outdoor_temperature_sensor: "sensor.v1_cloud_bfa384_temperature"
outdoor_humidity_sensor: "sensor.v1_cloud_bfa384_humidity"
indoor_wind_speed: "0.2"
humidity_role_coefficient: "0.2"

- platform: apparent_temperature
name: "室外体感温度"
unique_id: "sensor.shi_wai_ti_gan_wen_du"
weather_sensor: "weather.wo_de_jia"
temperature_sensor: "sensor.v1_cloud_bfa384_temperature"
humidity_sensor: "sensor.v1_cloud_bfa384_humidity"
outdoor_wind_resistance: "0.6"
temperature_convection_coefficient: "0.24"
humidity_role_coefficient: "1.0"

配置文件设置了两个 sensor ，室内体感温度和室外体感温度

参数：
weather_sensor #天气传感器实体 ID
temperature_sensor #室内温度传感器实体 ID
humidity_sensor #室内湿度传感器实体 ID
outdoor_temperature_sensor #室外温度传感器实体 ID
outdoor_humidity_sensor #室外湿度传感器实体 ID
indoor_wind_speed #室内风速
outdoor_wind_resistance #室外风阻系数
humidity_role_coefficient #室内湿度影响系数
temperature_convection_coefficient #温度对流系数
humidity_convection_coefficient #湿度对流系数

本身来说还是看室内外温差、天气对流和辐射因素会体感温度会有明显差距，天气晴朗白天室外 10 度室内 18 度感觉都热了，凌晨室外 10 度室内 18 度估计你都感觉冷死，省电来源看起来是来自体感暖和就很快关闭空调

我就是用空调伴侣，外加米家温湿度计，室内室外各放了一个，然后用 hss 搞了个自定义算法依据室内室外温度、天气情况、是否在家、是否快到家和不同时间段自动开关空调来调节温度和湿度，一般设定晚上健身、睡前和起床前后略微提高温度，舒适度不说重点是按月下来发现比单纯用空调还要省电不少😅😅

那不就是取消桥接模式么，你在说啥，前后矛盾的

https://github.com/python/cpython/blob/main/Python/import.c#L103C12-L103C12 单独加锁了呗，这有啥复杂的，有单独的 import 锁，并且属于整个解释器的，所以并不能并发 import

好像 golang 的 goroutine 调度并不是平衡调度，所以并发很高接口提交速度这么快的话，消费不足肯定导致大量数据拥塞在内存中内存使用量肯定高了，不过你可以试试看其实应该没有一直涨，看你这量不平衡导致内存使用估计得接近 10G 级别了吧，线程的调度平衡性要好的多，但是量特别大也是要考虑线程调度的平衡性影响的

但是换个方向如果你生成业务提交数据不是一直这么高的话，内存充足无所谓的吧，否则如果一直都这么高，或者对内存使用有极度需求，那么你使用 goroutine 提交到 Kafaka 并不能提高你整个系统的吞吐，整体来看对接口延时也帮助不大，整体还是受限于内存大小和 Kafaka 写入速度，异步 goroutine 提交没啥用吧，多余了

就这量维持心肌功能都够呛，还不如快走半小时的吧，身体机能调动需要时间，你这两加起来不超过三分钟的吧，一般来说中等运动强度比如慢跑超过 15 分钟对于普通人应该可以算是基本够用还差不多，但是如果不是特意控制饮食似乎也还是达不到能控制体重的程度

@Haku #17 不可以开端口，难道也不可以开 pipe 么？还有 IPC 通信共享内存什么的吧，也没说一定要使用网络才能搞 RPC ，windows 还有更变态的直接用进程 ID 远程写进程内存然后通过内核信号量通知进程执行远程调用的

便宜的越轻型因为弹性更大，所以噪音相对更大，你看健身房大型的就好很多，不过大多都超 5000 以上了，而且必备隔音地垫了

一种是像瑜伽垫大块的整体垫在跑步机下边，吸收你脚踏的声音，第二种小块的橡胶垫，垫在四角接触地面避免刚性连接直接传递噪音，可以垫个两三层估计更好，前者吸收低频噪音，后者隔绝高频噪音，如果跑步机放阳台估计楼下就不明显了

买过小米的跑步机用了很长时间，不过这货毕竟便宜踏板弹性太大，你几乎难以控制踏板回弹不和你脚下踩不相互冲击，对膝盖脚踝的冲击要比实在水泥地还大，后面膝盖疼的不行，所以还是废弃改室外跑了，真是受不住

厂商的请求数都是后算的吧，而且也只是个统计值，否则近乎实时计算每个对象的请求数这个费用估计都得超过你存储需要的费用了吧，所以没有这功能才是正常的

不会以为这种清理内存的程序不是通过杀进程的话就真的能清理内存吧，内存泄漏还是要程序自己解决的，程序正常改加内存就加内存呗

@sunorg #10 顺便补充一点点，这个写的 SQL 主要方向还是数据导出和数据同步，所以 insert into 并不和数据库的 insert into 一样，其 select 的第一个字段表示主键唯一值，insert into 的时候可以指定选项按这个字段值存在则更新否则插入以保证可重入，毕竟定时脚本统计同步数据不能保证重入简直坑死人，默认则是追加，如果是按天统计结果的也推荐用日期加统计类型来构建一个唯一值更容易保证不出错

https://github.com/snower/syncany-sql

那来推荐下这个项目呗，写 SQL 可以同时查询你需要的这些数据源还可以相互 join ，python 搞的，出发点也就是你现在遇到的这种需求，把统计结果同步到 mysql 之类的，图表用 superset 就很好用了

@fantathat 你这怎么还没转过来，你以为你发个图片消息实际内容是木马对方就直接运行木马了，这么明显的漏洞你是当大家都是傻子么，如果你在两边微信都能装插件你自己就是最牛逼的木马你还发个锤子的木马

如果按上面说的图片漏洞那是不是微信都会中招，你随便打开一个网页就中招了，但微信浏览器这种体量这么大的这种漏洞几乎不存在，否则早被人发现了

无厘头，如果你这能通，那我还有更简单的，我给你回复个自动预览的图片，或者微博什么的发个图片，但其实是个木马程序，那岂不是全部人都要中招了，这和你说的不就是一回事么

也许你需要的是 modbus 转 mqtt

比如这种 https://www.emqx.com/zh/blog/bridging-modbus-data-to-mqtt-for-iiot

慢慢来，身体要适应哪有那么快，慢慢提升距离速度，三月一周期适时调整，你这才开始呼吸适应了才怪，膝盖脚踝受不了了别强撑很容易受伤，差不多坚持跑步一年了才慢慢适应的，现在 6 、7 年了，你这才一个月别那么着急，运动贵在坚持不在于一天蹭蹭就要跑死

公布的驾驶速度不能算公开个人数据吧，个人数据很明显需要反向通过这个数据关联到你，但是公布的驾驶速度相关数据很明显并不符合，所以他们公布的这个信息肯定是不违规的

车联网这事本身不但车企很需要国家也有要求所以已经无可避免了，但也正因如此，社会、政策和法律都会有更严苛的监管和处罚，这对我们普通消费者算是好事了，毕竟都这时代了，按这么说手机只要接入基站，就会 24 小时每分每秒像移动运营商上传你位置等等各种数据了，但不也还是时时刻刻手机不离身了，你觉得手机安全，那么从相同的监管和处罚逻辑来说两者是一样的，无所谓顶多尽量选择正规大厂罢了