EMM issueshttps://git.cta.if.ufrgs.br/groups/emm/-/issues2019-09-18T22:25:19Zhttps://git.cta.if.ufrgs.br/emm/emm-webapp/-/issues/2Problemas na exportação de dados das EMM a partir do site de dados.2019-09-18T22:25:19ZLeonardo SehnProblemas na exportação de dados das EMM a partir do site de dados.Estou enfrentando alguns problemas quando tento realizar a exportação dos dados das EMM. São problemas diferentes, irei agrupá-los de acordo com o tipo.
**EMM 32 da instância emm**
Quando tento realizar a exportação, é exibido o có...Estou enfrentando alguns problemas quando tento realizar a exportação dos dados das EMM. São problemas diferentes, irei agrupá-los de acordo com o tipo.
**EMM 32 da instância emm**
Quando tento realizar a exportação, é exibido o código "502 Bad Gateway". Este problema é de longa data.
**EMM 4 da instância emm2**
Quando tento realizar a exportação, é exibido o aviso "Internal Server Error". Este problem ocorre pelo menos desde o dia 5 de Janeiro de 2018.
**EMMs 5 e 6 da instância emm2 e EMM 51 da instância emm.**
Quando abro os dados exportados da EMM 5 da instância emm2, são exibidas 15836 linhas de dados, com o último dado das 19:20:42 do dia 2018-01-15. Existem dados registrados no site e expostos nos gráficos que não constam neste arquivo, pois a EMM já conta com 132640 pontos de medida, sendo a última medida às 13:01:30 do dia 07/03/2018, ou seja, até recentemente.
Quando abro os dados exportados da EMM 6 da instância emm2, são exibidas 18418 linhas de dados, com o último dado das 00:10:34 do dia 2018-02-02. Existem dados registrados no site e expostos nos gráficos que não constam neste arquivo, pois a EMM já conta com 56090 pontos de medida, sendo a última medida às 10:52:51 do dia 05/03/2018, ou seja, até recentemente.
Quando abro os dados exportados da EMM 51 da instância emm, são exibidas 708 linhas de dados, com o último dado das 13:10:00 do dia 2017-09-02. Existem dados registrados no site e expostos nos gráficos que não constam neste arquivo, pois a EMM conta com 11084 pontos de medida, sendo a última medida às 18:22:00 do dia 08/10/2017.
Nelso JostNelso Josthttps://git.cta.if.ufrgs.br/emm/meteorolog/-/issues/8Impossibilidade de envio de muitos dados para serial (via esp) e cartão microSD2019-09-18T22:25:20ZMarina Freitasmarina.freitas@ufrgs.brImpossibilidade de envio de muitos dados para serial (via esp) e cartão microSD
### O obejtivo
Meu objetivo é hackear o sistema de aquisição de dados da emm (exceto envio de dados apra o servidor) para usar em outra pesquisa na qual serão usados 7 DHTs e 1 LDR. As alterações feitas no hardware estão detalhadas ...
### O obejtivo
Meu objetivo é hackear o sistema de aquisição de dados da emm (exceto envio de dados apra o servidor) para usar em outra pesquisa na qual serão usados 7 DHTs e 1 LDR. As alterações feitas no hardware estão detalhadas aqui: http://cta.if.ufrgs.br/issues/481#note-10 . As alterações feitas no meteorolog estão aqui http://cta.if.ufrgs.br/issues/481#O-que-eu-fiz . As alterações feitas no esplogger estão aqui http://cta.if.ufrgs.br/issues/481#Esplogger . Vou descrever abaixo as alterações no espelogger por achar pertinente a este problema:
No arquivo meteorolog.cpp da pasta espelogger alterei as linhas 317-324, onde alterei o nome da variável "sensor_name" e do argumento dentro de "root_sensors". Além disso, adicionei esse código 6 vezes, trocando o nome do "sensor_name" e do argumetno de "root_sensors" (cada DHT recebeu o nome de uma letra, de A a G, e suas variaveis e apelidos também, por isso "ta" é a temperatura do DHT A, "tb" é a temperatura do DHT B, etc).
else if (sensor_name == "ta") {
root_sensors["DHT22_TEMP_A"] = value;
}
else if (sensor_name == "aha") {
root_sensors["DHT22_AH_A"] = value;
}
Os firmwares alterados estão aqui http://cta.if.ufrgs.br/attachments/4595/Firmware_esplogger_meteorolog.zip
Mais detalhes na tarefa: http://cta.if.ufrgs.br/issues/481
### O Problema
Grandes quantidades de dados (mais de 100 bytes) não estão sendo corretamente enviados para a serial (via espe) nem para o cartão microSD.
A partir da décima variável incluida (contando dt) (mais de 100bytes) no comando "meteorolog" ou "arduino read" enviado via esp, a resposta do esp começa a ser errada (até a nona a resposta é correta). Ao invés de responder o valor da variável, o valor da variável anterior é substituída por " " (espaço vazio).
Exemplo:
>[DEBUG] Sending command 'read,dt,l,ta,tb,tc,td,te,tf,tg' to Arduino.
>[INFO] Sucessfully updated 'LOGGER.CONF' (SPIFFS)
>[DEBUG] Reading arduino serial response..
>[INFO] Recieved: '2018-1-15 16:10:36,94.330406,26.500000,26.600000,26.700001,26.299999,26.900000,26.299999,26.799999' (119 bytes)
>[DEBUG] --- JSON created ---
>{}
>[INFO] Attemping upload to server..
>[HTTP] POST...
>[DEBUG] Response:
>[INFO] 122 bytes written at 'DATALOG.TXT'
A resposta foi a esperada, mas ao adicionar mais 1 variável:
>[DEBUG] Sending command 'read,dt,l,ta,tb,tc,td,te,tf,tg,aha' to Arduino.
>[INFO] Sucessfully updated 'LOGGER.CONF' (SPIFFS)
>[DEBUG] Reading arduino serial response..
>[INFO] Recieved: '2018-1-15 16:10:36,94.330406,26.500000,26.600000,26.700001,26.299999,26.900000,26.299999,,' (119 bytes)
>[DEBUG] --- JSON created ---
>{}
>[INFO] Attemping upload to server..
>[HTTP] POST...
>[DEBUG] Response:
>[INFO] 122 bytes written at 'DATALOG.TXT'
No exemplo abaixo isto não fica claro, mas nos testes seguintes os valores passavam a ser substituídos por " " regressivamente. A resposta quando todos as 16 variáveis são chamadas é:
>
Note que o envio do pedido da medida "ahc" foi corretamente recebido, mas a resposta foi " ". A adição de cada nova variável faz com que o valor da variável anterior seja substituído por " ". E assim por diante a cada nova variável adicionada até que todas são comidas ([INFO] Recieved: '2018-1-15 16:10:36,94.330406,,,,,,,,). Um efeito similar ocorre se chamar as medidas "ah" primeiro e as "t" depois.
A resposta para cada DHT separadamente foi correta.
### O que eu tentei fazer
Edições:
* Na linha 1833 do ArduinoJson.h troquei "256" por "1024"
* Na linha 290 do meteorolog.cpp, alterei o tamanho do StaticJsonBuffer, de 500 para 1000.
** Fiz o mesmo nas linhas 201, 233, 261, 290, 403.
** Tentei alterar para 2000 e para 5000, só na linha 290, depois em todas
A resposta permaneceu a mesma em todos os casos (sim, eu lembrei de fazer upload dos novos firmwares).
Marina Freitasmarina.freitas@ufrgs.brMarina Freitasmarina.freitas@ufrgs.brhttps://git.cta.if.ufrgs.br/emm/emm-webapp/-/issues/1502 Bad Gateway error quando tento ver os gráficos2019-09-18T22:25:20ZMarina Freitasmarina.freitas@ufrgs.br502 Bad Gateway error quando tento ver os gráficosJá faz um mês, notei que quando tentava olha o valor de umidade do ar da EMM CTA_LEO, localizada no CTA, o erro "502 Bad Gateway - nginx/1.6.2" ocorria. Como era um erro muito pontual, não dei bola. Porém, o erro se estendeu para a EMM "...Já faz um mês, notei que quando tentava olha o valor de umidade do ar da EMM CTA_LEO, localizada no CTA, o erro "502 Bad Gateway - nginx/1.6.2" ocorria. Como era um erro muito pontual, não dei bola. Porém, o erro se estendeu para a EMM "Residência Hacker", com todos os sensores! Em contra partida, o erro não aconteceu mais na EMM CTA_LEO.
O erro aparece somente quando clico no nome do sensor para ver a tabela de medidas. Vi este erro acontecendo no note do CTA, e no meu note (debian também) e no celular. Fiz alguns procedimentos para verificar se o problema não era no meu computador (reiniciei o browser, limpei cookies, etc), mas não obtive nenhum resultado.
Não sabia bem onde registrar este problema, mas imaginei que como o desenvolvimento do web-app é mais firmado aqui do que no site, seria melhor registrar nesta ferramenta.
https://git.cta.if.ufrgs.br/emm/meteorolog/-/issues/7Sugestão: alterar pino do DHT2019-09-18T22:25:20ZMarina Freitasmarina.freitas@ufrgs.brSugestão: alterar pino do DHTO pino usado para o DHT no shield do Meteorolog2 é o 6, diferente do definido no Meteorolog02. No materiald as oficinas o pino usado é o 4, mas creio ser mais importante se basear no eteorolog2.
https://cta.if.ufrgs.br/attachments/12...O pino usado para o DHT no shield do Meteorolog2 é o 6, diferente do definido no Meteorolog02. No materiald as oficinas o pino usado é o 4, mas creio ser mais importante se basear no eteorolog2.
https://cta.if.ufrgs.br/attachments/1250/meteorolog2_1v0_esquematico.jpg
http://cta.if.ufrgs.br/projects/estacao-meteorologica-modular/wiki/Montando_uma_Esta%C3%A7%C3%A3o_Meteorol%C3%B3gica_em_Protoboardhttps://git.cta.if.ufrgs.br/emm/meteorolog/-/issues/6Falha Inclusão de bibliotecas pelo caminho relativo "libs/"2019-09-18T22:25:20ZMarina Freitasmarina.freitas@ufrgs.brFalha Inclusão de bibliotecas pelo caminho relativo "libs/"Fiz os passos 1 e 2 tranquilamente. Ao tentar instalar o firmeware pela ID do arduino o programa nem compilou. A mensagem de erro foi:
In file included from mysensors.cpp:2:0:
mysensors.h:9:22: fatal error: libs/DHT.h: Arquivo o...Fiz os passos 1 e 2 tranquilamente. Ao tentar instalar o firmeware pela ID do arduino o programa nem compilou. A mensagem de erro foi:
In file included from mysensors.cpp:2:0:
mysensors.h:9:22: fatal error: libs/DHT.h: Arquivo ou diretório não encontrado
#include "libs/DHT.h"
^
compilation terminated.
Acho isto estranho pois o arquivo DHT.h encontra-se dentro da pasta libs.Nelso JostNelso Josthttps://git.cta.if.ufrgs.br/emm/meteorolog/-/issues/5Fuso horário2019-09-18T22:25:20ZMarina Freitasmarina.freitas@ufrgs.brFuso horárioOlá,
Notei que não há a opção para o usuário definir seu fuso horário, nem horário de verão.
Acho importantante discutirmos como solucionar esta questão. Se a estação do usuário estiver conectada ao computador, o horário de verão se...Olá,
Notei que não há a opção para o usuário definir seu fuso horário, nem horário de verão.
Acho importantante discutirmos como solucionar esta questão. Se a estação do usuário estiver conectada ao computador, o horário de verão será trocado automaticamente. Haverá uma hora sem dado nenhum e outra com dois dados.
Além disso, os horários dos usuários devem estar sincronizados. Imagine quando tivermos um mapa, ou quando os dados forem usados para pesquisa, se o relógio de um usuário estava atrasado em relação ao outro, ao se juntar os dados, a informação estará incorreta. O que um coletou as 13h, outro coletou as 13h02.
Devemos discutir qual será o padrão seguido pelo CTA.https://git.cta.if.ufrgs.br/emm/meteorolog/-/issues/4Meu teste com o Meteorolog 022019-09-18T22:25:20Zrenan da silvaMeu teste com o Meteorolog 02Baseado na [wiki] (https://git.cta.if.ufrgs.br/meteorolog/arduino-meteorolog/wikis/home#utilizando-o-software), fiz o teste com a estação conectada ao Raspberry. Alguns comentários:
### virtualenv
> $ sudo apt-get install python3 p...Baseado na [wiki] (https://git.cta.if.ufrgs.br/meteorolog/arduino-meteorolog/wikis/home#utilizando-o-software), fiz o teste com a estação conectada ao Raspberry. Alguns comentários:
### virtualenv
> $ sudo apt-get install python3 python3-pip python3-virtualenv supervisor
retorna:
> E: uneable to locate package python3-virtualenv
---
O comando
> $ sudo apt-get install python-virtualenv
(sem o "3" depois de "python") funcionou.
---
### Data
configurei uma data aleatória no relógio, e ela aparece com
> >>> send('read,dt')
mas na [página] (http://dados.cta.if.ufrgs.br/emm/board/20) aparece a data do Rasp (que estava errada, motivo pelo qual a data no gráfico estava estranha -- estava em agosto e tal).
Ajustei a data do Rasp e dei
> $ make undeploy
> $ make clean-data
> $ make clean-logs
> $ make deploy
e volta o erro
> make: warning: Clock skew detected. Your build may be incomplete.
Então dei
> $ make undeploy
> $ make clean-data
> $ make clean-logs
e configurei a data correta no relógio; mas o erro continuou, e na [página] (http://dados.cta.if.ufrgs.br/emm/board/20), continua com a data estranha (agosto), mas a hora nova (correta) -- apesar da hora estar correta, na [página] (http://dados.cta.if.ufrgs.br/emm/board/20) ainda aparece dado com a hora antiga (agora são 15:16 e aparece um dado de 17:00 *antes* no gráfico) -- e não aparece nada no eixo x, onde deveria estar a data. Reiniciei o Rasp e mudei o *settings.yaml* para mandar a cada 30 segundos; e agora, na página, os gráficos mostram ainda a hora errada (e, agora, *só* a hora errada) e diferentes valores para mesmos horários -- agora voltou o eixo x.![Captura_de_tela_de_2015-07-17_15_48_22](https://git.cta.if.ufrgs.br/meteorolog/arduino-meteorolog/uploads/1d0992e1784d149fbf7683559cb1e139/Captura_de_tela_de_2015-07-17_15_48_22.png)
---
Sei que o comando
> $ make sync-rtc
havia sido dado anteriormente; imagino que esses problemas são resultado de alguma confusão com a configuração do relógio. O Rasp está alterando a hora sozinho (provavelmente para um fuso horário diferente), mas o mês está correto (diferente do que aparece nos gráficos na página).
---
Resumindo:
1. Não consigo desfazer a a sincronização do relógio da placa com o do Rasp.
2. Por algum motivo, a [página] (http://dados.cta.if.ufrgs.br/emm/board/20) dá uma informação de um mês no futuro (mesmo que, no Rasp, o mês esteja correto).Nelso JostNelso Jost