E… o api não atravessa subnets.
Tenho um contador “remoto” via 4G (wireguard).
Eventualmente posso fazer outro demo
Olá Nikito, obrigado pela informação, existe um user que vai pegar nesse trabalho e avançar com isso por carolice, depois postamos os resultados assim que for possível.
1 Curtiu
Mais um ZIV integrado! Wemos com tasmota + script alterado e partilhado por @Norberto_Martins. Muito obrigado!!!
1 Curtiu
Olá Miguel, gostei do total feito no script, dá para partilhar essa parte?
Obrigado
Boas @francisco.marques , vai ver no manual do @Encarnacao está lá tudo. 
Depois se poderes manda uma foto do modelo do teu Wemos, tive problemas com o meu.
3 Curtiram
Nao me tinha apercebido do excelente manual referido, obrigado pela indicação e ao @Encarnacao pela partilha.
O wemos que estou a usar adquiri em https://a.aliexpress.com/_mPO9Ulx , arranjo se quiseres.
Na fase de testes, apercebi-me que perdia a configuração, sempre q desligava a alimentacao.
Com o backup+restore resolvia, mas ficava 5* se grava-se a configuracao na memoria nao volatil, alguem sabe como no tasmota?
Isso só perde as configurações em certos casos
https://tasmota.github.io/docs/Device-Recovery/#fast-power-cycle-device-recovery
If you have a weak power grid or frequent power brownouts its best to disable this feature with
SetOption65 1immediately or you’ll end up with firmware default devices after a brownout event.
1 Curtiu
@nikito7 usando a integração do modbus do homeassistant como consegues contornar o problema do pedido 0x0079 uma vez que é uma Double long unsigned existe alguma forma de desmultiplicar o pedido ?
o HA parece ter um problema com pedidos de Double long unsigned
tentei também via NR com modbusTCP e parece queixar se do mesmo pedido 0x0079
Tem de ser seguidos, se falas do esphome.
0x0073
@nikito7 nao é usando o ESPhome mas sim a integracao modbus do HA tou a testar um esquipamento que nao tem esp
tens de abrir um issue no git do homeassistant
Nunca usei o metodo direto.
Já pensei fazer uma bridge serial-tcp com o tasmota
testei com esse componente mas deu me erros
Supostamente isso é bug do home assistant. Alguém tem de reportar
https://docs.python.org/3.5/library/struct.html
count: 1
data_type: custom
structure: "algo milagroso aqui"
No tasmota é UUuuUUuu que é 2x 32bits salvo erro, e não 64bits, salvo erro novamente xD
Talvez:
structure: ">LL"
ok testei modificando o componente official e removendo as tais linhas e funciona mas, nao funciona com adress 0x0079 mas sim com address: 38 enquanto no componente official com address: 38 da o tal erro Structure size (4 bytes) mismatch registers count (1 words)
Usa count 2
4 bytes, 2 words
[ (AA BB) (CC DD) ]
38 é o index
38 0x0026 Rate 1 contract 1 active energy (+A)
Outra nota
Às vezes é preciso pedir 2 registers, mesmo que só se use 1.
Pelo menos no tasmota
A tarifa e o dcp.
Sem RAW pede sempre 2 por funciona naturalmente.
Com raw tem de se pedir 2. r01xxxxx0002
Já podem criar uma alternativa ao EoT 
em relação ao modbus integração do HA simplesmente nada funciona hehe
o problema é que da parte do HA em termos the logica esta tudo ok pedes 1 byte recebes 1 byte
o problema parece estar no lado da EDP, em que manda sempre mais do que tu pedes, nao to a ver eles querem fazer um fix a uma coisa que esta correta da parte deles ja reparas te que eles consideram uma Double long unsigned com 4 bytes quando na realidade sao 8 bytes
Não falando correctamente.
O que supostamente devia ser 64bits
São 32+32 ou dois registos em 1
( nao percebo nada disto, words dwords qwords…, é apenas um exemplo )
Isso tem debug? Os bytes?
Isso pode estar a fazer o pedido errado.
Nos esphome foi preciso corrigir isso…
Ao inicio também dava esse erro
Tasmota:
22:43:01.797 script: up 592729.00
22:43:02.795 > 01 04 00 26 00 01 d0 01
22:43:02.799 script: up 592730.00
22:43:03.043 : 01 04 04 00 1a b1 1c af da
22:43:03.797 script: up 592731.00
Está correto…
por exemplo para watts pedindo address: 121 ou address: 0x0079 da sempre erro, removendo o sanity check do componente modbus, funciona logo 
resumindo tudo o que seja Double long unsigned chapéu.
0x0073, 0x0075 etc…
Isso é bug do home assistant…
Ou aumenta o count e diminui o tipo
Continuando:
00 1a b1 1c
hex to decimal
001ab11c = 1749276 ok
Os nome corretos não faço ideia.
Volto a referir, no esphome “tivemos” de corrigir isso.
response size mismatch
Exemplo esphome
- id: ActPower
name: "${dev} Active Power"
address: 0x0073
offset: 24
modbus_functioncode: "read_input_registers"
value_type: U_DWORD
accuracy_decimals: 0
device_class: power
unit_of_measurement: "W"
- id: ActPowExp
name: "${dev} Active Power Export"
address: 0x0073
offset: 28
modbus_functioncode: "read_input_registers"
value_type: U_DWORD
accuracy_decimals: 0
device_class: power
unit_of_measurement: "W"
internal: true # disable sensor
# type changes
- id: PowFac
name: "${dev} Power Factor"
address: 0x0073
offset: 32
unit_of_measurement: "pu"
modbus_functioncode: "read_input_registers"
value_type: U_WORD
accuracy_decimals: 3
filters:
- multiply: 0.001
device_class: power_factor
- id: PowFacL1
name: "${dev} Power Factor L1"
address: 0x0073
offset: 34
unit_of_measurement: "pu"
modbus_functioncode: "read_input_registers"
value_type: U_WORD
accuracy_decimals: 3
filters:
- multiply: 0.001
device_class: power_factor
U_WORD anda 2 bytes; tasmota UUuu
U_DWORD anda 4 bytes; tasmota UUuuUUuu
U_QWORD nao é usado
Termos correctos!
( no esphome também foi uma confusão brutal. Porque o nome atribuido pela EDP está errado)
No esphome está tudo ok
Isso é bug no pedido!!
1 Curtiu
No python é:
short 2 bytes >H
long 4 bytes >L
Acho que nem há suporte no código fonte para o long
E ainda há dois tipos 32bits
2 registers adjacentes
- 0x1234
- 0x5678
Apenas 1 register, que é o caso da edpbox
- 0x12345678 (4 bytes) uint32
| Python | edpbox
Uint | short | long
Uint32 | long | double long
Issue aberto
Coloquem detalhes
Caso aceitem o issue, alguém depois tem de testar…
Eu não uso…