You are currently browsing the archives for the Em curso category


Subredes numa ligação da NOS

Há muito tempo que tinha previsto separar a rede de casa em várias subredes. A proliferação de equipamentos, e certamente as boas práticas em termos de segurança, sugerem que não se misturem telemóveis, IOTs, computadores, e outros equipamentos. A rede era uma coisa muito controlada por mim, e por isso nada de WiFi para visitas, e coisas do género, o que me merecia algumas críticas…

Este fim de semana meti mãos à obra. Com os conhecimentos que tinha, devia ser uma coisa simples. Munido de um router simpático, comecei a configurar tudo, com várias redes internas separadas. A meio da coisa, resolvi começar a ligar à Internet, para começar a testar. Fui aí que descobri que o router da NOS não suporta este tipo de ideias…

Percorri vários foruns, e a ideia estabelecida é a de que tal não é possível. A única forma é a de utilizar o router da NOS em modo bridge e utilizar outro router para substituir o da NOS. A partir daí, fica limitado apenas às capacidades desse router. Por várias razões, não queria ir por aí, pelo que continuei a insistir, até descobrir uma solução (quase perfeita).

A solução passa por utilizar a funcionalidade de subrede nas “Definições” de “Rede Local” do router da NOS. Não consegui encontrar documentação detalhada desta funcionalidade, mas a verdade é que não procurei quase nada. Parece ser que o router cria uma sub-interface com o IP definido em “Gateway de sub-rede”, com a correspondente “Máscara de Sub-Rede”:

Subredes no router NOS

Tal possibilita que o router passe a saber que existe uma subrede adicional à da rede principal do router NOS. Note-se que o router NOS não suporta o conceito da rota estática (“static route”), pelo que a opção que eu acabei por fazer foi englobar toda a restante rede interna dentro da subrede 192.168.1.0/24, subdividindo-a posteriormente no meu router em várias subredes separadas. Admito, porque não testei, que se possam adicionar subredes adicionais no router NOS.

A configuração anterior não faz com que uma configuração tradicional funcione. Não existindo o conceito de rota estática, o router NOS pensa que os dispositivos da rede 192.168.1.0/24 estão directamente acessíveis. O router NOS não sabe, nem se lhe consegue dizer, qual é o endereço IP do nosso router interno! Por isso, quando tenta contactar com um dispositivo da rede 192.168.1.0/24, tem que enviar um pedido ARP para resolução do correspondente endereço MAC.

E é aqui que esta solução que encontrei deixa de ser óptima. Para que funcione, o nosso router tem que suportar algo chamado “Proxy ARP”: fazer-se passar pelos endereços IP da rede 192.168.1.0/24. Aí, o router NOS pensa que encontrou o endereço MAC do endereço IP com o qual está a tentar comunicar, mandando assim o pacote para o nosso router. Este, depois de receber o pacote, já sabe o que fazer…

Esta é uma solução um pouco rebuscada, e que terá alguns problemas de segurança. Dependerá sobretudo da forma exacta com que o nosso router implemente o “Proxy ARP”, algo que continuarei a investigar de seguida.

Consumo de electricidade de um sistema AQS

O consumo de electricidade de um sistema de AQS (Água Quente Solar), com circulação forçada, habitualmente é tido como sendo negligente. A verdade é que não será, porque tem um pequeno motor eléctrico, que faz circular o fluido entre os paineis e o acumulador interior (cilindro), e que permite efetivamente aquecer a água. Nunca tive a oportunidade de monitorizar um, mas tal possibilidade surgiu recentemente.

Serão várias as variáveis que contribuirão para uma variação do consumo. No Verão, o consumo será menor, porque os paineis aquecem mais rapidamente, e logo o motor funcionará durante menos tempo. O mesmo variará possivelmente em função das nuvens que se atravessem no céu. No Inverno, poderá nem sequer chegar a consumir, se a temperatura do painel não for suficiente para aquecer a água no cilindro. Quanto maior for o consumo de água quente, maior será a quantidade de água a aquecer, e logo mais tempo funcionará o motor. A distância entre os paineis e o cilindro também terá o seu impacto, dado que para maiores distâncias, maiores serão as perdas térmicas no circuito, e logo maior será o tempo durante o qual o motor funcionará. E estas são apenas as que me lembro.

Nas duas experiências seguintes, o sistema AQS envolve dois paineis no telhado, sendo o sistema com circulação forçado ligado a um cilindro de aproximadamente 300 litros. A configuração por defeito faz com que o sistema aqueça a água do cilindro até 60ºC. Em ambos os casos, a monitorização do consumo de electricidade foi efetuada recorrendo-se a um dispositivo EOT. O gráfico é efetuado apenas pouco depois das 10 horas, dado verificar-se um consumo grande antes desse período, o que distorce o gráfico. Depois de terminado o aquecimento, verifica-se que o consumo restante da cas está ligeiramente acima dos 30Wh.

No primeiro caso, verificamos o comportamento sem nenhum consumo de água quente. Durante a noite verificam-se perdas de calor no cilindro, pelo que na manhã seguinte, e logo que a incidência de raios solares permita o aquecimento dos paineis, o sistema volta a tentar colocar a temperatura do cilindro nos 60ºC. Verificamos que se verificam intervalos de consumo com uma potência associada de cerca de 10 a 15 W, um consumo extremamente baixo. A evolução é intervalada com períodos sem consumo, períodos esses que vão sendo mais curtos à medida que a manhã avança. Tal comportamento explica-se, em minha opinião, pelo funcionamento dos painéis: quando o Sol está mais baixo, o aquecimento dos painéis é mais lento, pelo que demora mais tempo a atingir a temperatura a partir da qual se começa a transferir o calor dos painéis para o depósito, e que neste caso está definido em +5ºC. Por volta das 12:30, os painéis conseguiram que a temperatura da água do cilindro voltasse aos 60ºC:

Consumo sistema solar sem actividade

No segundo caso, verificamos o consumo adicional resultante dum duche, em que a temperatura de água, medida no topo do cilindro, resultou numa descida da temperatura da água de 60º para 55º, ao final da tarde anterior. Note-se que o comportamento do consumo, visível abaixo, não é muito distante daquele que foi observado no gráfico acima. Os intervalos de consumo são mais próximos, pelo menos numa fase inicial da manhã. Note-se que antes das 10 da manhã se verificaram provavelmente mais consumos, até porque partindo de uma temperatura inferior da água no depósito, a energia do Sol que incide nos painéis pode começar a aquecer essa mesma água mais cedo. Na verdade, atinge valores de consumo mais elevados, mas por outro lado consegue chegar aos 60ºC mais cedo.

Consumo sistema solar depois de um chuveiro

Como é claro pelos dados, esta primeira experiência não dissipa todas as dúvidas que tinha. Mas há uma que fica obviamente definida, que é a dos sistemas de AQS com circuito fechado consumirem alguma electricidade, mesmo quando não se verifica consumo de água quente. Felizmente, como se pode ver, mesmo quando há consumo de água quente, o consumo de electricidade é muito baixo. Estimo que nestes casos esteja próximo de 5 Wh, média por cada uma das três horas. Tal significa um consumo de cerca de 15 Wh por dia, só para repor a temperatura. Tal significa um consumo de cerca de 450 Wh durante um mês, o que corresponde a cerca de dez cêntimos de euro de electricidade por mês… Quanto ao acréscimo para repor a temperatura resultante do duche, o consumo, pelas minhas contas, é ainda menor, e dentro de um intervalo que considero susceptível de erro. Terei que tentar melhorar a precisão, para chegar a uma conclusão mais acertada…

Nota: O artigo foi alterado para correção de um erro: onde antes se lia 150Wh, passou a estar 450 Wh, bem como se corrigiu o correspondente valor financeiro.

Usar uma Trust Mini Webcam WB-1200p como camera do Raspberry Pi

Trust WB 1200P webcam

Trust WB 1200P webcam

A Trus Mini WebCam era uma câmera portátil vendida há muito, muito tempo. Dava para capturar uns incríveis e espetaculares 352 x 288 pixeis.

Hoje há câmeras com muito mais capacidades que esta pequena câmera. Isso não significa que não possa ser aproveitada, nem que seja para umas experiências com o Homebridge.

Ter uma câmera dentro de casa permite criar um sistema de alarme com base na alteração do que a câmera capta. O resultado para mim foi passar a ver a última imagem capturada em caso de movimento e ter acesso ao vídeo do período do evento.

IMG_6385.jpg

Se têm um Homebridge no vosso Raspberry Pi, uma câmera e um iPhone, podem ter estas funcionalidades. Para isso terão de instalar e configurar o seguinte software:

Cada um destes componentes serve um propósito:

  • O Motion é um servidor de deteção de movimento com base em camêras compatíveis com Video for Linux (V4L2);
  • O v4l-util é o conjunto de utilitários que permite ao sistema utilizar câmeras e outros equipamentos de vídeo;
  • O Homebridge-Camera-motion é o módulo do Homebridge que permite configurar uma localização de um ficheiro especial de *nix e da última imagem capturada;
  • O fswebcam é um utilitário que permite testar a câmera.

A instalação dos componentes com através de um comando é trivial. Mais complicado é a configuração e os vários problemas que encontrei por ter um equipamento pouco recente e  algo instável.

Um dos problemas que encontrei foi quando a câmera falha, o device da câmera mudava de /dev/video0 para /dev/video1. Mesmo com regras em /etc/udev que criam um link simbólico de /dev/videoSpaceCam para /dev/video? .

Para combater isto, tive de criar um cão de guarda algo rudimentar que verifica qual o device no link simbólico e recria o link simbólico se não tiver vídeo no nome.

#!/bin/bash
SPACECAMDEV=$(ls -l /dev/videoSpaceCam | sed ‘s/.*> //’);

if [[ $SPACECAMDEV == *”video”* ]];
then
echo “SPACECAMDEV OK”
else
echo -e “$SPACECAMDEV NOK \n$(ls -la /dev/video*)”
DEVID=$(ls /dev/video? | sed ‘s/\/dev\/video//’)
rm /dev/videoSpaceCam;
ln -s /dev/video$DEVID /dev/videoSpaceCam;
fi

O script é depois chamado a cada minuto depois de configurado com o crontab.

Outro problema encontrado foi que a captura de imagem da câmera revertia sempre para um tamanho ainda mais pequeno que os incríveis e espetaculares 352 x 288 pixeis.

Para isso foi necessário configurar corretamente o motion para capturar na capacidade máxima da câmera. Isso é feito no motion.conf alterando o valor da variável v4l2_palette.

Para saber isso e outras coisas utilizei o comando v4l2-ctl:

v4l2-ctl –list-formats-ext — identificação do formato a configurar na variável v4l2_palette

v4l2-ctl –list-ctrls — lista de controles da câmera

Por último, para mostrar a imagem do último evento no iPhone, foi necessário criar um segundo cão de guarda.

O script procura a última imagem no diretório onde os eventos detetados são guardados e copia-a para o nome laspsnap.jpg para ser mostrado no iPhone.

#!/bin/bash
find /media/Media/Motion/ -maxdepth 1 -type f -name “*.jpg” -print0 | xargs -0r ls -tr  | tail -1 > lastjpeg
LASTJPEG=$(cat lastjpeg)
cp -f $LASTJPEG /media/Media/Motion/lastsnap.jpg

Guardo as imagens e filmes gerado pelo Motion num disco externo para evitar problemas de falta de espaço.

O Motion pode ser configurado para aceder remotamente a câmeras ip, o que facilita a configuração do sistema de controlo num sitio e de captura no outro.

Que ESP? Uma comparação de Espressif

ESP2866 placa programável com WiFi

ESP2866 placa programável com WiFi

Quando comprei o ESP8266 foi para me iniciar na criação de “coisas interligadas”. A primeira coisa que fiz foi uma espécie de “hello world” que mede a temperatura e a humidade.

Ultrapassados as primeiras dificuldades e concluída a aprendizagem, a construção de coisas interligadas está bastante facilitada por estes módulos. Só que o módulo é bastante volumoso porque têm muitos pontos de ligação e a parte de configuração tudo na mesma peça.

Existem módulos de volume mais reduzido, mas que podem não ter tudo o que precisamos. Por isso, fui à procura duma comparação entre estes módulos ESP8266, e encontrei. Esta página contém também uma comparação entre os módulos de desenvolvimento.

Adaptei a tabela de comparação sobre os módulos ESP8266 que podem encontrar no site.

ESP-01 ESP-12 ESP-201
ESP01v0 ESP-12 ESP-12
Pins GPIO 2 11 11

ADC (Analog-to-Digital Converter)

1 1
Antena PCB PCB Externa e PCB
Facilidade de utilizar numa Breadboard Media Boa
Tamanho Pequeno Médio Grande
Aplicação Standalone
ou como wifi shield para um Arduino
Standalone Standalone
Preço aproximado €2,00 €1,74 €3,31

O site tem também detalhes sobre os módulos de desenvolvimento, como o que veem na imagem acima, e a opinião do autor sobre cada módulo.

Encontrei também outra página, mas é uma comparação que vai para além dos módulos baseados em ESP8266, mas isso fica para outro dia.

ESP8266: um amigo para o RPi

ESP2866 placa programável com WiFi

ESP2866 placa programável com WiFi

O Espressif 8266(ESP8266) é uma placa programável com WiFi. Tal como o Raspberry Pi (RPi), mas com menos capacidade, dá-nos a liberdade de criarmos para nós coisas que a que dificilmente teríamos acesso por um preço tão baixo.

Aqui em casa vai servir para fazer tarefas que não posso por o RPi a fazer porque está agarrado à televisão a fazer de gestor de conteúdos multimédia ou Home Theater PC. O sensor de temperatura e humidade que tinha ligado ao RPi esteve a registar dados na sala, mas se quero dados de qualquer outro sitio, não posso andar a passear com isto tudo pela casa.

Como já sabemos, o RPi custa cerca de €35,00, enquanto o ESP8266 custa cerca de €5,00, na versão de desenvolvimento e menos que isso na versão definitiva. A diferença entre estas duas versões é a facilidade em programar e alimentar o ESP8266.

A versão de desenvolvimento tem uma porta USB que permite a programação sem mais nada para além de um cabo USB, enquanto a outra é mais pequena e a  programação depende da placa ser ligada através de outro equipamento.

O resultado prático é o mesmo que tinha já quando publiquei a informação sobre como ligar o HomeKit da Apple a equipamentos não certificados através do Homebridge. A diferença é que posso ter mais sensores por um preço muito baixo.

Apple TV, Homekit, Home App, Raspberry Pi e homebridge dá IoT

Works with apple HomeKit sticker

Works with apple HomeKit sticker

A Apple TV e o Home App no iPhone/iPad em conjunto trazem a possibilidade de termos um equipamento à imagem do Amazon Echo na nossa mão. O Amazon Echo era aquela torre que permitia o controlo por voz recorrendo ao Alexia da Amazon.

Com os equipamentos ligados através do HomeKit é possível configurar cenários e regras automáticas. Um cenário ou cena é uma configuração de todos os equipamentos para cumprir uma função, como por exemplo, baixar as luzes da sala quando vamos ver um filme. Já os automatismos podem recorrer a estes cenários ou fazer ações especificas como ligar equipamentos quando chegamos a casa ou desligá-los quando saímos de casa.

Apple HomeKit - Home layout

Apple HomeKit – Home layout

Podemos definir as divisórias da casa e os equipamentos que se encontram em cada divisória. Os serviços que cada equipamento presta aparecem depois junto com o equipamento.

A Apple TV funciona como o servidor central e faz a ligação da casa ao iPhone, quer estejamos em casa, quer estejamos noutro sitio qualquer.

Acontece que nos equipamentos que não estiver o autocolante a dizer que funciona com o Apple HomeKit, não há comunicação. Isto significa quase imediatamente que todos os equipamentos que tenham o autocolante serão mais caros.

Depois de alguma pesquisa na Web, decidi experimentar um mix de Raspberry Pi (RPi), iOS, TVos e outras coisas da Internet (IoT).

Ligado ao RPi tenho um sensor de humidade e temperatura. Para ter estes sensores a prestarem serviços através do HomeKit foi necessário instalar o Homebridge no RPi.

Instalar o node.js necessário para correr o Homebridge, ou mesmo os plugins do Homebridge, é bastante direto.

Configurar cada equipamento e serviço é feito à mão, editando o ficheiro de configuração do Homebridge. A configuração é feita através da edição do ficheiro de configuração em JavaScript Object Notation (JSON), uma forma de trocar dados muito em voga hoje em dia na web.

Home App no iPhone com sensores no Raspberry Pi mediados pelo Homebridge

Home App no iPhone com sensores no Raspberry Pi mediados pelo Homebridge

O resultado é poderem consultar os vossos sensores no iPhone/iPad em qualquer lugar e configurar condições baseadas nesses sensores.