iOS 低功耗蓝牙4.0开发指南。

1什么是蓝牙40，蓝牙其它标准又是什么？

详细描述：低功耗蓝牙(Low Energy; LE)，又视为Bluetooth Smart或蓝牙核心规格40版本。其特点具备节能、便于采用，是蓝牙技术专为物联网(Internet of Things; IOT)开发的技术版本。所以它最主要的特点是低功耗，普及率高。现在所说的蓝牙设备，大部分都是在说40设备，ble也特指40设备。 在40之前重要的版本有 21版本-基本速率／增强数据率(BR/EDR) 和 30 高速蓝牙 版本，这些统称为经典蓝牙。40还有41和42的小版本，其中42版本对传输速率做了进一步他提升，提高了25倍，苹果从iphone6开始使用42，最新的蓝牙标准为蓝牙50，其中最大的特点连接范围扩大了4倍，速度又提高了2倍，无连接数据广播能力提高了8倍，增加了蓝牙组网的能力。

2蓝牙开发必须知道的概念。

211 central和peripheral：
蓝牙应用开发中，存在两种角色，分别是central和peripheral(pə’rɪfərəl) ,中文就是中心和外设。比如手机去连接智能设备，那手机就是central，智能设备就是peripheral。大多时候都是central去连接peripheral的场景。
212 广播和连接:
peripheral会发出广播,central扫描到广播后，可以对设备进行连接，发出connect请求，peripheral接收到请求后，同意连接后，central和peripheral就建立了连接。
213 连接后的 *** 作:

write，read，notify，indecate， response or not …
indecate和notify的区别就在于，indecate是一定会收到数据，notify有可能会丢失数据（不会有central收到数据的回应），write也分为response和noresponse，如果是response，那么write成功回收到peripheral的确认消息，但是会降低写入的速率。
214 协议:

每个具体的智能设备，都约定了一组数据格式，这个就是数据协议，例如手环中获取到数据0X001023，其中第2位到第5位表示步数，那么就2310就是步数的16进制的数据，转换成10进制就是8976步，需要注意的是，设备端都是小端模式，所以取4位时候，高字节在前低字节在后。
3 iOS蓝牙应用的一般开发流程。
4 蓝牙的数据交互。

write，read，notify，indecate， response or not … 都是容易理解的，indecate和notify对应的是长连接，建立indecate后，peripheral可以随时往central发送数据。
indecate和notify的区别就在于，indecate是一定会收到数据，notify有可能会丢失数据（不会有central收到数据的回应），write也分为response和noresponse，如果是response，那么write成功回收到peripheral的确认消息，但是会降低写入的速率。
对于一个charateristic，他的读写订阅的权限是peripheral决定的，熟悉可以被同时设置，一般会根据外设的功能来决定。
5蓝牙ota DFU。

蓝牙ota,DFU（Device Firmware Update）指的是蓝牙设备的固件升级，其实是一整套流程，不同的蓝牙芯片，ota的流程有不同之处，我这里用ti的芯片举例。步骤为：切系统(bootloader mode)，重启，传输数据，验证数据，切系统，重启，完成。
其中数据传输也会分成很多节去发送，没法送一段数据，做一次数据校验。

6ota存在的问题。

每个智能设备的速率，功耗，存储都会有很多限制，导致很多设备会自己去实现ota的功能，自定义流程和数据传输方式，导致许多设备都是有自己私有的ota模式和协议，所以在做开发的时候，要仔细阅读设备协议中对ota的描述。
7如何做自动重连。

只需要在设备断开连接的委托方法中，重新调用gattconnet或者是centralManagerconnet方法就可以了，无论当时设备是否有点，是否在周围，当设备再次开会或者连接到可连接范围内，都会自动被连上。
8连接失败处理。

分两个平台来说，iOS端也有连接失败的委托，但是好像几乎不会发生这种情况，而对于同款设备，android常常会出现连接失败的情况，status != BluetoothGattGATT_SUCCESS，android端开发请不要把连接失败和断开连接放在一块处理，因为断开连接可以直接尝试重新连接，而连接失败后尝试重新连接，需要加一些延时，并且需要gattclose，清空一下状态，否则会把gatt阻塞导致手机不重启蓝牙就再也无法连接任何设备的情况 。
9后台运行。

iOS后来运行，需要设备中infoPlist权限，key:Required background modes ,value: bluetooth-central(手机作为central) , bluetooth-peripheral。
10同时连接多个设备。

使用同一个CBCentralManager，通过进入委托的peripheral的identifier区分不同的设备，进行不同的 *** 作和处理。
11扫描广播包。

所有外设，只有在发出广播包的情况下，才能被central发现，绝大多数情况下，外设被连接后就不会发出广播（也有例外），很多人遇到无法找到设备的问题，大多属于这种情况。
12提高蓝牙连接速度。

无论是iOS，还是android，都可以通过已绑定的设备，在不开启扫描的情况下进行快速连接，iOS需要的参数是peripheral的identifier，android需要mac地址。但android和iOS还是有一些区别的，比如iOS不能拿到已绑定的设备list，但是可以通过UUID去拿到peripheral的实例。而android可以拿到已绑定的设备list。android绑定过程需要手动调用createBond的方法，而iOS在连接成功一次后会自动绑定。 android在处理createBond时，常常会应为不同手机平台，不同设备，会产生兼容性的问题，这点需要注意。
13定向扫描。

在扫描时候可以传入serviceUUID，这样可以扫描到特定条件的设备，提高扫描的速度，排除干扰。
14如何获取mac地址。

而iOS出于苹果的安全策略问题，无法直接获得mac地址，只能得到一个mac地址换算出来的identifier。

大数据远距离，用4G网络

网络布局上，远距离的网络直接连基站，无需自己布设网络节点。而近距离的网络都需要有一个网络节点，先把终端数据传给节点，节点再接入广域网。远距离传输比近距离传输的价格更贵、功耗更高，合理利用远近搭配，能够有效降低物联网终端的成本。

例如原本的共享单车采用2G网络解锁，必须要保持数据长连接或使用下行短信开锁，功耗高费用大，而下载的共享单车抛弃了远程解锁，直接使用手机的蓝牙解锁单车，节省了数据流量、降低了功耗、还能提高开锁速度；盈能量电动自行车智能充电站也是物联网高科技产品，运用最新窄带通讯技术，引领电动自行车充电设备的技术高度。

云服务的设计物联网的云服务器和APP的设计，和互联网基本是一致的，JAVA、PHP、ASP都可以用来做物联网的后台处理。移动互联网是“人－－服务器－－人”的架构，物联网是“物－－服务器－－人”的架构，两者本质是相同的，物联网终端设备也采用TCP、>

使用场景分散化，技术集中化物联网的使用场景，总结下来很一致：采集＋传输＋计算＋展,物联网终端采集数据、把数据传输给服务器、服务器存储和处理数据、把数据展示给用户。

IOT网关，接收sensor数据的总入口，主要是日志，安全防护，流控，协议转换等功能，

图1 IOT网关

之前有提到IOT网关是基于python的twisted框架实现的，初期的时候该IOT网关主要实现的功能是 数据接收和转换功能 和 安全防护 。

数据接收和转换功能 ，这里很简单，拟定好数据交互格式后，IOT网关按照约定好的格式进行解析，然后转发给后端服务进行进一步的处理

安全防护 ，设备的区分主要是依靠烧录到硬件的SN号来实现，SN号包含的信息比较多，如生产批次，设备型号等，受制于厂商我安全防护不能做的非常完善，同时sensor与IOT网关的交互不能非常复杂。安全防护这一块理论上是设备接入要一型一密或者一机一密，协议上还应该启用tls/ssl安全通信协议。

图2 鉴权

安全防护要做ssl这类的安全通信协议的话，要考虑设备厂商实现通信模块能力，设备功耗，设备性能（低端设备cpu性能可能比较差，可考虑对称加密形式），IOT网关也需要引入相应模块。

另外认证从性能方面考虑，后期在设备比较多的情况下，可以加入redis等内存型key-value数据库，缓存设备信息，提高鉴权模块性能。

实践中，我们的sensor基本都是依靠电池供电，因此我们的IOT网关基本是面向短链接（后期我们有监测设备，依靠外部电源直接供电，为长连接），因此在每次发起连接我们都要进行一次鉴权，鉴权通过后，设备方可上传传感器监测数据和设备自身状态。

图3 数据交互流程

这一块的调试工作长达半年左右，才基本稳定下来，主要集中在设备商处除了硬件稳定性，还有在调试中发现传输的字符串乱码（c语言处理问题），沾包（厂商开发人员tcp协议不熟），优化传输效率，关闭cork或者 Nagle 算法（传输包很小）。

因为IOT网关不能主动断连接，理论 *** 作中，IOT网关应该和sensor有心跳协议，保证连接的有效性。设备商在数据流程交互完成后，竟然没有close 连接，直接休眠，导致网关所在服务器的连接的文件描述符一直没有正常释放，后面为了预防这种现象，我开启了 *** 作系统层面的keepalve定时器，回收失效连接（系统默认时间是2小时左右，我缩短了失效时间），理论上来说应该是应用层面去实现心跳协议。

整个IOT网关的设计，是无状态，可伸缩的，单网关在普通型ecs上可轻松达到数百tps。

使用rt thread系统里的EC200驱动包+web client做一个物联网项目，之前开发的时候一直都是用的EC600S模块，看起来挺好的，没什么大问题，后来量产的时候不小心买了EC600N焊上去了，之前也听厂家的技术支持说应该是完全一样的，可是就掉进了这个坑里。
故障现象：
模块的net_status和net_mode灯的状态不太对，模块开机后的最终状态有时候net_mode常亮，net_status灭掉，或者net_status一直在慢闪，net_mode一直熄灭。甚至有时候我的应用可以先从服务器拿一包数据，然后又挂掉再也连不上了。
分析：
上述这两种状态都不在文档描述中，打at client去看，你发什么它都是直接回显，比如发AT+CPIN它就直接回，而不是回OK或者错误,所以初步判断是模块进入了一个错误的状态。那么能让模块进入错误状态无非就是以下几种情况：
睡眠或者开机、重启的姿势不对
或者在模块初始化之前我的应用代码把它搞死了。但是之前用EC600S开发都是好的，而且一般应用代码不太能把模块搞到错误状态，这种可能性比较低。
排查：
针对第二种情况，排查很简单，先把应用软件去掉看看。故障依旧，所以继续排查1
在EC200的驱动包里要配置开机引脚，状态引脚，睡眠引脚。无论是开发什么东西，一般睡眠这种状态是最容易出问题的，包括x86开发，usb设备开发，屡见不鲜，所以首先把睡眠去掉了（-1），但是故障依旧。
刚开始我始终没有怀疑状态引脚，因为它是个输入，只是判断一下模块有没有开机，感觉不会有什么问题，所以绕来绕去一直没有去动它。直到看到了有个哥们遇到了类似的问题：
RT-Thread-at_device 没有使用power pin 导致的网络异常 bugRT-Thread问答社区 - RT-Thread
这个问题其实我之前用EC600S的时候好像也遇到了，但是我并不用ping，应用也没有问题，所以也没去管他。不过这倒提醒了可以去试试，于是把开机状态也改成-1，居然就好了。
 
电源引脚我没去动它，模块是需要有一个开机时序的，我看它的初始化代码里也有去动电源引脚重新开机之类的。
希望其他掉在坑里的小伙伴可以看到我这篇帖子，少走点弯路。
打开CSDN，阅读体验更佳
Quectel_EC600S系列_TCP(IP)_应用指导_V12rar
EC600S-CN 模块内置 TCP/IP 协议栈， Host 可以 直接通过 AT 命令访问网络； 这大大降低模块对 PPP 和外部 TCP/IP 协议栈的依赖性，从而降低终端设计 的成本。
EC600N（二）--核心板初次点亮
系列文章目录 EC600N（一）–基本信息介绍 EC600N（二）–核心板初次点亮 目录系列文章目录前言一、使用前说明1供电方式2 模块开机状态二、AT指令测试1测试准备2AT指令测试 前言 本次实验使用移远EC600N双排核心板，主要使用AT指令测试模块，测试模块的USB口和33V串口。 一、使用前说明 1供电方式 EC600N模块需要用排针的VIN进行供电，供电如下图所示： USB口供电可能达不到模块的开机要求(由于串联了二极管，有压降)，一般采用针脚对模块供电。这个设计有点鸡肋。 2
继续访问

移远4G模组EC600N进行TCP/IP连接和服务器测试
最近公司产品需要增加一个4G模块进行数据传输，想到之前做的移远的4G模块，于是买了一个核心板回来调试。 协议选择TCP/IP，因此使用的是TCP/IP部分的AT指令手册。工具方面，使用串口调试助手，关于测试服务器，一开始用的安信可的透传云，但是服务器连接一段时间不发送消息就会自动断开，所以还是使用了网络调试助手。因为网络调试助手使用的是本地网络，如果需要和4G通信，还需要使用花生壳做内网穿透。 接下来先把服务器部分做好。 如果没有花生壳软件，建议先去官网下载一个 长这样色的。安装后打开界面如下 这个界
继续访问

STM32F405+4G模块OTA固件升级调试记录
STM32F405+4G模块OTA固件升级调试个人记录
继续访问

Cat1模块使用总结（EC600N）
由于Cat4模块（EC20）功耗大，考虑到NB网络覆盖问题（设备在野外工作场景），因此项目上用选择了Cat1（EC600N）模块，现在把调试过程总结下，希望能够帮助到大家。EC20使用总结请看：单片机和4G模块通信总结（EC20）。 一、电源 手册说供电电压≥34V，峰值电流3A。 二、通信口 UART和IO口都是18V，需要做电平准换。 三、开机顺序 我是上电1s后复位，复位低电平600ms，然后100ms后开机，开机等待10s后进行 *** 作。 四、AT指令 采用消息地体原理，具体请看
继续访问

日志组件
日志组件 1 日志是什么 日志是软件应用必备的组件，是程序debug，或是数据收集管理的重要依据，方便我们监测生产环境的变量值变化以及代码运行轨迹。本课程主要用来学习实际开发中常用的日志组件。 主要是为了方便我们监测生产环境的变量值变化以及代码运行轨迹等。 这些记录会被输出到我们指定的位置形成文件,帮助我们分析错误以及用户请求轨迹。 2 常用日志组件 21 Log4j与log4j2x ​ Log4j有8种不同的log级别，按照等级从低到高依次为：ALL>TRACE>DEBUG&gt
继续访问
ESP32+移远EC600N模组通过MQTT连接阿里云并通过>

  MQTT 协议 是基于发布/订阅模式的物联网通信协议，凭借简单易实现、支持 QoS、报文小等特点，占据了物联网协议的半壁江山。
  常用于 IOT 物联网和一些需要服务端主动通知客户端的场景。

1 导入依赖

2 创建 MqttHelper 辅助类，设置回调监听

3 连接 MQTT

  连接成功或失败，以及中途的连接掉线，会触发 OnMqttStatusChangeListener 回调

4 MQTT 连接状态监听

5 MQTT 收发消息监听

  onSubMessage 订阅的消息回调，因为存在订阅多个 topic 的情况，所以回调能知道是来自哪个 Topic 的消息；
  onPubMessage 发布的消息回调，用于确认发布的消息是否发送成功。

6 MQTT 订阅 Topic

  需要在 MQTT 连接成功后才能订阅 topic，否则订阅 Topic 不成功，收不到对应消息

7 MQTT 取消订阅 Topic

8 MQTT 发布消息

9 MQTT 断开连接

10 通知设置
  由于 MQTT 启动了一个 Service，而 Android 80 以上对于后台 Service 限制时长 5 秒；所以将 MqttService 绑定到 Notification 上成为了一个前台通知；通知的标题和内容显示可以在 stringsxml 中设置，对应属性如下：

  Android 80 及以上开启前台服务绑定到通知，80 以下默认不启用，可将 mqtt_foreground_notification_low_26 设为 true，将 80 以下设备也开启前台通知服务

  创建 MQTT 实例时需要传送参数 MqttOptions,下面将介绍下部分参数;

1 Topic
  MQTT 是一种发布/订阅的消息协议, 通过设定的主题 Topic,
发布者向 Topic 发送的 payload 负载消息会经过服务器, 转发到所有订阅
该 Topic 的订阅者
   通配符 : 假想移动端消息推送场景,有的系统消息是全体用户接收,有的消息是 Android 或 iOS 设备接收, 又或者是某些消息具体推送到用户,当然, 对应的多种类型消息可以通过多订阅几个对应的 Topic 解决,也可以使用通配符;
  通配符有两个, " + " 和 " # ", 与正斜杠 " / " 组合使用;加号只能表示一级Topic, 井号可以表示任意层级 Topic; 例如: 订阅 Topic为 " System/+ ", 发布者发布的 Topic 可以是 System、System/Android、System/iOS; 但是不能是 System/iOS/123, 而订阅的 Topic 如果是" System/# " 则可以收到;
   注意,只有订阅的 Topic 才可以使用 通配符, 发布和遗嘱的 Topic 不能包含通配符

2 ClientID
  发布者和订阅者都是属于客户端, 客户端与服务端建立连接之后,发送的第一个报文消息必须是 Connect 消息,而 Connect 的消息载荷中必须包含 clientID 客户端唯一标识;
  如果两个客户端的 clientID 一样, 则服务端记录第一个客户端连接之后再收到第二个客户端连接请求,则会向一个客户端发送 Disconnect 报文断开连接, 并连接第二个客户端, 而如果此时设置了自动重连, 第一个客户端再次连接,服务端又断开与第二个的连接, 连上第一个客户端, 如此将导致两个客户端不断的被挤掉重连
  注意: clientID 使用的字符最好是 大小写字母和数字, 长度最好限制在[1, 23] 之间;

3 遗嘱消息
  可选参数, 客户端没有主动向服务端发起 disconnect 断开连接消息,然而服务端检测到和客户端之间的连接已断开, 此时服务端将该客户端设置的遗嘱消息发送出去
  应用场景: 客户端因网络等情况掉线之后, 可以及时通知到所有订阅该遗嘱 Topic 的客户端;
  遗嘱 Topic 中不能存在通配符

4 Session
  客户端和服务端之间建立的会话状态, 一般用于消息保存, 如果设置清除 Session,则每次客户端和服务端建立连接会创建一个新的会话,之前连接中的消息不能恢复,
  而设置不清除会话, 对应发布者发送的 qos 为 1和2 的消息,还未被订阅者接收确认,则需要保存在会话中, 以便订阅者下次连接可以恢复这些消息;
  注意: Session 存储的消息是保存在内容中的, 所以如果不是重要的消息,最好是设置清除 Session, 或者设置 qos = 0;

5 心跳包
  标识客户端传输一次控制报文到下一次传输之间允许的空闲时间；在这段时间内，如果客户端没有其他任何报文发送，必须发送一个 PINGREQ 报文到服务器，而如果服务端在 15 倍心跳时间内没有收到客户端消息，则会主动断开客户端的连接，发送其遗嘱消息给所有订阅者。而服务端收到 PINGREQ 报文之后，立即返回 PINGRESP 报文给客户端
  心跳时间单位为秒，占用2个字节，最大 2^16 - 1 = 65535秒（18小时12分钟15秒）,设置为 0 表示不使用心跳机制； 心跳时间一般设置为几分钟或几十秒即可，时间短点可以更快的发出遗嘱消息通知掉线，但是时间短会增加消息频率，影响服务端并发； 微信长连接为 300 秒，而三大运营商貌似也有个连接时间最小的为 5 分钟。

6 qos
  服务质量等级 qos 对应两部分,一是客户端到服务端发送的消息, 一是服务端到客户端订阅的消息; 从发布者到订阅者实际 qos 为两段路中 qos 最小的。
  qos 可选值 0(最多交付一次)、1(最少交付一次)、2(正好交付一次);
   qos = 0 ：接收方不发送响应，发送方不进行重试；发送方只管发一次，不管是否发成功，也不管接收方是否成功接收，适用于不重要的数据传输；
   qos = 1 ：确保消息至少有一次到达接收方，发送方向接收方发送消息，需要等待接收方返回应答消息，如果发送方在一定时间之内没有收到应答，发送方继续下一次消息发送，直到收到应答消息，删除本地消息缓存，不再发送；所以接收方可能收到1-n次消息；适用于需要收到所有消息，客户端可以处理重复消息。
   qos = 2 ：确保消息只一次到达接收方，发送方和接收方之间消息处理流程最复杂；
   Mqtt Qos 深度解读 和 MQTT协议QoS2 准确一次送达的实现

7 payload 负载消息
  字节流类型, 是 MQTT 通信传输的真实数据

8 保留消息
  发布消息时设置, 对应参数 retain, 服务端将保留对应 Topic 最新的一条消息记录; 保留消息的作用是每次客户端连接上线都会收到其 Topic 的最后一条保留消息, 所以可能存在网络不稳定,频繁掉线重连,每次重连重复收到保留消息;
   可以向对应的 Topic 发送一条 空消息,用于清除保留消息。

MQTT 服务搭建 Apache Apollo 服务器 搭建 MQTT 服务
Github 仓库
mqtt 协议

eSIM指的是eSIM卡，即Embedded-SIM，嵌入式SIM卡。

eSIM卡将传统SIM卡直接嵌入到设备芯片上，而不是作为独立的可移除零部件加入设备中，用户无需插入物理SIM卡，用户可以更加灵活的选择运营商套餐，或者在无需解锁设备、购买新设备的前提下随时更换运营商。

由于不再需要为设备设置一个独立的SIM卡槽，采用eSIM设计的设备将拥有更轻、更薄的机身，同时eSIM能够显著降低运营商的SIM卡采购成本、码号资源管理成本。

扩展资料

eSIM应用领域

eSIM卡在物联网领域有着极为广泛的应用。eSIM卡轻薄小巧、无需换卡和空中写卡的特性十分符合物联网连接的需求。据某研究机构预计，2022年eSIM卡市场规模将达到440亿元，而数码、车联网和公共设施将是2020年eSIM卡的三大主要应用方向。

除运营商外，互联网巨头和手机厂商同样在eSIM卡上发力，包括小米、联想等多家企业已在自家的笔记本产品上集成了eSIM功能。有观点认为，随着eSIM卡的普及，运营商、手机企业、互联网巨头之间对该领域的竞争会更加激烈。

参考资料来源：百度百科-eSIM卡

参考资料来源：新华网-三大运营商纷纷开展eSIM试点

1Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。
2MQTT协议是应用层协议不依赖长连接，适合弱网络。通过topic缓存信息。符合物联网设备的使用场景。因为通过topic缓存信息，因此可以实现通过topic与多个端的一对多连接，而不是设备与设备的多对多连接，节省了能耗及带宽。
MQTT的心跳，及非信息的报文，较Websocket更少，更节省带宽及能耗。更适用于物理网的多种网络协议。
3WebSocket和>