[hvalentim]

Bom Dia,

O WeatherDuino conhece a humidade exterior com precisão decimal e mostra-a como tal no ecrã. Por exemplo, num dia de nevoeiro cerrado vejo algo como 99,4%.

Porém dou-me conta de que na base de dados os valores estão sempre arredondados para a unidade.

Dúvida 1: o protocolo Davis admite como precisão máxima a unidade percentual?

Dá-me impressão que na comunicação tanto o WeatherDuino como o WeeWX estão a trabalhar nesse pressuposto.

A minha Dúvida 2 é: se se retirar o "Round the reading" no loopData.outsideHumidity tecnicamente é possível enviar no loop e guardar no arquivo com precisão decimal ?

Cump.s

[werk_ag]

Olá, boa tarde

Dúvida 1: o protocolo Davis admite como precisão máxima a unidade percentual?

Não, para a Humidade, tanto interna como externa, apenas valores inteiros.

A minha Dúvida 2 é: se se retirar o "Round the reading" no loopData.outsideHumidity tecnicamente é possível enviar no loop e guardar no arquivo com precisão decimal ?

A váriavel que armazena esse valor tem de ser do tipo inteiro, razão pelo qual o valor é arredondado antes de ser atribuido à váriavel.
Por outro lado, sendo que o WeeWX segue estritamente o protocolo Davis, certamente tambem ele espera receber um valor inteiro.

Cumps

[hvalentim]

Não, para a Humidade, tanto interna como externa, apenas valores inteiros.

Penso que estávamos a pensar no mesmo. O valor tem que ser um número inteiro de 0 a 100.

A váriavel que armazena esse valor tem de ser do tipo inteiro, razão pelo qual o valor é arredondado antes de ser atribuido à váriavel.
Por outro lado, sendo que o WeeWX segue estritamente o protocolo Davis, certamente tambem ele espera receber um valor inteiro.

Sim. o WeeWX também espera receber um número inteiro. Mas na base de dados o valor é guardado com espaço para a décima (eg. 98,0) pelo que talvez não fosse difícil "martelar"/adaptar o driver para lidar com uma resolução na casa das décimas.

Não obstante, pelo que entendo, o "espaço" (os bytes disponíveis, se assim se pode dizer) reservado na comunicação não admite aumentar a resolução, é isso?

É pena. Porque observando o ecrã os valores progridem com uma certa consistência (82,5 - 82,6 - 82,7).

[hvalentim]

Se bem entendi, para quem se queira meter em "invenções" deveria no entanto ser possível melhorar a resolução para 0,5% (valores até 200). Era caso para pôr depois o WeeWX a fazer a divisão por 2...

EDITADO: Em relação ao infra, finalmente, deve explicar-se pelo facto de estar a usar o record_generation em modo "software". Neste caso, o WeeWX fará algo com uma média dos loops. Olhando os períodos em que o tive em modo hardware (e o valor era recuperado do arquivo) os valores nesse caso são sempre números inteiros.

Olhando a base de dados com mais atenção há uma coisa que eu não entendo (embora isto seja uma pergunta melhor posta no Weews UserGroup): se o WeatherDuino manda valores inteiros e o WeeWX espera valores inteiros porque é que na base de dados surgem por vezes resoluções mais detalhadas (tanto na temp. externa como interna). Por exemplo:
"83.6302521008403"
"81.775"
"81.3898305084746"
"81.0"
"81.0"

À partida poderia ter que ver com o processo de conversão entre unidades de medida, mas o valor da humidade não deveria precisar disso. % é %.

---

Bom. Parece que o driver trata o valor da humidade como floating point quando talvez o devesse tratar as it is como integer.

def _little_val(v):
return float(v) if v != 0x00ff else None

Seja como for não se entende bem a aparente arbitrariedade do resultado que acaba na base de dados.

[werk_ag]

Caro hvalentim

Deixe aproveitar esta ocasião e espero não leve a mal, para tentar esclarecer algo que já vi algumes vezes expresso em alguns dos seus topicos, e se se prende com o conceito "Arquivo" e "Loop".

Olhando os períodos em que o tive em modo hardware (e o valor era recuperado do arquivo) os valores nesse caso são sempre números inteiros

Qualquer dos softwares quando em comunicação com um sistema Davis, obtem sempre os seus dados atravês do comando Loop, os dados do "Arquivo" que suponho se refere ao que está armazenado na memória (logger), apenas são lidos no arranque do software, quando em funcionamento o logger nunca é acedido.
O WeeWX quer esteja em modo hardware quer em modo software, obterá sempre os dados através do que é disponibilizado pelo comando Loop.

Passando este preambulo...

para quem se queira meter em "invenções"

A estrutura de dados da Davis e o tipo das variáveis a serem usadas está perfeitamente definido, é não vejo possível "inventar", especialmente no caso do tipo das variáveis. O espaço de armazenamento para este dado (Hum) é de apenas 1 byte, em virgula flutante seriam precisos 4 bytes. A estrutura de dados (do logger tambem) não o permitiria.

Vendo bem as coisas, o erro resultante de não armazenar o valor com uma casa décimal, é inferior ao da margem de erro do sensor.

Mostrar os valores da Humidade com uma casa decimal, é um bonus do sistema WeatherDuino Pro2. E não é só na Humidade, nos sensores Extra, tambem! No entanto e pelos mesmos motivos, nos registos ficam apenas inteiros, apesar de que poderá ver neles valores com uma casa decimal, se analizar bem, verá que eles são sempre multiplos de 1ºF, e aparecem com uma casa decimal devido à conversão de F para C.

Cumps. e obrigado por sempre tentar levar as coisas mais além.

[hvalentim]

os dados do "Arquivo" que suponho se refere ao que está armazenado na memória (logger), apenas são lidos no arranque do software, quando em funcionamento o logger nunca é acedido.
O WeeWX quer esteja em modo hardware quer em modo software, obterá sempre os dados através do que é disponibilizado pelo comando Loop.

Não exactamente. O WeeWX permite definir dois modos para gerar os valores que guarda na sua base de dados: hardware e software.

No modo "hardware" (que é o por defeito) o programa efectivamente recupera e usa os valores do registo guardado no "logger" do WeatherDuino a cada período definido (no meu caso a cada 5 minutos), à medida que são gerados. Inclusive permite definir um período em segundos (archive_delay) entre o registo ser gerado pela estação meteorológica e ele efectuar a sua recuperação.

Já no modo "software" o programa só usa o arquivo/logger do WeatherDuino para preencher na sua base de dados os períodos em que o computador em que ele esta a correr esteve desligado da estação, gerando os demais a partir do processamento dos dados em tempo real.

Da Documentação (aqui):

[StdArchive]

This section is for configuring StdArchive, the service that stores data in a database.

archive_interval
If your station hardware supports data logging then the archive interval will be downloaded from the station. Otherwise, you must specify it here in seconds. Optional. Default is 300 seconds.

archive_delay
How long to wait in seconds after the top of an archiving interval before fetching new data off the station. For example, if your archive interval is 5 minutes and archive_delay is set to 15, then the data will be fetched at 00:00:15, 00:05:15, 00:10:15, etc. This delay is to give the station a few seconds to archive the data internally, and in case your server has any other tasks to do at the top of the minute. Default is 15 seconds.

record_generation
Set to whether records should be downloaded off the hardware (recommended), or generated in software. If set to hardware, then weewx tries to download archive records from your station. However, not all types of stations support this, in which case weewx falls back to software generation. A setting of hardware will work for most users. A notable exception is users who have cobbled together homebrew serial interfaces for the Vantage stations that do not include memory for a logger. These users should set this option to software, forcing software record generation. Default is hardware.

loop_hilo
Set to True to have LOOP data and archive data to be used for high / low statistics. Set to False to have only archive data used. If your sensor emits lots of spiky data, setting to False may help. Default is True.

Em relação ao resto de acordo. Do ponto de vista do desenvolvimento e de quem desenvolve não se pode mexer no protocolo sem quebrar a compatibilidade.

As modificações terão que ser individuais e por conta e risco de cada um. O que tem-se visto é parte do gozo e da superioridade do sistema WeatherDuino.

[hvalentim]

Se bem entendi, para quem se queira meter em "invenções" deveria no entanto ser possível melhorar a resolução para 0,5% (valores até 200). Era caso para pôr depois o WeeWX a fazer a divisão por 2...

OK, Testado e confirmado. Funciona.

Caso para mudar no WeatherDuino para:
* 0.2; // Round the reading

E definir no weewx.conf:
outHumidity = outHumidity * 0.5

Não chega a ser preciso mexer no driver.

Resultado: o valor da humidade para a ser transmitido arredondado com a resolução de 0,5%.

[werk_ag]

No modo "hardware" (que é o por defeito) o programa efectivamente recupera e usa os valores do registo guardado no "logger" do WeatherDuino a cada período definido (no meu caso a cada 5 minutos), à medida que são gerados. Inclusive permite definir um período em segundos (archive_delay) entre o registo ser gerado pela estação meteorológica e ele efectuar a sua recuperação.

Efectivamente você esta certo! Acabei por ir verificar isso, e assim é. Tanto quanto agora sei o WeeWx é o unico a aceder ao logger após inicialização.
Você nem imagina o quao importante este facto é, para umas coisas que tenho em mente. Tomar conhecimento disto, não podia vir em melhor altura! Uma coisa é certa, vou passar a incluir o WeeWx como arma pesada nos testes de desenvolvimento.

Em relação ao resto de acordo. Do ponto de vista do desenvolvimento e de quem desenvolve não se pode mexer no protocolo sem quebrar a compatibilidade.

As modificações terão que ser individuais e por conta e risco de cada um. O que tem-se visto é parte do gozo e da superioridade do sistema WeatherDuino.

Possivelmente, você será das pessoas que mais tem explorado essas potencialidades. De facto, ter acesso ao codigo fonte é uma vantagem que outros sistemas não permitem.

OK, Testado e confirmado. Funciona.

Caso para mudar no WeatherDuino para:
* 0.2; // Round the reading

Nem duvido. Basicamente é um "truque" semelhante ao que usei para permitir ter uma resolução da velocidade do vento bem melhor do que a de 1mph, definida no protocolo. O que não é possível fazer é mudar o tipo das váriáveis, agora o que se põe nelas é outra conversa. Neste caso, com a alteração que fez, o valor Hum * 2 continua a caber num byte, é só desfazer do outro lado