标签: alexa

相信大家在购买智能家居设备的时候，往往只要在商品介绍中，看到此商品兼容于某某智能家庭生态圈，就会下单购买了。但购买此类商品，对消费者而言往往充满了陷阱及不确定的潜在风险！ 根据市场研究调查的数据来看，目前市占率最高的智慧音箱为支持Alexa智慧家庭生态系，所以有很多的使用者，就会采购兼容于Alexa应用生态系的产品，来建构自己的智慧家庭。 选购智能家庭产品不可不知的事情 当您选购Alexa当作智慧家庭平台时，其构成元素是您在采购时必须要了解的！它是由三大要素所组成： Alexa Built-in Devices(ABI)、 Alexa Connected Device、Alexa Skills 。 这三个要素只要一个环节有问题，消费者就无法享受到Alexa智慧家庭的应用情境。如果厂商们在产品的验证上，没有做好相对应的验证，等产品上市后，就会收到很多的客诉问题！ 如Product 1：产品厂商可能只拿了某一个Alexa的设备进行测试，只要没有问题，就会夸大地宣称说：我的产品兼容于Alexa智能生态系了！毕竟，大多数的厂商碍于时间成本及人力成本压力，很大的概率不会执行全方位的Alexa智慧设备兼容验证。 如Product 2 & 3：有经验的使用者，会在购买前先确认是否有Alexa认证标志WWA(Works With Alexa)，至少有最基本的质量保障。但是就算买了有取得WWA认证的设备产品，依旧还是会面临某些潜在风险，如：产品固件&软件的升级问题、APP使用接口的软件更新等等，导致部分功能失常、甚至是设备无法使用! 在搜寻分析各大电商平台的消费者评论之后，我们发现到最多的用户反馈就是产品与Alexa之间的兼容性问题，居然有蛮大程度上的差别！例如： ● 有消费者反应，购买兼容于Alexa的智能插座，在第一次初始化的设定时就无法透过Alexa APP(Amazon Alexa) 作连接设定，必须要透过另外下载指定APP并以该指定APP操作才能做 ● 但是同一个产品，却有部分消费者回馈是可以透过Alexa APP完成初始化连接设定 这个问题经过百佳泰依据使用者的回馈，分析归纳后发现到有可能是下列的因素所造成： 手机系统OS版本不同 使用的Alexa APP版本不同 产品本身的固件版本或软件版本的不同 连接时的Wi-Fi、Zigbee、蓝牙、Thread等讯号太差或受到干扰 上述的原因，皆有可能会造成，相同产品在不同使用情境下，会发生严重程度不同的兼容性问题，让消费者在使用意见反馈区，留下不好的评价。为了避免产品使用上发生兼容性问题，进而导致客诉问题的产生，全面的测试验证成为了关键。

在智能家居领域中，Matter技术引入带来一系列的创新，为消费者提供更简单、更便利的智能家庭体验。然而，在智能家庭平台的选择上，会因为选购的设备不同，而有不同的使用体验。随着四大智能家庭平台的崛起（Homekit、Google Home、Alexa、SmartThings），如何让一个智能家庭设备在各大平台间游走，让使用者能按照自己习惯使用的平台界面去做选择，成为各家厂商都很注重的问题。而随着Matter的应用，打破了各平台间的隔阂，让使用者可以恣意的选择自己喜爱的智能家庭平台，但一些兼容性问题也随之产生，这也成了Matter应用的大挑战。 本篇使用市面上买得到且支持Matter的WiZ智能灯泡为例，在四间智能家庭平台（Homekit、Google Home、Alexa、SmartThings）上，透过一般使用者日常的使用方式进行实验，藉此找出 透过Matter同时连接不同智能家庭平台的智能灯炮，容易发生哪些问题 ？ 严重问题一. 若从SmartThings智能平台移除该灯泡，再重新透过扫描Matter QR Code或是利用输入Matter序号的方式重新连三星SmartThings，会发生无法连接的问题。 有时因为布置智能家庭设备时，可能一次性够买许多相同的智能设备，例如：本次实验的灯泡第一次与智能平台正常建立连结之后，发现一次性连结太多相同的智能灯泡，但在连结的当下没有好好的命名或是选择正确的所在区域，导致难以辨认出是哪一个灯泡。此时若想透过移除这些灯泡，再重新建立一次与智能家庭的连结，就会导致这个问题的产生，无法再次的透过智能平台连结该灯泡。 但此问题不是100%会发生，笔者发现在每个智能家庭平台透过移除连结再重新建立连结的时候都会发生相同的问题，如SmartThings有80%的发生机率；Homekit有40%的发生机率；Alexa为60%的发生机率，Google home则是40%的发生机率。这问题也可能在更多的场景下发生，像是：消费者在更换或升级设备时，因为他们需要重新配置整个智能平台系统，所以这个问题的存在凸显了Matter协议还需要进一步优化，以确保设备在不同场景下的连结过程更加顺畅。 严重问题二. 遇到在使用Amazon Alexa生态圈触发连结多重生态圈时，Samsung SmartThings无法被正常连结的情况： 这可能是由于不同生态圈之间的通信协议沟通上的问题，导致设备无法正确地进行交互连结。笔者在各种智能平台之间的互连进行实际测试（如下表），仅在利用Alexa平台去多重连结SmartThings平台的状况下才会发生，导致消费者可能需要花更多的时间和精力来解决连接问题，降低了整体的使用体验感受。

开口即遥控? 智能电视应用新型态 智能电视的兴起改变了人们使用电视的方式，其配备的语音助理为用户提供更方便、更智能的电视观看体验。用户可以透过语音与电视互动，例如说「打开Netflix」、「调高音量」、「播放音乐」等等，依照电视机种以及国家地区支持度的不同甚至可以请语音助理协助「比价、购物」、「操控智能家电」、「查询目前电视画面中演员的服装信息」等各式需求。 由于搭载语音助理的智能电视比一般纯语音装置更具备可视化界面的优势，因此Juniper Research预测未来几年内成长幅度最快的语音类别装置将会是智能电视(121.3%) ，其次是智能音箱(41.3%)，再来是穿戴装置(40.2%)。 *注1：使用数量最多的平台依然是智能手机 图片来源：https://www.iphoneincanada.ca/carriers/telus/telus-google-assistant-optik-tv/ 目前主流平面电视系统内建的语音助理主要有『Amazon–Alexa』、『Google–Google Assistant』、『Samsung–Bixby』和『LG–AI ThinQ』…等。(Apple TV Box–Siri因产品别不同暂不在此一同讨论)。为了能让使用者更方便的运用各家语音助理与其生态系统，现在的智能电视也多有支持非原生语音助理的安装，大幅提升消费者在使用上的弹性与便利度。 * 需搭配外部装置进行设定 然而智能电视语音助理的运行也存在一些挑战，除了本身语音识别上的能力以外，还须加上电视正在执行的多样程序，例如：观看电视节目、网络影音串流的播放…等等。因此容易受到电视本身的系统程序管理、语音数据传输能力 、抗干扰能力、麦克风设计或是不同语音助理系统与电视系统间的兼容性问题等因素，可能会严重影响使用者体验。 *注2：现行的智能电视语音控制主要有两种方式，一种是透过遥控器上的语音按钮启动并透过蓝牙传输数据给电视，另一种是免持遥控器便能直接对电视唤醒语音助理的方式又称作Far-field voice control。 使用后真的满意吗? 使用者评价现况调查 拥有30年电视验证经验的百佳泰特别针对主流智能电视语音助理进行用户反馈调查，特别统整常见的抱怨评论。主要问题分布如下： 从上述问题类型来看，终端用户对于电视语音助理的需求不外乎： 稳定、听得懂、回答正确 反应灵敏与互动流畅 我们进一步将上述需求转为量化数据并综合分析: 1.语音助理运行的稳定性和回答正确率 ：以目前语音助理的技术发展以及终端使用者的期望来看，百佳泰建议整体执行正确率应达到95%-97%以上才能满足其需求。 Reference:https://www.gadgets360.com/internet/news/google-voice-recognition-accuracy-machine-learning-mary-meeker-internet-trends-170 2. 反应速度 ：若要让用户在透过 按键唤醒语音助理时能感到灵敏流畅的话，参考”人类感知能力”相关报告，百佳泰建议反应时间应在1秒内，最慢则是建议不超过1.5秒。 Reference: https://medium.com/@slhenty/ui-response-times-acec744f3157 https://www.nngroup.com/articles/response-times-3-important-limits/ 实测方向说明 本次找了各大厂商在2021生产与贩卖的智能电视搭配主流语音助理进行评测比较。 测试手法 由于语音相关测试的难处在于，若透过一般人工方式难以有效率地进行多次数且精准的测量，也难以确保测试条件的一致性，例如: 腔调、音量、角度、距离…等等，更无法提供当下的测试记录以重新检视和分析测试过程中发现的各种问题。 本次实测是运用百佳泰开发的ACSTS测试套件执行测试，此套件可跨平台模拟各种问答情境且并反复进行数百次、上千次的功能验证以及反应时间量测，并将问题透过影片、照片作纪录和回放。 测试环境 使用专业的聆听室，能有效减少不必要的干扰以执行专业的测试和分析。 环境参数与架设 1. 无线环境: 开放式 2. 语音语言: 英语 3. 电视网络: 有线网络 4. 相对位置: 如下图 测试情境 除了专业的测试工具以及环境外，另一个至关重要的是测试情境的设计。 测试规划如下： 语音助理响应速度与稳定度测试 语音助理执行率与正确率测试 – 简单情境 语音助理执行率与正确率测试 – 普通情境

各大Logo更新汇报 | NEW 百佳泰为ISO/IEC17025实验室，亦获得国际协会授权，可提供超过30种标准认证测试，特为您整理12月各大Logo的最新规格信息。 Intel EVO (Project Athena) Audio Test Intel SPET tool version 2.0.297 将在12月发布。 Amazon Alexa A4PC: 2022年12月起AQT 稳定性测试(STT)成为必测项。 USB USB-IF合规研讨会#129 会议时间：2023年2月6日—10日 会议地点：加利福尼亚旧金山机场海湾希尔顿酒店 USB-IF发布了关于USB 2.0 DCR(DC Resistance)的新ECN 近期可能会在一致性测试规范中加入以下测试检查线缆组件的DCR值 通过使用校准的Golden Host执行“false disconnect”测试来检查高速设备的DCR值。 使用经过校准的Golden Host执行“false disconnect”测试, 检查具有高速能力的Captive Device的DCR值。 使用具有本ECN中定义的最大DCR的校准负载，对具有高速能力的Host执行“false disconnect” 和 “false connect” 测试。 现有的电气测试要求 — EL_16也可能在near fixture中更新 Thunderbolt™ 4 现在开始Thunderbolt™ 4 Raptor Lake systems应该使用PD3.1合并的CTS进行测试（而不是PD3.0 CTS）。 PCI Express PCI-SIG 台湾2023开发者大会 会议时间：2023年2月20日-21日 会议地点：台湾台北万豪酒店 PCI-SIG 合规性研讨会#123 会议时间：2023年2月21日-24日 会议地点：台湾台北万豪酒店 Wi-Fi Fragment 和 Forbe 漏洞检测 测试用例 4.2.1, 4.2.2, 5.2.1, 和 5.2.2 现在成为强制性规定（2022年12月1日起）。 Multiple M-BSSID现在对所有的6 GHz STAUTs都是强制性的。

Max has already extolled the apparent virtues of Amazon's Echo appliance, but as I mentioned to him, this thing is a serious threat to luddites everywhere. Yes, if you're already used to saying "Siri..." or "ok google now..", "Alexa" seems like yet another voice-activated assistant. Before I bought mine, I was interested to see that many reviewers felt it was barely worth the $99 intro price at the time. Yes, it offers better than average audio and comes in this nice unobtrusive package that at a glance just looks like an elegant flowerpot (I advise not watering it though), but what does it do?   This thing is nothing less than your own always-on entry point to cloud services. I mean that very literally. Amazon's Alexa AppKit  (currently in beta) provides a set of services that allows developers to create their own apps that leverage Alexa voice services to respond to custom commands with custom actions.   That just sounds like another app, right? In fact, developers can already tie into Android standard system voice  commands for wearables, phones, tablets, and other Android devices. Google is also in limited release with a custom voice  capability so developers can let users "ok google now" into Android apps. Those are still one-way voice activations -- not conversations. And Siri? We're still waiting, Apple. With interesting market timing, Google very recently released its Voice Interaction API , which is the closest thing to Amazon's Alexa AppKit services in offering the capability to let users not just invoke an app or provide basic voice input but also have a conversation with it.   There's a fundamental and very significant difference between Alexa AppKit services and the Voice Interaction API. Amazon wants to make sure developers understand this difference and one of the first things you see on the AppKit pages is the following notice in a large orange box:   Note: Developing apps with the Alexa AppKit is different than developing for other devices such as Android or iOS. Alexa apps are not installed on an actual device. Instead, they are web services hosted in the cloud. When a user wakes an Echo device and makes a request, that request is sent to the Alexa service in the cloud. If the request was intended for your app, the Alexa service sends a request to your app, waits for the response, and delivers the response to the user.   So this device that seems like just an interesting speaker system is essentially a physical extrusion of the cloud into your personal space.   That fact alone makes Echo compelling, but here's why it could help Amazon suddenly become a major player in app services. (Yes, Amazon already has a whole app services capability that includes Amazon Fire Phone, Fire Tablet, and Fire TV, none of which have particularly shaken the market at this point, running behind other market leaders in each category.) Echo is a mass market appliance into Amazon Web Services (AWS), which some time ago moved beyond just a Platform-As-a-Service capability, already offering 10x the computing capacity  of its next 14 competitors combined. More to the point: Even the worst luddite would be comfortable using Echo to interact with a growing array of smart devices.    Echo already allows users to interact by voice with Belkin WeMo and Philips Hue connected home devices, but the Alexa AppKit would allow developers to slap a voice interface onto their own devices and software applications. The Alexa Service provides a voice-interaction-in-a-box capability, sending parsed user intent to your application and translating your application's response to voice output on the Echo. Like an old-fashioned telephone, Echo itself doesn't do much here -- it "just" connects the user to the cloud rather than the POTS network. (When we someday talk about the plain old cloud service, could somebody please first come up with an expression that yields a nicer sounder acronym?)   Alexa Service flow overview (Courtesy of Amazon)   The Alexa Service can work with any web service and the Alexa AppKit provides a Java library for convenience. The part I find particularly interesting is that rather than building your own web service with all the required bells and whistles, you can also just use an AWS service called Lambda. Lambda is AWS's foray into event-driven service. Unlike its flagship Elastic Compute Cloud (EC2) virtual servers, Lambda instantiates an instance on receipt of an event and maintains the instance only as long as required for it to respond to that event. AWS wasn't the first to offer this type of service, and Lambda is a relatively new entry. When Lambda first previewed, I thought it was an interesting service but fairly specialized in its utility. Now I see that it's the underpinnings of Echo/Alexa. Lambda supports Java and nodejs, the two programming languages currently supported in the Alexa AppKit, and it's easy to imagine the Alexa strategic plan had a lot to do with Lambda's appearance.    Within the Alexa AppKit application service, you define your app by providing a URL or ARN (Amazon Resource Name), pointing to your own hosted web service or AWS Lambda function, respectively. In addition, you provide a JSON-formatted "schema" that describes the "user intent" for the conversation and a description of sample utterances. The terms for "intent" provided in the schema correspond to entry points and variables within the web service specified by your URL or ARN. The details of all this are way beyond the scope of this little post but it will all look familiar to developers.   Alexa AppKit and the Service in general are tied deeply into the AWS world in the way the Service authorizes users to interact with Alexa apps and the way Alexa apps are allowed to interact with other resource endpoints. Within the AWS world, all this becomes particularly easy of course. I've been using AWS for many years so I'm familiar with Lambda and the AWS model and getting the Alexa AppKit version of "hello world" up with Lambda was very quick. It's kind of cool chatting with my much smarter Lambda self through Echo.    This is by no means a toy, however. The low-hanging fruit with this service is providing a voice interface to other popular event-driven application services such as IFTTT (there's already an IFTTT Alexa channel ) and the myriad vendor-specific and third-party services out there. Beyond that, you know Echo interfaces are going to pop up for Arduino, Raspberry Pi, Beaglebone, Neopixels, and other connected hardware out there. The interesting thing will be if this becomes a voice hub for home automation and beyond that, if it literally becomes a voice of the IoT.    Stephen Evanczuk