mqtt

Good way to design mqtt topic?

你离开我真会死。 提交于 2020-08-24 15:49:56
问题 I am very new with mqtt design. As I see from some tutorials in the internet, common mqtt topic has this format: /home/room/device_type/device_id I could not see the benefit to do that. And have no idea how to use this kind of design. From my point of view, the device (dev) might subscribe (sub) to control topic and publish (pub) to status topic. Like this: pub: clients/dev/devid/stat sub: clients/dev/devid/ctrl In this way, it seems sub,pub logic is very simple for both clients and devices

Good way to design mqtt topic?

心不动则不痛 提交于 2020-08-24 15:44:52
问题 I am very new with mqtt design. As I see from some tutorials in the internet, common mqtt topic has this format: /home/room/device_type/device_id I could not see the benefit to do that. And have no idea how to use this kind of design. From my point of view, the device (dev) might subscribe (sub) to control topic and publish (pub) to status topic. Like this: pub: clients/dev/devid/stat sub: clients/dev/devid/ctrl In this way, it seems sub,pub logic is very simple for both clients and devices

Good way to design mqtt topic?

安稳与你 提交于 2020-08-24 15:44:15
问题 I am very new with mqtt design. As I see from some tutorials in the internet, common mqtt topic has this format: /home/room/device_type/device_id I could not see the benefit to do that. And have no idea how to use this kind of design. From my point of view, the device (dev) might subscribe (sub) to control topic and publish (pub) to status topic. Like this: pub: clients/dev/devid/stat sub: clients/dev/devid/ctrl In this way, it seems sub,pub logic is very simple for both clients and devices

RPC style request with MQTT

我只是一个虾纸丫 提交于 2020-08-23 09:46:27
问题 what is the best way to implement RPC style communication (synchronous request/response) with MQTT? Or would it even make sense to put another interface (e.g. REST api) into use? Thanks in advance! 回答1: MQTT is a PUB/SUB system and doesn't lend itself well to RPC. While you could possibly shoehorn something on top of MQTT to simulate the synchronicity required, you are probably better off looking for a system which provides real RPC semantics. That said, depending on your application, you can

Kuiper 正式成为 EdgeX 规则引擎

女生的网名这么多〃 提交于 2020-08-20 05:11:14
概览 在 EdgeX Geneva 版本中, EMQ X Kuiper - 基于 SQL 的轻量级流式数据处理软件 与 EdgeX 进行了集成。在进入这篇教程之前,让我们先花一些时间来了解一些 Kuiper 的基本知识。EMQ X Kuiper 是 Golang 实现的轻量级物联网边缘分析、流式处理开源软件,可以运行在各类资源受限的边缘设备上。Kuiper 基于 源 (Source) , SQL (业务逻辑处理) , 目标 (Sink) 的方式来支持流式数据处理。 源(Source):流式数据的数据源,例如来自于 MQTT 服务器 的数据。在 EdgeX 的场景下,数据源就是 EdgeX 消息总线(EdgeX message bus),可以是来自于 ZeroMQ 或者 MQTT 服务器; SQL:SQL 是你流式数据处理指定业务逻辑的地方,Kuiper 提供了 SQL 语句可以对数据进行抽取、过滤和转换; 目标(Sink):目标用于将分析结果发送到特定的目标。例如,将分析结果发送到另外的 MQTT 服务器,或者一个 HTTP Rest 地址; 使用 Kuiper,一般需要完成以下三个步骤。 创建流,就是你定义数据源的地方 写规则 为数据分析写 SQL 指定一个保存分析结果的目标 部署,并且运行规则 该教程描述如何使用 Kuiper 处理来自于 EdgeX 消息总线的数据。

工业采集网关需要具备哪些功能

老子叫甜甜 提交于 2020-08-19 23:12:13
在工控、自动化、监测等工业应用当中,各种设备、仪器、传感器的通信模式都有所不同,物联网和工业系统之间需要工业采集网关来做承上启下的作用,将不同协议的下位机反馈给上位机,它的基本功能是协议转换,汇总所有数据,转换传感器的协议,并在发送数据之前对其进行预处理。 一般来说,工业采集网关需要具备以下功能: 1、具备对下位机设备的协议解析功能,如modbus、can、opc等协议,实现现场设备数据采集。 2、需要具备常用的采集接口,如RS485、RS232、网口等,方便现场设备广泛接入。 3、具备对云端的协议对接功能,如常用的MQTT、212等协议,可与私有云、公有云匹配对接。 4、数据转发需要具备通信功能,如有线、无线、WiFi、4G、5G等通信方式。 5、需要具备边缘计算功能,保障数据安全与分担云端负荷。 BMG700工业采集网关采用ARM架构,具有强劲的边缘计算能力,可提供二次开发应用,具有丰富的采集接口,兼容多种协议,支持5G、4G、有线等多种通信方式,是工业设备数据采集的上上之选,工业级设计,契合工业现场使用。 来源: oschina 链接: https://my.oschina.net/u/4587008/blog/4478379

029. RabbitMQ 消息可靠性和插件机制

时间秒杀一切 提交于 2020-08-19 17:38:30
1. 消息可靠性 RabbitMQ 的消息可靠性,一般是业务系统接入消息中间件时首要考虑的问题,一般通过三个方面保障: 发送可靠性:确保消息成功发送到 Broker。 存储可靠性:Broker 对消息持久化,确保消息不会丢失。 消费可靠性:确保消息成功被消费。 1. 发送可靠性 一般消息发送可靠性分为 3 个层级: At most once:最多一次,消息可能会丢失,但绝不会重复传输。 At least once:最少一次,消息绝不会丢失,但可能会重复传输。 Exactly once:恰好一次,每条消息肯定会被传输一次且仅传输一次。 RabbitMQ 支持其中的“最多一次”和“最少一次”。 其中“最少一次”投递实现需要考虑以下这几个方面的内容: 消息生产者需要开启事务机制或者 publisher confirm 机制,以确保消息可以可靠地传输到 RabbitMQ 中。 消息生产者需要配合使用 mandatory 参数或者备份交换器来确保消息能够从交换器路由到队列中,进而能够保存下来而不被丢弃。 “最多一次”的方式无需考虑以上那些方面,生产者随意发送,不过这样很难确保消息会成功发送。 2. 消费可靠性 消费者在消费消息的同时,需要将 autoAck 设置为 false,然后通过手动确认的方式去确认已经正确消费的消息,以免在消费端引起不必要的消息丢失。 3. 代码示例 // 可靠生产

识人、识货、识场—— 这就是智能零售该有的样子

邮差的信 提交于 2020-08-19 13:39:29
过去的20年,“网购”逐渐改变了人们的消费习惯,颠覆了商业的交互方式,也倒逼着实体零售在线下往更精细的“服务”和“运营”方向杀出一条生存之道。在这条路上,互联网、物联网、人工智能、AR等技术都在积蓄着能量,试图打造一个 智能化的新零售商业模式 。 智能的零售,该是什么样子? 它应当为每一位到店的消费者,量身定制专属的个性化服务; 它应当在我们拿起一款商品时,推送商品详情、价格、评价、优惠券等信息,给予消费者犹如线上购物一样的体验; 它应该能够感知我们的消费习惯,预测消费趋势,引导商家的生产和供货; 它也应当能实时记录客流在店铺内的行动路线,在货架前的每一次停留,与商品的每一次互动,帮助商家改善店内陈设及商品的摆放策略,提高销售转化率; 这些,或许就是智能零售该有的样子—— 重塑人们的购物体验,帮助线下门店实现智能化、可视化管理、拉新引流、降本增效 。 面向零售全场景的智能物联中台 在智能零售时代,技术会越来越成为门店的核心竞争力之一,驱动门店不断升级。随着零售行业数字化不断深入,新设备和新应用大量涌现,但它们之间往往较为独立,彼此的系统比较割裂。而数据难以打通、设备难以集中管理、应用价值难以更好挖掘等难题,直接导致了门店部署复杂,消费者体验提升有限等难题。 物联网的出现有望改变这一难题。物联网技术与门店基础设施相结合,从采购商品到维护仓库再到销售商品,均可为客户提供更好的体验

MQTT Client paho.mqtt.python使用简介

╄→гoц情女王★ 提交于 2020-08-18 12:55:28
简介 MQTT协议目前可能是物联网最为流行的传输协议,那么如何使用Python作为客户端,和MQTT服务器端进行交互? 本文将以paho.mqtt.python ( https://github.com/eclipse/paho.mqtt.python )作为客户端,EMQ为MQTT Broker来介绍paho与EMQ之间交互。 安装MQTT Broker: EMQ EMQ是目前开源社区最为流行的MQTT Broker,之前EMQ君的博客上已经对如何在不同的操作系统安装,本文不再赘述。 在Ubuntu上安装EMQ,请 点击这里 ;在Windows上安装EMQ,请 点击这里 。 准备paho.mqtt.python Python安装请参考这三篇文章: Linux系统python安装 ; Windows系统Python安装 ; Mac系统Python安装 。 EMQ君建议Python版本为python3.6(paho建议版本为2.7+和3.2+) 解压paho.mqtt.python-master.zip 打开命令行窗口,切换到解压后paho目录,安装paho python setup.py install Windows安装完成后paho文件在Python\Lib\site-packages\paho_mqtt-1.3.1-py3.6.egg\paho\mqtt目录。

EMQ X 速率限制(Rate Limit)配置指南

拜拜、爱过 提交于 2020-08-18 05:34:31
在阅读该指南之前,假定你已经了解 MQTT 与 EMQ X MQTT 服务器 的简单知识。 EMQ X Broker 从 V3 版本开始支持速率限制功能,包括了对 PUBLISH 报文接收速率 与 TCP 数据包接收速率 的限制,本文将详细介绍该功能的配置与使用。 配置项 MQTT PUBLISH 报文接收速率 该配置位于 emqx.conf : zone.external.publish_limit = 10,1m 配置格式为: <Number>,<Duration> ,表示在 <Duration> 时间段内,最多允许接收 <Number> 数量的 PUBLISH 报文。 TCP 数据包接收速率 该配置位于 emqx.conf : listener.tcp.external.rate_limit = 1024,4096 配置格式为: <Rate>,<Burst> ,它表示允许的数据包接收的平均速率为 <Rate> 。但它允许的的最大峰值由 <Burst> 值决定。详细的内容见下节: 速率限制算法令牌桶 — 算法 active_n 该配置位于 emqx.conf : listener.tcp.external.active_n = 100 active_n 实际上表示的是:在底层的异步 I/O 中允许读取的数据报条数,每当异步的读操作到达该限制时,便暂时的切换为同步模式