智能锁的外观设计公司真正专,业的还是少，都跑遍了深圳，广州。目前只有锐科吉讯工业产品设计公司还是很好的。智能锁设计的很好。
有关智能家居电子设计的有什么好建议啊？
最最主要的就是智能节能灯光方面，还有安防方面，像这些的具体设计就得考虑你家的户型图啊，灯光回路图啊等等，也可以融入背景音乐，场景控制，家电节能控制，你可以参考下世界级控制功能最全和稳定性最高外观工艺最闪的BTICINO法国罗格朗公司的最新系列奥特，专为智能家居设计，功能强大，集成度高，稳定性强，适合中国电力啊无线啊等领域的指标！
智能体温计设计
智能体温计用于精确测量人体温度，并可将所测数据通过点阵式LCD屏记录与显示，以确定人体在某个阶段的体温曲线。
一．任务：设计并制作数字式智能体温计
二．要求：
⒈ 基本要求:
⑴ 系统前端部分归一化输出，即0 ～＋50 ℃线性对应0 ～ 5 V；
⑵ 系统前端部分应具有输出保护电路，使其输出电压不超过5V；
⑶ 系统每秒采集一次温度，经滤波、计算等处理后实时显示温度值，测量精度为±0.1℃；
⑷ 系统每分钟用语音报告一次所测温度当前值；
⑸ 系统可在0～50℃的范围内任意设预警温度值（默认值设定为37.0℃），当所测温度超过预警温度值时，系统立即报警，预警值的设定应可随时更改。
调试方法——以水温代替人的体温，用一根水银温度计与所制作的体温计探头（捆绑）同时接触被测热水的同一点。被测热水存放于一只容器中，另备一只热水壶与一只冰水壶（保温壶内放适量冰块），以便用添加热水或添加冷水的方法随时改变被测水温。
智能硬件产品的软件设计
我一直相信努力会有回报，一直在公司推的扩展器APP项目终于做起来了。目前UI，UE已经完成，软件开发和APP开发的接口也对好了，就等排期进行开发了。我觉得自己的运气也是极好的，本来一个APP项目是很难立起来的，这期间经历的挫折和打击也不少，还好搭着costdown项目的顺风车一起做了起来。本文主要讲讲整个硬件产品的软件设计中自己的经验，虽然以扩展器为例，但是这些点适用很多智能硬件产品的软件设计了。
既然APP都要做了，则索性将PC端和H5端都进行了一次迭代，由于接手过来的时候PC端和H5端产品都已经做了一个初版，但是都没有相关的文档，所以自己全部重新整理了一遍PC端，H5端的文档。当写一个新的产品或者功能的prd的时候，我是可以根据自己的逻辑和思路一气呵成的，但是这个我需要在同一个文档里既整理出现有产品的内容还得加入新的想法进行改进。这就要求我得先对已有的功能逻辑完全了解，然后思考这个逻辑是否合理，有没有更好的方案。更奇葩的是，有些逻辑我觉得是混乱的，在询问之前团队时，他们居然说当时有些异常情况没有遇到，没有去做相关的测试，所以没有梳理相关逻辑。因为项目的推动不容易，主要是因为开发资源比较紧张，在和开发商量的时候答应过开发，PC端和H5端的升级会尽量减少开发的工作量。因此在梳理文档的时候，只是整理现有逻辑，修改不合理的逻辑，梳理之前团队没有想的逻辑，新功能一个都没有添加。关于PC端和H5端这块，我只想给出以下建议：
遇到中途接手的项目，并且没有相关文档可以参考的时候，三点建议：
第一：一定是需要把已有的逻辑了解透彻，记录下逻辑还有优化的点以及逻辑混乱的点，自己先梳理一遍之后再去和现有的开发团队对一下有没有什么问题；
第二，考虑到开发也是根据现有的程序做修改，在文档中把有改动的点一定要做标记，清楚描述现有逻辑是怎样的，修改后是怎样的，这样方便程序员查看；
第三，除了有些逻辑进行了相关改动，为了更好的用户体验，交互方面也做了些改动。坑爹的是，翻看公司之前的UE和UI资料，发现做出来的产品和资料对不上，这可苦了UE和我了。我给UE把整个产品操作流程录了下来方便她对着现有做出来的查看，然后把要修改的地方在文档中标记出来，拜托她对着标记的地方做相应的修改。最后我再把她做出来的UE图仔仔细细对好几遍，有不对的地方得记录下来拜托她再修改，这还得来回好几次。
虽然过程繁琐了点，但是比推项目的时候开心多了。而且这样一来，我相当于把一个硬件产品所需要的软件设计全部做了一遍。虽然说扩展器的功能比较简单，但是能把架构和细节都过一遍，也学到了不少东西。毕竟之前做路由APP的时候全部做的是功能点，没有一个整体的概念。
这部分主要是根据自己做扩展器APP的经验，介绍一下在设计智能硬件产品APP的时候需要注意的部分重点。智能硬件产品APP不同于纯互联网APP，它的设计需要考虑的端比较多，每一个逻辑都需要考虑到所有的端的情况，不同端之间会相互影响，不同的网络情况又会对不同的端造成不同的影响。所以那个情况多呀，异常多呀，有些功能稍微复杂点的写出来的prd快赶上一个APP了。今天呢，不谈这些细节，细节还是放在具体的功能设计里面去说比较合适，今天只说在新做一个硬件产品APP时需要考虑的切入点。
一般来说，对硬件产品APP而言，重要的有如下模块：
接入，首配，工具
对于一个刚起步的硬件产品APP来说，其中最重要的是 接入 和 首配， 只有简易快速的配置连接硬件，才谈的上控制硬件，即工具和APP的其他功能设计。
接入主要考虑的是APP如何识别出硬件产品，识别是不是自己公司的产品（只有自家的产品才能进行通信控制）以及是自家公司的哪个产品（不同的产品，其首配，工具等等很多功能都是不一样的）。由于公司的硬件产品比较多，最好的是能够将相同性质的硬件产品集成在同一个APP里面，这样既方便产品的开发，用户体验也会更加友好。扩展器同路由器一样同属网络产品，再加上扩展器本身就需要搭配路由器使用，因此我所负责的扩展器APP是直接集成到现有的路由APP里。识别是否为自家公司的产品好做，一般待配置产品的SSID（网络名称）都是带有自家公司的名称的，根据SSID就可以直接判断了。那如何识别这是一台路由器还是一个扩展器呢？连接上设备的网络后，路由器是有IP地址的，APP可直接通过访问IP发送消息来确认是路由器。但是扩展器只有在扩展成功后才会有分配的IP，而且还是变化的，因此不能使用和路由器一样的方法进行识别。产品处于待配置状态时会广播一些字段，其中就有MAC地址，原以为可以通过对Mac地址进行管控，直接将一段Mac地址对应一类产品，这样就可以直接通过Mac地址进行识别产品类型。然而首先我们公司并没有做Mac地址的管控，其次APP通过广播接收的Mac地址信息会有一定的不准确性，因此这种方法不可行。但是广播出来的字段又没有其他有用信息可利用了，所以又回到了SSID上，我们决定给SSID加上后缀名，表征它是一个扩展器。因用户在首配和无线设置中是可以修改SSID的，为了始终能够识别（除了首配的时候需要进行识别，在用APP切换设备管理的时候也需要对连接设备进行识别），后缀名不能让用户改动，这个我们在交互层面上做了一定的设计，而在理解上，则参考Word之类的文档名称一样，只能修改名称，不能修改后缀名。从SSID上进行识别只是一个初步识别，在初步识别后还会通过尝试通信让扩展器发送一个产品类型的字段进行确认。
这样整个识别接入的逻辑才算完整，开发做起来相对简单，用户体验也没有太大影响。
不同的产品的首配流程是不一样的，这里只谈一些共识点。首配需要首先检测是否首配过，检测方法在了解后略微有点low。主要是根据WiFi名称是否被更改过以及是否有设置密码来判断。当然，若恰好某台配置过的路由器既没有修改WiFi名称还没有设置密码，那不好意思，我们判断不了，可能需要重新配置一次了。整个首配流程在设计的时候一定要简单并且防呆工作做好，不然一步错导致步步错就会带来极差的用户体验，而首配的失败会让用户对整个品牌和产品的好感度消失。无论是在路由配置还是扩展器配置中，首配基本上都是“一气呵成”的，也就是把所有的设置项都选好后记录下来，中间没有任何生效的点，只有最后一步才会将所有的设置生效。而有一点不一样，就是管理员密码的设置是直接生效的。在体验产品的时候会发现，在保存管理员密码后不进行接下来的配置，退出后再次进入则需要输入管理员密码；而且输入后不能进入首页（也就是不能），而是进入继续配置的页面。为什么要提到这些，因为有两个方向的考虑点，一是管理员密码有没有必要和接下来的配置分离开，二是用户就是不想配置连网就想使用工具控制设备的场景怎么处理。PC端现在做的还是分离和不能进入，而APP不同的是，用户在输入管理员密码后可以跳过配置，直接进入首页，因为考虑到APP是有与硬件不相关的功能（比如社区）和账户体系（比如我）。分离是为了设备管理的安全性着想；不能进入考虑的是大部分场景：没有扩展连网，设备的意义不大，所以还是尽量引导用户去配置完成。
以上几点是首配中比较容易混乱的大的逻辑点，其他的步骤是根据不同设备的连网需求而有所不同的，这个里面的细节也是非常的多，本文就不做过多的描述了。
不得不说，文章排版有点.......（不过内容可是真真切切的的实战干货）我实在不想把时间花在排版上，因为还有好多东西要学，好多内容要尽快输出。此时的我已经换了个部门，现在已经不是硬件产品经理了，目前是一名社区产品经理。所以很多东西要尽快学习熟悉起来，不然要被人怼死。以后输出的和硬件相关的产品设计文章可能不多了，社区产品相关的文章请拭目以待。
