1,582
社区成员




近日爱智迎来重大更新,EdgerOS 1.7.8 正式发布。此次发布升级了 Wi-Fi 管理程序,无线连接更顺畅,更多细节可见下方。
做为初代产品设计的精灵一号在发布之初并没有采用国外高通、博通等大厂的现成无线方案。秉承着翼辉信息坚持自研的理念,精灵一号的 Wi-Fi 驱动也是基于芯片厂家的开源驱动结合 SylixOS 自行适配研发的。然而不论是爱智团队内部使用的效果,还是社区反馈,精灵一号的无线网使用起来总感觉“不够稳”。
做过无线网的同学都知道,从数字电路的 0、1 逻辑变换到模拟信号的过程本身就是非常复杂的,这中间不仅仅需要深厚的编程功底,还需要丰富的信号优化经验。经过无数次的调试优化,精灵一号的信号强度终于满格,然而即使是满格,使用起来还是不够“顺畅”。
经过了大半年的不断尝试,翼辉网络大神“时雨月一”直接使用 SylixOS 网络协议栈完成包排序,编译、部署、测试,Wi-Fi 网络的速率和稳定性均得到了明显的提升!
程序员的快乐就是这么简单……
本次更新加入了 http.fetch API。什么是 http.fetch,对开发者而言又能够提供哪些便利呢?让我们先来看看 MDN 官方网站的介绍:
Fetch 提供了对
Request
和Response
(以及其他与网络请求有关的)对象的通用定义。使之今后可以被使用到更多地应用场景中:无论是 service worker、Cache API、又或者是其他处理请求和响应的方式,甚至是任何一种需要你自己在程序中生成响应的方式。它同时还为有关联性的概念,例如 CORS 和 HTTP 原生头信息,提供一种新的定义,取代它们原来那种分离的定义。
英文原文如下:
Fetch provides a generic definition of
Request
andResponse
objects (and other things involved with network requests). This will allow them to be used wherever they are needed in the future, whether it's for service workers, Cache API, and other similar things that handle or modify requests and responses, or any kind of use case that might require you to generate your responses programmatically (that is, the use of computer program or personal programming instructions).It also defines related concepts such as CORS and the HTTP Origin header semantics, supplanting their separate definitions elsewhere.
在 EdgerOS JSRE 中,http.fetch
是对 Fetch API 的实现。它要求必须传入一个 URL 参数,无论请求成功与否,都会返回一个 Promise 对象,resolve 为对应请求的 Response 。
我们可以像下面这样很方便地发送一个 http 请求:
const http = require('http')
http.fetch(`http://127.0.0.1:3000/ping`)
.then(res => res.text())
.then((text => {
console.log(text)
})
http.fetch 还提供了第二个可选参数用以配置请求,包括以下选项:
method:HTTP 请求方法,默认是:GET。
timeout:设置请求超时的等待时间,如果超时,HttpClient 将会关闭。
headers:设置请求头。需要注意这里的请求头关键字需要是小写,大写会被转换成小写。
redirect:处理请求重定向的方式,可以是 'follow' 表示跟随后端的重定向,'error' 表示阻止并抛出异常信息,'manual' 则表示阻止重定向,默认值为 'follow'。
body:当请求方法为 POST 等时,可以将数据放到 body 中传递。注意,当请求方法为 GET 时,body 并不会被发送。
tlsOpt:TLS 安全连接选项。默认为 undefined
。
http.fetch 对请求返回的 Promise 对象做了解析,我们可以根据不同的业务需求来处理不同的返回数据,主要有下面几种方法:
res.buffer(),处理返回的 Buffer 数据。
res.text(),处理返回的字符串数据,当返回的是 JSON 数据时,使用 res.text() 返回需要在 then 中手动解析成 JSON 对象。
res.json(),处理返回的 JSON 数据。注意,用 res.json() 返回字符串数据时会抛出解析错误。
res.pipeTo(writeStream),将返回的数据写入到可写流中。
下边是一个流式处理的例子:
// 发送流
http.fetch('http://192.168.128.1:3000/upload', {
method: "POST",
body: require('fs').createReadStream('./test.jpg')
}).then((res) => {
if (res.statusCode === 200) {
console.log('Upload success.');
} else {
throw new Error('Upload fail:' +res.statusCode);
}
})
// 接收流
http.fetch('http://192.168.128.1:3000/download', {
method: "GET"
}).then((res) => {
const wStream = require('fs').createWriteStream('./test.mp4');
return res.pipeTo(wStream);
})
.then(() => console.log('Load file success.'))
是不是非常的方便呢?
本次更新改进了 SDDC 设备连接管理的相关时序问题。此项改进的需求来自爱智社区中鼎鼎大名的灵感桌面同学。他曾经给我们反馈过一个问题,就是他使用 Arduino 开发的一些 SDDC 设备经常会掉线。SDDC 协议是基于 UDP 协议开发的,在 SDDC 设备与 Spirit 1 通信的时候,大部分场景下收发数据都默认不需要对端回复确认信息,减少网络损耗和提高实时性。同时 SDDC 也支持可靠传输和消息重传,如下图 API 所示,当参数 req 设定为 true 时,系统将等待来自远程设备的回复。当远程设备未回复时,系统将自动重新发送此消息,直到远程设备响应或超时。
EdgerOS 就是在此基础上维持设备的在线状态,系统在与设备没有通信的情况下,每隔一定时间就会主动发送一个需要设备回复的数据,用来确认设备的实际状态。尽管如此,在无线网络不稳定或者设备 Wi-Fi 信号差的情况下,往往会出现丢包的情况,假如出现丢包导致系统没有收到设备的确认信息,会出现系统误认为此设备已经离线。本次更新优化设备断连的相关逻辑,在同样的时间间隔内,Ping 包的发送次数增加,直到没有任何的回复,才认为此设备已经离线。
SDDC 协议和代码均已开源,智能设备侧的适配工作十分简单。前不久就有 Wi-Fi 智能插座厂家成功适配了 EdgerOS 的 SDDC 协议。同时,厂家了还提出了新的需求,就是希望 SDDC 协议在接入设备的时候发送一个时间戳,方便设备同步时间。这是因为智能设备一旦断电就会丢失自己的状态信息,而要保存时间信息就需要数据存储和电池供电,这些无疑都会提高设备的总体复杂度和制造成本。
综合考虑后,爱智团队觉得这是一个非常好的建议:连接设备时为无状态设备同步时间,可以极大地方便智能设备的设计开发,进一步降低生产成本;改进本身也没有影响 SDDC 协议原有的行为,仅仅在 Invite 消息中增加 JSON 字段即可完成:
{ "timestamp": { "utc": <当前的UTC时间毫秒数>, "tz": <UTC时间与本地时间之差> } }
utc
字段的值相当于 JavaScript 中直接调用 Date.now(),
而 tz
字段就是本地时间的时区信息了,相当于 EdgerOS 系统 API 的 sys.getTz() * 1000
。需要设备开发者注意的是,为了与 JavaScript 中的时间戳的单位保持一致,两个字段的数值单位都是毫秒。
从此,使用 SDDC 的智能设备就不再需要保存时间了,越来越简单方便啦!
目前 EdgerOS 1.7.8 已正式发布,爱智用户可前往升级,欢迎广大开发者朋友体验。
参考链接: