Hoje eu gostaria de falar sobre casas inteligentes e dispositivos de IoT. Mas não é um artigo comum. Você não encontrará descrição de hardware, links para fabricantes, lotes de código ou repositórios. Hoje discutiremos algo de nível superior - princípios que são usados para organizar sistemas "inteligentes".
A casa inteligente é um sistema que pode fazer algumas rotinas diárias em vez de uma pessoa. Isso nos leva ao primeiro e ao princípio principal:
1. A casa inteligente deve facilitar a vida.
Casa inteligente é um sistema de vida, não é um brinquedo para geeks. Os sistemas que são mais complicados em uso
1 do que um comutador não são o Smart home.
Qualquer coisa nova deve ser testada contra esse princípio. Se isso não facilitar a vida e você não entender como melhorá-la para facilitar a vida, não é para o Smart home.
O segundo princípio de importância é como um usuário interage com o sistema:
2. A boa experiência do usuário é mais importante que a funcionalidade.
Uma ferramenta interessante e difícil de usar não vale um centavo. Dispositivos convenientes e confiáveis com funções limitadas têm chances muito maiores de sucesso em comparação com dispositivos complicados para todos os usos e aplicativos possíveis.
2.1 Interfaces convenientes são melhores que a personalização.
Se você não entender como combinar inúmeras funções e uma interface simples e simplesmente estocar todas as funções esperando que o usuário possa descobrir tudo sozinho, talvez você deva reconsiderar sua escolha de carreira.
Se você não entender como integrar conveniência e inúmeras funções, livre-se de algumas configurações. Qualquer função é melhor que uma chave comum. Mas se for muito complicado, o usuário voltará a um switch.
O mesmo pode ser dito sobre a qualidade do trabalho. Um botão que simplesmente apaga a luz é melhor do que um dimmer que às vezes funciona e às vezes não funciona:
2.2 A qualidade das funções realizadas é mais importante que o número de funções
É melhor ter poucas funções confiáveis do que inúmeras funções com defeito.
Um dos mecanismos desenvolvidos na mente do homem no curso da evolução é a reação mais emocional a estímulos negativos. Fatores negativos são mais importantes que positivos - é muito mais perigoso não notar um tigre se aproximando do que perder um fruto maduro em uma árvore. Se o seu sistema não possui determinadas funções, não há nada errado. É simplesmente a ausência de um estímulo positivo. Mas se você tem uma função, mas não funciona corretamente, é um estímulo negativo que é facilmente lembrado por um longo tempo.
2.3 O uso do sistema não deve diminuir a velocidade normal de trabalho
Atrasos são inadmissíveis, pois afetam negativamente a experiência do usuário. É um estímulo negativo também. Se uma pessoa não notar nenhum atraso entre o acionamento do interruptor e a luz acesa, ela não deve notá-la no seu sistema.
O hardware moderno funciona em alta velocidade. Não há problema em atingir frequências de dezenas de MHz nos controladores e pelo menos dezenas de kilobits por segundo, mesmo através de um canal de rádio. Se, com esse hardware, o usuário ainda sofrer atrasos no trabalho - reconsidere sua escolha de carreira.
2.4 O sistema não deve quebrar os hábitos de usuário já formados.
Seu sistema é uma pequena parte da vida de uma pessoa. Normalmente, a vida de uma pessoa excede o período de exploração de um sistema. Assim, os sistemas vão e vêm e a vida de uma pessoa continua. E essa vida é cheia de hábitos formados sobre o brilho da luz, mudar de local e a maneira como ele ou ela acha conveniente controlar a luz e o clima.
Os hábitos não podem ser mudanças à força. Coisas novas podem ser oferecidas, mas não forçadas.
Você não pode dizer a um usuário: "Agora você acenderá a luz de um telefone inteligente - é moderno, elegante e legal". Isso vai contra esse princípio e alguns outros também.
O que fazer?
2.5 O sistema deve trazer nova experiência e não substituir a antiga.
Se você acha que sua maneira de controlar sistemas domésticos é melhor que uma antiga, ofereça-a a um usuário. Se for realmente conveniente, ele mesmo escolherá o novo (sim, pessoas diferentes escolhem maneiras diferentes). Tudo o que você pode (e deve) fazer é oferecer a ele uma escolha.
A lógica do trabalho desempenha um papel importante no Smart home. Ele define a regra pela qual o Smart Home trabalha. E isso nos leva ao próximo princípio:
3. A lógica do usuário não pode ser limitada.
Se um usuário quiser ferver uma chaleira
3 quando a temperatura em uma sala aumentar, deixe-o fazer isso. Você também deve evitar uma situação em que uma ação necessária possa ser executada nos níveis de hardware ou software, mas ela não estará disponível apenas porque um desenvolvedor pensou que “Ninguém nunca precisará dela”.
3.1 Quanto mais simples - melhor: criar lógicas não deve exigir conhecimento especial da estrutura do sistema.
Se você possui dispositivos de versões diferentes e com protocolos diferentes, verifique se o usuário sabe disso apenas nos casos em que é realmente necessário e inevitável.
Se você pode poupar a um usuário o problema de obter conhecimento especial, mesmo com o custo do tempo dos desenvolvedores, faça-o. Um desenvolvedor gastará dois dias e demorará mil usuários por hora. Se observarmos 48 horas contra 1000 horas, a resposta é evidente.
Você dorme bem, John, um programador serial?
3.2 Dispositivos com as mesmas funções devem ser controlados da mesma maneira.
Um usuário não precisa saber que uma válvula de água é controlada por certos comandos e uma torneira é controlada por outros. Se os dois controlam a água em um tubo, eles devem ter as mesmas interfaces no nível do usuário: “água aberta”, “água fechada”.
Vivemos no mundo físico. O corpo e o cérebro do homem são formados para interagir com objetos físicos. Isso nos leva ao próximo princípio.
4. O dispositivo de controle físico é melhor que o virtual.
Todos os aplicativos em um telefone inteligente, mesmo os melhores, não são tão bons quanto uma troca física regular em um local necessário.
Outra questão é que um switch precisa estar localizado exatamente no
lugar certo . Isso leva a outra regra:
5. Os sistemas sem fio são melhores que os com fio.
Os sistemas com fio são confiáveis, mas apenas os sistemas sem fio permitem colocar um novo comutador ou um relé sem reformar uma sala. Também permitem mover um interruptor se você achar que um novo local é mais conveniente. Mas há certas exceções:
5.1 Os sistemas sem fio ruins são piores que os com fio.
Para um bom sistema sem fio, não importa a que distância os dispositivos estão do controlador central. Bons sistemas sem fio são protocolos com
rede de malha : ZigBee, Z-Wave, 6LoWPAN, etc.
Todas as outras opções, incluindo Wi-Fi, não são tão boas. Protocolos proprietários como "433 MHz", embora possam funcionar em outras frequências e diferir muito um do outro, também não são tão bons.
As desvantagens do Wi-Fi são que você não pode criar dispositivos "adormecidos" totalmente funcionais, a configuração automática é complicada, a incompatibilidade com outros dispositivos Wi-Fi em casa.
As desvantagens dos protocolos proprietários são que, na maioria dos casos, eles não têm controle de entrega, criptografia e especificações disponíveis. Nem o Wi-Fi nem os protocolos proprietários têm roteamento de malha que resulta na seguinte dificuldade - "Não consigo colocar um comutador nesse canto, pois está muito longe do roteador".
Você não pode criar um sistema 100% confiável que não precise ser mantido. Os dispositivos ficam fora de ordem, há uma sobrecarga na linha de energia, os vizinhos podem inundá-lo, as baterias descarregam, uma criança pode derramar sopa em uma lâmpada, etc. Mas:
6. Fixar, atualizar, manter e diagnosticar deve ser fácil.
Tudo está claro no B2B. Existe um usuário, um desenvolvedor e um operador, é uma pessoa ou organização que sabe como é o sistema e como trabalhar com ele no nível profissional. Um contador não precisa saber de programação para usar seu software profissional. Uma pessoa que aluga um escritório não precisa saber como funciona a ventilação, tudo o que precisa fazer é dizer: "Está abafado no escritório".
Uma solução sábia sobre a compra de um sistema é feita com base no cálculo dos custos totais de propriedade que são compostos pelo preço do sistema e pelas despesas de manutenção.
É um pouco mais complicado em sistemas usados em residências. Um operador e um usuário são a mesma pessoa que não possui o conhecimento necessário do sistema. Infelizmente, esses são os limites do mercado consumidor. E isso leva aos seguintes princípios.
6.1 Os dispositivos funcionam ou não. Não há terceira opção.
Trabalho provável, trabalho parcial ou mau funcionamento são inadmissíveis. Evite situações em que o dispositivo não funcione sempre uma em cada dez vezes. Se você acha que seu dispositivo está com defeito, desligue-o por motivos de segurança e para manter uma experiência positiva do usuário. Substituir um dispositivo não é agradável, mas é melhor fazer com que um usuário substitua um dispositivo do que formar uma opinião de que o sistema funciona “sempre”. Existem apenas dois estados possíveis de um sistema: está fora de ordem ou não funciona, está em ordem e funciona.
Se você tiver certeza de que a degradação do sistema é possível, informe um usuário sobre o assunto com a ajuda de uma mensagem fácil de entender: "O segundo canal dimmer está com defeito. Substitua o dimmer. Continuar usando o primeiro canal dimmer? Sim / não »
6.2 Substituir um dispositivo quebrado deve ser fácil.
O sistema deve ter um módulo. Se um sensor ficar fora de ordem, somente esse sensor deverá ser substituído. Não é correto exigir a substituição de um relé por um controle remoto por um sensor, porque eles estão emparelhados no estágio de fabricação.
Não é correto exigir que "um novo sensor possa ser instalado apenas por nosso especialista", porque é evidente que com o tempo seus especialistas não serão suficientes para atender milhões de usuários à medida que a popularidade do seu sistema aumenta. Assim, em um determinado momento, os problemas aparecerão. É claro que um usuário não conserta um dispositivo, mas quando ele fica fora de ordem, ele deve ter a oportunidade de substituí-lo.
6.3 Mensagens amigáveis.
Se algo der errado, o usuário deve saber e saber o que exatamente deu errado. Você não pode mostrar a mensagem "Erro nº 45", implicando que ele deve entendê-la. Uma mensagem como esta deve ser exibida para um usuário “O dispositivo não responde. Tente recarregá-lo e atribuí-lo novamente ou entre em contato com o suporte técnico. Erro 45
Você não pode aprender que um dispositivo não responde (se você pode fazê-lo) e reter essas informações de um usuário. Não é agradável receber mensagens sobre um problema. Mas é muito mais desagradável saber que um dispositivo está inoperante há uma semana no momento em que você finalmente precisa dele.
6.4 Nenhuma informação extra nas mensagens.
Não envie spam a um usuário com logs. Um usuário precisa de informações como no princípio anterior, porque contém informações sobre o que exatamente deu errado. Se ele não consegue entender as informações ou não é o destinatário, ele não precisa delas.
Não mostre centenas de mensagens típicas "conexão ao dispositivo perdida", "conexão ao dispositivo restaurada". Você precisa decidir se é uma informação crítica e um usuário deve ser informado sobre ela. Ou, se a conexão for restaurada, essas informações não serão importantes; portanto, não as mostre
4 .
6.5 Nenhum conhecimento ou equipamento especial deve ser necessário para os trabalhos de manutenção.
Permita que um usuário atualize o firmware clicando em alguns botões. Isso pode ser feito através de uma interface padrão (USB / BT / Wi-Fi) ou não menciona a atualização via programador SPI.
Você não pode esperar que um usuário calcule máscaras de bits para configurar um dispositivo.
6.6 O sistema não deve exigir manutenção constante.
Se um redutor perder a conexão todos os meses e um usuário precisar subir uma escada para alcançar uma lâmpada e conectar o atuador novamente - não é conveniente. Se as baterias precisarem ser trocadas a cada dois meses - isso não é conveniente. Mesmo que o período médio de manutenção de um dispositivo seja de seis meses - não é conveniente. Se houver cerca de vinte dispositivos em casa, o usuário precisará fazer algo a cada nove dias.
6.7 O sistema deve ter oportunidades para atualizar e estender.
As despesas com a extensão de um sistema devem crescer em progressão linear.
Evite situações em que um usuário que deseja adicionar um sensor precise comprar um novo controlador, porque o antigo não suporta mais de 6 sensores
5 .
Evite situações em que o novo firmware do sensor possa funcionar apenas com uma nova versão de um controlador.
Tais limitações têm uma influência positiva na renda, fazendo com que os usuários comprem novos dispositivos. Mas é um caminho para lugar nenhum. Você pode perder a confiança dos usuários devido a esses truques e, como resultado, perderá muito mais do que poderia ter ganho.
7. Auto-sustentabilidade: redes externas são uma opção, não um requisito.
Um sistema em que os comandos precisam passar por um servidor externo não é conveniente. Você pode falar por horas sobre interfaces convenientes, aplicativos modernos, redes neuro legais, mas elas não significam nada se um usuário não puder acender a luz no banheiro quando a Internet estiver inativa. Você realmente acha que esse sistema pode ser considerado bom?
Eu realmente não entendo por que esse princípio não é um dado adquirido. Se você incluir um servidor externo em um projeto, ele se tornará um possível ponto de falha. Serviços externos são legais, eles podem adicionar mais funções, mas não podem ser a única variante de controle. Embora possam ser maravilhosamente usados como um canal de controle adicional, um armazenamento de backup, uma ferramenta para análise de dados, etc.
8. Centralização: a ausência de um hub central limita as lógicas disponíveis.
Mas um sistema descentralizado também não é o ideal, embora seja confiável.
Um sistema descentralizado é um sistema em que um interruptor "informa" uma lâmpada para "desligar" e um sensor de temperatura liga um aquecedor quando a temperatura está caindo. Um sistema descentralizado perde para um centralizado, porque é bom apenas para a interação simples entre dispositivos quando um dispositivo controla outro dispositivo. Se um sistema se tornar mais complicado, aparecerão muitas perguntas. Se houver vários sensores, o aquecedor aceitará o comando de todos eles? O aquecedor deve solicitar os próprios sensores? Se for necessário tomar uma decisão sobre a análise dos dados reais, onde armazenar o arquivo morto? Onde armazenar e como alterar as lógicas? Como armazenar lógicas em dispositivos "estúpidos"? Como atualizar lógicas?
Todas essas perguntas desaparecem se for dado como certo que um hub é necessário como um ponto de interação de dados e um local para armazenar as lógicas de um usuário. Os dispositivos podem ser "estúpidos", ou seja, podem enviar dados e obter comandos, pois a tarefa de armazenar dados, processar dados, tomar decisões e interagir com serviços externos fica no controlador central.
A descentralização pode ser parcialmente salva, pois quando não há hub, os comandos podem ser enviados diretamente como modo de segurança. Não há lógica, mas a luz pode ser ligada.
9. O sistema não deve realizar ações potencialmente perigosas sem informar um usuário ou obter uma confirmação dele.
Enquanto vivermos em um mundo em que um programador não seja responsável pelos danos causados por seu software, haverá erros no software, incluindo o software do Smart home. A única maneira de não permitir que um erro cause sérias conseqüências é limitar as ações independentes do sistema. Ações potencialmente perigosas devem ser executadas somente quando um usuário é informado sobre elas ou, melhor ainda, após a confirmação. A luz pode ser ligada automaticamente, um erro no software acorda um usuário à noite ou aumenta sua conta de luz. Não é agradável, mas não é perigoso. Mas as torneiras de água não podem ser abertas automaticamente, se não houver ferramentas para impedir inundações. Achei que não era perigoso fechar as torneiras automaticamente.
Isso não significa que o controle automático de aquecedores, caldeiras, lareiras, chaleiras, etc., é proibido. Isso significa que, se você deseja tornar automática uma ação potencialmente perigosa, verifique se o perigo não alcançará o nível do usuário. Certifique-se de que a chaleira seja desligada automaticamente quando atingir uma temperatura definida, se o banho possui sensores de vazamento, etc.
10. Sistema, deve ter opções para autocontrole e autodiagnóstico.
Um desenvolvedor atual de sistemas domésticos inteligentes deve ser um pouco paranóico. Não se pode confiar na Internet, pode estar inoperante. O código não pode ser confiável, pode haver erros. O hardware pode ser confiável? Não, não é possível confiar no hardware. Os relés podem travar, os triatcs podem abrir, os fusíveis podem queimar. Até um usuário pode conectar uma chaleira de kilowatt a uma tomada de 100 watts. Assim, são necessários um sensor de tensão, um sensor de corrente e um sensor de temperatura. Se a temperatura exceder os limites - desligue tudo e envie um aviso. Se a corrente excedeu os limites - desligue tudo. Se um relé estiver desligado, mas ainda houver tensão - envie uma notificação. Se você desligar um relé e não houver tensão - envie uma notificação.
11. O sistema deve ter controle manual.
Mesmo se você considerar todas as coisas paranóicas, haverá uma situação em que todos os controles falharam e algo quebrou. Pode ser um comutador, um roteador ou o hub central, mas, no entanto, um usuário deseja acender a luz no banheiro. O que fazer?
Sempre deve haver um botão que possa fazer o sol se pôr no modo manual, um botão que pode ligar / desligar a luz AGORA. Como levará um dia para entregar um novo hub e um novo interruptor poderá ser comprado mais tarde, mas a luz do quarto deverá ser desligada hoje à noite.
12. Os hackers são tão importantes quanto os usuários comuns.
Usuários regulares trazem dinheiro, hackers
6 pode pensar em novas funções. Uma manufatura não pode e não deve desenvolver todas as cenas de uso do sistema, pois ele não possui conhecimento em todas as esferas e não pode calcular o efeito de tais coisas. É bem possível que um soquete inteligente possa ser conveniente de controlar por meio de um termostato de uma cervejaria móvel, porque possui um regulador PID. O exemplo é um pouco exagerado, mas a idéia é que não é ruim criar condições convenientes para os hackers, pois eles podem adicionar a força móvel ao seu sistema.
13. Abertura: o sistema deve ter uma API aberta para integrar-se com outros sistemas.
Você não pode atender a todas as necessidades de seus clientes com seus próprios dispositivos. Sempre haverá dispositivos que você não possui. Ou você pode ter os dispositivos, mas dispositivos de outros fabricantes podem ser melhores. Para conectar seu sistema a outros, é absolutamente necessário ter uma API aberta e bem documentada. Se você não possui API, seus usuários não podem ter sistemas heterogêneos. Mas mesmo grandes empresas de hardware e software proprietários não podem pagar.
14. Documentação: é tão importante quanto hardware e código.
Não importa o quão legal é o seu hardware ou o quão bom é o seu software, se um usuário não conseguir entender como iniciar o sistema e como trabalhar com ele. Uma boa documentação é aquela após a leitura, na qual um usuário não pensa em entrar em contato com o suporte técnico ou não avalia negativamente as habilidades mentais do desenvolvedor. É impossível escrever essa documentação, mas é algo pelo qual lutar.
E o último, mas não menos importante:
15. Auto-sustentabilidade e auto-suporte: o sistema deve continuar funcionando, mesmo que a empresa não exista mais.
Uma pessoa vive cerca de 70 a 90 anos, um sistema instalado em sua casa funciona cerca de 5 a 10 anos (na melhor das hipóteses), as empresas duram ainda menos. Não crie um sistema que pare de funcionar se a sua empresa morrer. Sinta-se para os usuários. Planeje o sistema de forma que ele possa ser trabalhado com a empresa e o desenvolvedor não estejam mais neste mundo.
Se um dispositivo estiver atribuído com a obtenção de um token do servidor de um desenvolvedor, faça o botão "Ignorar a obtenção de um token". Se o firmware precisar ser atualizado a partir do site quando o sistema for iniciado pela primeira vez, possibilite o download do firmware padrão se o site não estiver disponível. E assim por diante
Neste artigo, tentei descrever a experiência de usar, desenvolver esses sistemas e trabalhar com eles em 15 princípios. Parte deles pode parecer absurda, outros são discutíveis (é normal) e outros são falsos (também é normal).
Mas se você levasse algum tempo para pensar em um deles, o artigo não foi escrito em vão.
Comentários
1. Por "uso", quero dizer o processo de interação regular com o sistema, mas não a configuração.
2. Gostaria de enfatizar que digo "um usuário não deve perceber", mas não "o atraso deve ser o mesmo que". A prática mostra que um ser humano não percebe um atraso de 300 milissegundos.
3. Talvez ele tenha crescido na Ásia e acha que o melhor remédio para o calor é o chá verde quente.
4. Quando digo "não mostrar informações", significa que um usuário não deve receber uma mensagem sobre isso todas as vezes. Ele deve ser mostrado na solicitação de um usuário - por exemplo, "show the log" ou "show debug information" quando um botão é pressionado. Não olhe para os usuários como idiotas, respeite seu tempo.
5. É ou é impossível criar um sistema que suporte um número ilimitado de dispositivos. Sempre haverá limites, mas é tarefa do desenvolvedor torná-los irrelevantes em 99% de todos os casos. O limite para 6 sensores é inaceitável. Cem ou duas centenas de dispositivos em uma rede são suficientes para a maioria dos usuários de residências inteligentes.
6. Uso a palavra "hacker" no significado essencial dessa palavra, de acordo com a RFC1983, e não o significado de uma pessoa que usa computadores para obter acesso não autorizado aos dados.
Este texto foi ajudado a traduzir para o inglês pelo iRidium Mobile , pelo qual eu os agradeço muito.