Ligação direta entre Raspberry PI e EMI via RS485/USB dá timeout

Olá a todos. Não queria inaugurar a minha presença aqui com uma questão, mas a verdade é que as coisas não me estão a ir de feição.

Ora, encomendei um Waveshare Industrial USB to RS485 Converter e passei cabo do contador para dentro de casa, onde tenho um Raspberry Pi. Nele, decidi brincar um bocado. Por isso, criei um pequeno programa em C para comunicar com o contador usando a biblioteca modbus.

O output não é o esperado:

Opening /dev/ttyUSB0 at 9600 bauds (N, 8, 1)
connect returned 0
Bytes flushed (0)
flushing 0 bytes...
[01][04][00][04][00][01][70][0B]
Waiting for a confirmation...
ERROR Connection timed out: select
Bytes flushed (0)
Failed to modbus_read_input_registers: Connection timed out
n: 00, content: 0
n: 01, content: 0
n: 02, content: 0
n: 03, content: 0
n: 04, content: 0
n: 05, content: 0
n: 06, content: 0
n: 07, content: 0

Estou convencido de que o aparelho está bom (a luz TX pisca quando o pedido é enviado), e a ligação também me parece sólida (tenho os 5v do EMI nos fios dentro de casa). O que está de facto a faltar é uma resposta.

Alguém que já tenha andado nestas andanças tem alguma ideia do que posso estar a fazer mal?

(btw, se porventura isto dever estar noutra parte do fórum, pf apitem)

Antes de cenas complexas tens de saber se o modbus funciona.

Qual o contador?

O 0x0004 vai responder 6 bytes.

Se o Rx não piscar nem reposta recebeste.

É melhor tentar com o 0x006c primeiro.

Algo para testar:

Ou outros

[[https://github.com/nikito7/edpbox-dev/tree/dev/modbus/modpoll]]

Obrigado pelas sugestões.

O contador é o Landis+Gyr ZCXe110CRU0L3D2.03 S3

Poderá ser Stop Bits 2

Por muito absurda que a ideia seja (em virtude do que diz naquele doc da EDP que todos conhecemos), usar 2 deu origem a resposta! Vou investigar por aqui abaixo, ver o que sai. Merci

1 Curtiu

A maioria dos Ziv são Stop Bits 2.

Metade dos Landis idem.

Houve um update aos Landis em algumas zonas para Stop Bits 1.

Ou seja, há divergências entre a spec e a realidade. É só nas configurações das comunicações, ou nos comandos também?

A v0 é Stop Bits 2
A v1 (2020) é Stop Bits 1

Mas os contadores antigos não foram actualizados.

A v1 traz o Stop Bits 1 e a ultima parte do pdf (registos de falhas)
Aqui nunca funcionou.

Depois há os L1 L2 L3

Os contadores monofásicos antigos dão erro se tentares aceder a esses registers

Alguns novos reportam zero.
O que obriga a ter código para monofásicos e trifasicos.

Nos trifásicos consegues a maioria da informação num só pedido (ou monofásicos que reportam zero nos L)

Entretanto consegui avançar com isto e o código funciona de facto. Estou a mandar tudo para MQTT e daí importo para o Home Assistant. Aparentemente, está bonito. Para documentação futura, está tudo no repo (:

1 Curtiu

Se quiseres mais desafio tens o diagrama de carga / Load Profile.

01 44 06 01 crc crc

[[https://github.com/nikito7/edpbox-dev/tree/dev/modbus/moacir]]

[[https://github.com/nikito7/edpbox-dev/tree/dev/tasmota/notes]]

1 Curtiu

Ou mesmo fazer dump do histórico

[[https://github.com/nikito7/edpbox-dev/blob/dev/tasmota/notes/dump.js]]

Kaifas tem bug

Não passa de 01FF a 0200. Repete os dados.

Só tem cerca de 512 linhas viáveis.

Isto os kaifa mais antigos

Ver o histórico é algo que me agrada, apesar de não estar certo de como importar os dados no hass. De qualquer modo, não encontrei nada no PDF da EDP sobre isso. É omisso, ou vi mal, @nikito7?

É o Load Profile

O resultado é parecido com o xlsx da e-eredes

Não sei o que é isso :eyes:

https://www.e-redes.pt

Ah, got it. Vou investigar, nunca olhei para isso.


Copyright © 2017-2021. Todos os direitos reservados
CPHA.pt - info@cpha.pt


FAQ | Termos de Serviço/Regras | Política de Privacidade