Clubeletricos.com

Alterar o codigo dos Pzems seria uma dor de cabeça até para mim que o elaborei, não vai passar dos 3 por eNode. Há a possibilidade de fazer diferente como o RJSC uma vez referiu, se se programar o endereço de cada pzem antes de os ligar, teoricamente poderiam-se ligar muitos na mesma porta serie que o software iria requisitando os dados a um de cada vez. Mas o meu codigo seria inútil nesse caso e teria que fazer tudo do inicio. Também acho que teriam que se ajustar as resistencias nos pzems adicionais.

Apr Escreveu: Há a possibilidade de fazer diferente como o RJSC uma vez referiu, se se programar o endereço de cada pzem antes de os ligar, teoricamente poderiam-se ligar muitos na mesma porta serie que o software iria requisitando os dados a um de cada vez.

Usar o I2C? Esquece...é muito lento..eu estava a ir por aí, com o nodeMCU e ADCs ADS1115, mas cheguei à conclusão que mesmo requisitando apenas 1000 samples para os cálculos usando as bibliotecas do openenergymonitor e mal cumpria os requisitos de ter valores ao fim de 10s.

Outra questão: no esquema no gtihub diz para colocar resistências de 510 Ohm no local de R17 e para deixar apenas a R15 num dos PZEM. Esta ultima "instrução" é mesmo assim? É para remover a R15?

Não tem nada a ver com I2C nem ADC's. O PZEM é um medidor completo, calibrado pronto a usar. Só é preciso requisitar os dados prontos a consumir da sua porta Serial. Até há uns à venda com um dongle USB adicional para o ligar a uma porta USB de um PC qualquer.

jfr2006 Escreveu: Outra questão: no esquema no gtihub diz para colocar resistências de 510 Ohm no local de R17 e para deixar apenas a R15 num dos PZEM. Esta ultima "instrução" é mesmo assim? É para remover a R15?

Sem medo, desde que fique 1 e só 1 resistencia ligada ao pino Rx do ESP8266!

Eu ando a trabalhar numas versões que me permitam recolher dados de vários equipamentos com uso intermitente.
Neste caso, uma tomada que poderá medir cargas pontuais como máquinas de lavar, pequenos electrodomésticos, etc.
Vou construir outra para medir uma carga que tenho lá em casa que é um verdadeiro vampiro! Um aquário de 250litros de água quente!!!
Estou a ter problemas com a comunicação com o PZEM, mas fica aqui a ideia...

Está com bom aspecto
Força no projeto!

Apr Escreveu:Não tem nada a ver com I2C nem ADC's. O PZEM é um medidor completo, calibrado pronto a usar. Só é preciso requisitar os dados prontos a consumir da sua porta Serial. Até há uns à venda com um dongle USB adicional para o ligar a uma porta USB de um PC qualquer.

Acho que não me fiz entender

- Eu sei que o PZEM faz a "papinha" toda
- Inicialmente estava a fazer algo deste género: https://www.seeed.cc/project_detail.html?id=378 . Só que isto serve para medir apenas um consumo, mas com mais elementos e tentar medir mais consumos já não vai lá. Por isso é que estava a perguntar se ias usar o I2C para ligar os PZEM, mas já percebi que eles só tem uma simples UART.
Mas se a ideia é usar o endereçamento do tipo IP que eles tem, acho que aquilo é só mesmo para enfeitar Pelo menos nos comandos que se envia ao PZEM não vi nada que usasse isso.

E que tal usar antes 1 ou 2 pinos do ESP para controlar um MUX e selecionar qual o PZEM a ler? É capaz de ser implementável, não?

O IP é um identificador que pode ser gravado no PZEM. Pode-se dar endereços aos PZEMs e isso permite colocá-los num BUS partilhado. Assim quando se envia uma pedido de dados, todos recebem e só o PZEM com o IP certo responde. O eNode tira partido do BUS partilhado para receber os dados dos variados PZEMs.

Esquece.. que tapado O endereço está lá sempre nos comandos pedidos ao PZEM, mesmo à frente dos meus olhos (C0 A8 01 01 = 192.168.1.1)

Apr Escreveu:O IP é um identificador que pode ser gravado no PZEM. Pode-se dar endereços aos PZEMs e isso permite colocá-los num BUS partilhado. Assim quando se envia uma pedido de dados, todos recebem e só o PZEM com o IP certo responde. O eNode tira partido do BUS partilhado para receber os dados dos variados PZEMs.

Quando falas do eNode, não é deste projecto: https://github.com/apreb/eNode ?

É que aqui, pelo que percebi usas a porta RX da UART0 para receber os dados dos vários PZEM e as portas TX0,TX1 e TX2 para enviar o comando para cada PZEM distinto.

jfr2006 Escreveu: Quando falas do eNode, não é deste projecto: https://github.com/apreb/eNode ?

É que aqui, pelo que percebi usas a porta RX da UART0 para receber os dados dos vários PZEM e as portas TX0,TX1 e TX2 para enviar o comando para cada PZEM distinto.

Sim,quando falamos em PZEMs e ESP8266 até ver são exclusivos desse projeto. Nota que o ESP8266 apenas tem uma UART, o resto é emulado por software e funciona mal. a motivação de ter 3 linhas Tx é para nao ter que ligar os PZEMs um a um para lhe dar um endereço antes de os ligar, a rotina faz isso quando o tenta iniciar. A linha comum RX de todos os PZEM's é para evitar problemas com o softwareSerial que funciona muito mal e causa interferencias no funcionamento do WiFi.

Aqui vai a versão final... não está bonito, mas funciona!
Veio um novo PZEM e montei tudo de novo. Estava a ter problemas com a comunicação com o PZEM anterior, e tudo leva a crer que está "morto"... não sei se já veio assim ou se o "matei" com alguma forma... mistério!
Aqui vão umas imagens:
https://imgur.com/a/gvoIU
https://imgur.com/a/xjQdl