我彻底弃用MQTT了，不是因为MQTT不好，而是环节越少越好！

ghostist

ryanh7 发表于 2022-4-15 12:22
然而，我要用新插件把它接到ha，用ha的ffmpeg解码可以支持更多格式。至于增益，我那是没办法才用软件处理 ...

是的 我搞了功放板 准备加进去试一下
ffmpeg是可以解决上述问题，但我只想要一个简单的TTS  12块的盒子刚好满足

没注意到原来你就是那个模块esphome的作者呀 嘿嘿

BlueFang

看个人需求吧，mqtt是一种广泛使用的协议。

打个比方，未来有一天，想迁移到别的平台，mqtt很容易就会有对应的接口或插件支持。

远的不说，每次HA的stable版本变更，论坛就会一阵鸡飞狗跳，“升级到xx版本xx插件失效怎么办？”“升级到xx版本后xx功能不正常怎么处理？“

mqtt并不是没有以上的顾虑，而是因为它是广泛使用的协议，HA开发组会更慎重的处理与之有关的开发兼容，就算出问题，也会有人第一时间给出解决方案。

neroxps

囧 发表于 2022-4-15 10:48
MQTT还是有他的优势的 包括出错重连等底层逻辑都帮写好了，CURL失败之后就完啦 ...

囧大所言甚是。
MQTT  对比 Restful API 的话，主要是有心跳机制，还有遗言机制。另支持记录最后状态等，这些特性套到 Restful API 上得自己加工了。

XCray

囧 发表于 2022-4-15 10:48
MQTT还是有他的优势的 包括出错重连等底层逻辑都帮写好了，CURL失败之后就完啦 ...

这个优势在我的环境中完全发挥不出来

原来跑的mqttl项目，用我签名贴里的esp32+esphome替代了，esphome原生api，直接以传感器的形式发布到ha，底层的东西更不用操心，比起mqtt协议也更有优势。

剩下的用到curl的这个应用，简单的不能再简单了，并且是路由器和ha主机间通信，只要ha没有崩溃，也就不会失败了。通信问题更是不存在——如果局域网内的ha主机和路由器之间通信都不可靠，那简直就没法玩了

当然，mqtt协议本身还是非常优秀的、优势也是很巨大的，只不过也有其适用场景。

我弃用mqtt一是用不到了，二来减少了一个单点故障的机会，三是简化了维护

ekingfan

我不太理解，你说的是直接的MQTT??   tasmota , z2m这些都是基于MQTT的。。只不过是本地的，，，，你指的是 internet 中的MQTT吧？

XCray

ekingfan 发表于 2022-4-16 09:50
我不太理解，你说的是直接的MQTT??   tasmota , z2m这些都是基于MQTT的。。只不过是本地的，，，，你指的是 ...

就是本地的mqtt，tasmota、z2m这些我都没用，internet中的mqtt更没用过

involute

赞老大，我一开始就没用过MQTT，感觉这玩意不是必须的。

hang1993

我也用restful api，真是太好用了。不过我觉得它和mqtt是两个层面的东西，不存在替代关系，该用mqtt的我还用，不过目前看来场景是比较少，需要用mqtt的都被esphome集成了，然而restful api是万能的

huang7dede

我还是用mqtt,,主要是我没安装HA，esphome的API对接的HA，，在node-red里我都不知道怎么调用，，所以编译esphome时我都是注释了API那条目。

sophia

彻底弃用MQTT，很难做到万物互联。