Aumentaram o preço??
Já está no sitio , o colaborador que veio montar , diz que passa aqui amanha ou depois para por o cabo, diz que a porta fica logo activada
.
O contador Tem duas tomadas RJ12, qualquer uma delas dá para ligar a ficha?
Nestes Ladis+Gyr modelo ZCXe110CRU0L3D2.03 S3 (plc) as portas HAN funcionam bem , não é como nos ZIV?
Em conversa com o colaborador diz que estão a mudar os ZIV, pk tem dado problemas , não soube dizer que problemas.
.
Estando o contador no exterior sujeito a forte humidade, as fichas estão sujeitas a oxidar, sei que há uma especie de massa “azul” que era usada pelos antigos TLP em tomadas problematicas, alguem sabe exactamente o que é e onde se compra?
P.e.f., podes colocar o hardware que utilizaste e algumas fotos.
Ainda não tenho a porta disponivel para testar , mas tenho feito testes em “bancada”
wemos <-> [TTL/RS485 (modulo do tutorial)] <-> RS485/USB <-> PC
e as strings dos pedidos modbus que obtenho no PC são algo estranhas para modbus , está a passar pela ideia que a origem pode estar algures no hardware utilizado , especialmente o wemos.
Pk substituindo o wemos por conversor USB/TTL (fica assim o esquema)
PC <> USB/TTL <-> [TTL/RS485 (modulo do tutorial)] <-> RS485/USB <-> PC
as strings que envio de um lado chegam exactamente iguais ao outro e vice versa.
Coloca os equipamentos e ligações dentro de uma caixa de exteriores e estanque. Há à venda nos locais habituais, por exemplo, AKI e Leroy.
1 Curtiu
eu já tentei as varias combinações A/B e nao tive resultados nenhuns por aqui
pode ser que mais alguém teste e que possa também confirmar o mesmo para ter certezas que nao é por ai o problema…
Com os testes que fiz, acho que o problema não vai ser do cabo, por isso em principio vai ficar tudo dentro de casa.
Como não consegui passar cabo PIMF 2x2x1 (encravava a meio) acabei por passar os 30m UTP CAT. Para testar comunicação, criei cenario de comunicação semelhante ao que se irá verificar qd tiver a porta do contador disponivel , PC <> USB/485 <> 485/TTL <> TTL/USB <> PC , um hiper terminal (termite) em cada PC , e comunicão perfeita até 115200, aos 230k, num dos lados apareciam caracteres adicionais no fim de cada texto que escrevia.
Como julgo que a comunicção com EDP-box seja a 9600 (mais favoravel em termos de erros), não devo ter problemas. No fundo até testei 60m de cabo, pois testei tudo apartir de dentro de casa, fiz um vai por um par e volta por outro do mesmo cabo.
Agora é esperar pela disponibilização da porta HAN e ver se dá , se falhar de certeza que não será falha no cabo ou conversores.(editado)
1 Curtiu
As duas portas são funcionais, quer parecer que existem duas, para podermos fazer “daisy chain” no caso de haver mais contadores a integrar no bus RS485, o protocolo Modbus permite ter varios #endereços no mesmo bus.
Teste feito (Ladis+Gyr modelo ZCXe110CR…) e a funcionar + ou- , pk + ou - , acontece algo estranho, se tiver wemos alimentado por fonte alimentação telemovel , só actualiza um ou outro valor e leva muitooo tempo a aparecer o 1º valor , se ligar a power bank actualiza mais valores, mas com frequencia muito baixa , mais de 30/40seg, mudei o cabo de alimentção ao wemos , melhorou um pouco a frequencia de actualização , ligado ao USB do PC dá ideia que trabalha ainda melhor , a actualização (por ex. dos Amperes) nunca foi menor de 20~25 seg.
OPTIMIZAÇÃO SCRIPT
Para actualizar todos os dados constantes no script original do tutorial do Redalert, o script de 5 em 5 segundos faz pedidos de leitura de registos, como são 9 pedidos o “pool” leva cerca de 45 seg, o quer dizer que cada valor é actualizado a cada 45seg.
No sentido de encurtar esse tempo, deixo um script adaptado, que para obter as mesmas grandezas se propoe fazer o pool em 5 pedidos, ou seja uma actualização de 25 segundos.
Pode-se ainda reduzir o tempo em que são feitos os pedidos, como não testei, não tenho a certeza se não vamos criar “dump” no Equipamento Medição Inteligente (EMI) e este deixar de responder aos pedidos.
O valor é o “50” que está na string de pedido modbus, se por exemplo colocarmos “20” os pedidos vão sair de 2 em 2 seg , passando o pool de actualização dos valores para 10seg.
>D
>B
=>sensor53 r
>M 1
; ########## pedido modbus ###########
+1,14,m,1,9600,EB,5,50,r010400260003,r010400790007,0104006C,0104000B,01040084
; ########## descodificações tramas modbus ###########
1,=hGRANDEZAS INSTANTÂNEAS
1,010404UUuuxxxx@i2:10,Tensão,V,Voltage_P1,17
1,010404xxxxUUuu@i2:10,Corrente,A,Current_P1,17
1,010412UUuuUUuuxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx@i1:1,Potênciaativa,W,Power_P1,17
1,010412xxxxxxxxxxxxxxxxUUuuxxxxxxxxxxxxxxxxxxxx@i1:1000,Fator de potência,pu,PFactor_P1,19
1,010412xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxUUuuxxxx@i1:10,Frequência,Hz,Frequency_P1,17
1,=h
1,=hTOTALIZADORES DE ENERGIA
1,01040cUUuuUUuuxxxxxxxxxxxxxxxxxxxx@i0:1000,Vazio (1),kWh,Energy_P1_R1,17
1,01040cxxxxxxxxUUuuUUuuxxxxxxxxxxxx@i0:1000,Ponta (2),kWh,Energy_P1_R2,17
1,01040cxxxxxxxxxxxxxxxxUUuuUUuuxxxx@i0:1000,Cheia (3),kWh,Energy_P1_R3,17
1,=h
1,=hESTADOS
1,010406uuxxxxxxxx@i3:1,Tarifa,,Tariff_P1,16
1,010406uuxxxxxxxx@i4:1,DCP,,DCP_P1,16
#
Quanto aos ZIV, algumas ideias para brain storm:
- Sendo equipamentos normalizados pode não fazer muito sentido , mas cá vai , fazendo um pouco analogia com diagnostico auto/moto e com leitura de centralinas mesmo dentro de cada marca (caso concreto das motos Honda) cada modelo tem uma forma de “acordar” a centralina e pedir dados, depois os dados (por ex, as r.p.m. e os km/h) não estão sempre no mesmo registo da centralina de cada modelo.
- Mais um ideia , qd a EDP for testar os ZIV, se levar aparelhos para teste de comunicação, tentar “escutar” e “gravar” o RS485 “grimpando” com um conversor 485/USB ou TTL e um PC com um soft hiperterminal ou equivalente, por exemplo Hterm
http://der-hammer.info/pages/terminal.html
1 Curtiu
Ainda estás na fase de descoberta (e divertida) xD
Já só uso raw. Mas ficas com uns comboios no decoding.
Sem raw pede sempre dois registers.
7 tramas…
O minimo recomendado pela EDP (pdfs) é 1s (10)
b)
c)
d)
Existe o “metodo direto”.
Deverá haver algum programa para windows para enviar os tramas
PC - usb ttl rs485 - HAN
1 Curtiu
@nikito7 De facto com o raw é util pode-se pedir ‘montes’ de registos (teoricamente acho que 256 registos) .
Consegues ajudar em algumas duvidas:
-
A) - só consigo fazer decoding com pedidos maximos de 10 registos, isto é uma limitação absoluta ou dá para aumentar o nº de decodings?
-
B) - há hipotese de criar duas ou mais frequencias de actualização , e.g.: grandezas instantaneas como Volts, Amperes, potencia de 3 seg , totalizadores de 30 seg , outras medidas 60seg.
-
C) - A limitação do decoding tem a haver com numero de variaveis do firmware compilado ?
-
D) - Sabes se o firmware complilado do tutorial permite uso de subrotinas?
ZIV´s - não há novidades? porque será que a malta que os tem não consegue comunicar com eles, portas avariadas ?
Há malta que vai receber visita de tecnicos EDP para validar funcionamento da porta, sabes como fazem isso ? Caso a porta esteja operacional tem que conseguir comunicar certo?
Inicialmente era 11. Usa a ultima. Ou o tiago enganou-se
Só para o mqtt.
…Power_P1,17 – imediato, 1 decimal
…Power_P1,1 – teleperiod, 1 decimal
teleperiod 300s
decimal + 16 = publicar imediatamente
Originalmente os ZiV nao tem 5V, logo a edp teve de inventar, suponho.
Qual seria a vantagem de ter algum código específico só para os ZIV…
No tasmota, site, há meters que precisam inicialmente baudrate 300, para acordarem
Provavelmente não.
E o meu pouco mais tem
#define SML_MAX_VARS 40
#define SML_REPLACE_VARS
#define USE_SCRIPT_GLOBVARS
hxxps://github.com/nikito7/HA_EDP_Box_Trifasico/blob/master/dev/tasmota_920_b1.zip
#define SML_MAX_VARS 40
#define SML_REPLACE_VARS
#define USE_SCRIPT_GLOBVARS
#define USE_SCRIPT_SUB_COMMAND
#define USE_SML_SCRIPT_CMD
Vou testar , estou interessado em conseguir decoding de mais de 10 registos seguidos, no sentido de reduzir o nº de pedidos no polling, se for possivel para 2 e por consequencia o tempo de actualização, sem estar a mexer muito nos 5 seg. O wemos tem estado a pedir em 3seg. e com 5 pedidos, estou com cerca de 15seg de pool.
O caso mais desfaforavel seriam 30 registos (0x000B ~ 0x0028 ) o outro conjunto teria 25 (0x006C ~ 0x0084 )
Nas gamas de registos que pretendo não está a responder ao nº de registos que solictito, ou há alguma limitação algures , ou estou a fazer alguma coisa mal, acho que não, se no exemplo vires algo mal p.e.f. corrige-me .
ex: para 30 registos na gama (0x000B ~ 0x0028 )
+1,14,m,1,9600,EB,5,30,r0104000B001E
[r raw][add01] [type04] [registo inicial 000B] [nº de registos 001E(30 em hex)]
Se der erro de checksum, invalida tudo.
E provavelmente os registos tem de existir nessa sequência.
Não compensa com o número de xxxxx que vais usar nos decoders.
E… na realidade so interessa o 20 (2 segundos)
Isso está em loop/serie. Um trama de cada vez infinitamente.
Ao pedir 30 registos, provavelmente massacras mais a edpbox
edit:
a implementação do modbus ainda não é uniforme nos contadores.
O tiago teve de inventar para obter o powerfactor (salvoerro)
No meu sagemcom tem funcionado tudo como esperado
edit:
E o protocolo mudou de 00 para 01. Pdf 2020.
Mas não afecta os registers antigos. Pdf 2017.
Sem updates de firmware nada muda nos contadores.
edit:
A sml_var so limita o número de decoders
Os registos existem na sequencia, pelo menos ordenei tudo num xls e parece que está em sequencia.
Testando com simulador de modbus em vez do contador , recebo n registos sem problemas, de facto deve ser qualquer coisa no contador a limitar o nº , ou como pelo meio há registo com diversos formatos (single, unsigned , double, hour, array…etc) dá raia.
.
o powerfactor está em
Instantaneous Values 123 0x007B Instantaneous Power factor {3,{1.0.13.7.0.255},2} Long unsigned - -3
O teu firm , não dá por OTA, vou ter de ir desmontar a “cena” toda , isto já funciona razoavel é mesmo só paranoia de optimizar e para testar o “long” decoding.
Os meus tem todos menos de 500kB
Mas a primeira vez so por usb
Vês o free space
Edit:
Não dá uso aos 4MB
Removi quase tudo para ser possível OTA
Já foi via USB tasmotizer, resultado recebe o pedido mas tb falha ao 11º decoding
16:25:52 MQT: stat/edp_box2/RESULT = {"Time":"2020-12-28T16:25:52","SML":{"CMD":"dump: 1"}}
16:25:56 : 01 04 1e 09 32 00 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
16:25:57 : 00 00 00 aa 17
+1,14,m,1,9600,EB,5,70,r0104006C000B
1,01041eUUuuxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx@i0:1,Teste,T1,Test,17
Isso só vai fazer decode do primeiro
Não precisas de qualquer x antes do @
Não sei se isso lida bem com break lines.
aa 17 checksum?
Será tudo UUuu?
Tens de fazer as 11 linhas
UUuu
xxxx UUuu
xxxx xxxx UUuu
…
b) edit
Isso esta a devolver 15 UUuu
Também é so zeros. Sem info.
c) edit
1e = byte count. Decimal 30. Bate certo
Se pedir 10 registos funciona bem o decode (não ligues aos textos nem aos nomes não tem a haver com o 1º registo que é a tensão.)
Sabes com certeza que o nº de “xxx” tem de coincidir com o tipo de registos
- Long unsigned (tenho 7 no pedido de 10 ou 11 registos )- xxxx se quiseres ignorar ou UUuu para descodificar
- Double long unsigned (3 no pedido de 10 e 4 no pedido de 11 registo ) - xxxxxxxx …
… e por ai fora
+1,14,m,1,9600,EB,5,70,r0104006C000A
1,01041aUUuuxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx@i0:1,Potênciaativa,W1,Power_P1,17
Consola:
17:30:06 : 01 04 1a 09 0a 00 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 74 33
Ou algo muito simples está a escapar-me ou entao é uma limitação do decode, já procurei por limitação mas nao encontro nada