Integração tasmota …
Desde já obrigado pela partilha da informação sobre os controladores de leitura da porta HAN dos SmartMeters da e-redes.
Após algum tempo a tentar perceber como “montar” um ESP/HAN consegui colocar a funcionar segundo os principios do tutorial do Tiago.
Consegui colocar a funcionar o script trifásico “basico” do nikito7 do tutorial do Tiago ao Janz B2801 GPRS 2017 com modem GSM ligado.
No entanto, resolvi testar o teu script mais avançado (pois o primeiro não tem energia exportada) e após colocar novos firmares noutro ESP8266 wemos mini D1, não consegui comunicar com o Janz. Mais tarde, percebi que o tutorial do Tiago no esquema de ligações usa softserial. Como tinha tentado também já o script avancado “EB3” do nikito7, reajustei o script para ir buscar as ligações RX/TX aos pinos do softserial. Consegui comunicar com o Janz, mas enquanto que com o script trifásico basico o ESP funcionou durante 4 dias sem problema (ESP8266 → TX/RX softserial), no script do nikito7 o ESP está instavel nas comunicações, embora conseguise ter leituras durante 3 horas em continuo… Para eliminar a instabilidade, decidi passar para o porta 3 RX e porta 1 TX (hardserial). Após alteração fisica e nos scripts “+1,3,m,0,9600,EB,1,…”, quando ligo o cabo rj12 ao Janz, o RX pisca quase em continuo, demonstrando saturação na comunicação. Verifiquei as ligações segundo o tutorial TTL-485 RX <-> RX GPIO3 ESP8266 mini D1 e TTL-485 TX <-> TX GPIO1 ESP8266 mini D1. Segundo o teu comentário, é necessário retirar o resistor junto ao RX. Será este o problema ? Existe algum feedback e uma solução ? Obrigado.
Alguns nodemcu ou wemos não gostam do gpio1 e gpio3 na han.
Led sempre aceso sem a HAN ligada poderá ser esse pull up.
Os novos clones ttl-rs485 não são grande coisa…
Em certos casos é preciso alimentar ttl-rs485 com 5V.
O janz precisa de watchdog.
Pelo menos 4x por dia o Janz bloqueia a porta e é preciso pausar a comunicação 35s.
Para os scripts antigos é usar a V1:
https://u.easyhan.pt/v2/tasmota-4M-v1.bin.gz
Actualmente no easyhan só uso o chip max3485 sem mais nada.
E o pin dir.
+1,3,mN1,1,9600,EB1,1(16),15,r010400010001…
Muito obrigado pelo feedback.
Sim, tens razão sobre o GPIO1/3. Também estive a pesquisar e alguns nodemcu e wemos partilham o hardware serial, criando conflitos…
Em relação ao LED, este apenas fica acesso a piscar rapidamente com intensidade baixa só quando é ligado fisicamente o cabo rj12 há porta do HAN (cabo configurados 1-G 3-A+ 5-B segundo esquema do tutorial do Tiago). Quando desligo o cabo, o RX desliga (o que é normal). Tenho uma ficha fêmea e uso um chicote rj12 fabricado de compra (não cravado manualmente) para evitar ruido.
A ligação entre o ttl-rs485 e wemos é mesmo TX-TX e RX-RX ou tem de ser invertido para TX-RX / RX-TX ?
O TTL-RS485 está a ser alimentado a 3.3v, via wemos, mas posso colocar um regulador 5V->3.3V para estabilizar ou mesmo ligar a 5V.
Actualmente a alimentação é via USB do wemos, porque estou ainda em fase “experimental”. A alimentação irá ser realizada por uma fonte Hi-link de 5V ou 3.3V, pois garante uma alimentação mais estável.
Obrigado pela informação do Janz. De facto estou agora a usar a tasmota-4m-v1.bin
Como estou a fazer tudo do zero, posso colocar o firmware que achares mais adequado ao Janz. Agradeço muito o teu feedback.
Na tua configuração indicas o tx enable (16), GPIO16/WAKE que deve ser devido a usares apenas o max3485, correcto ?
Também li que é possivel usar o swap.serial para ser uma solução com o ESP, mas não é suportada pelo Tasmota.
Uma opinião. Não será melhor usar um ESP32, pois este tem 3 portas série por hardware (ao contrário de 1 do ESP8266 partilhada)? Existe algum firmware tasmota e script para o ESP32 que possa ser aplicado à solução ?
Em ultimo caso arranco a resistência que liga o RX ao controlador série do wemos…
Os meus conhecimentos são básicos e agradeço desde já o vosso feedback. Obrigado.
Podes experimentar gpio 16 e 17.
Ou outros se desactivares o plugin interno.
Obrigado nikito7.
Pelo que percebo da tua resposta, esta é a solução para usar o ESP32, com a UART2-RX(GPIO16) e UART2-TX(GPIO17), que está por defeito no tasmota32.bin.
Vou tentar e dar feedback. Obrigado.
Se atribuires TCP tx a um pin sem uso, o meu plugin fica desliga. Podes depois usar o script.txt e qualquer pin.
Firmware tasmota32 sem plugin incluido, não tenho.
Plugin = V2, C++ modbus.
V1 = modbus no script.
Desde já, muito obrigado pela ajuda.
Coloquei da /v2/32/ o firmware tasmota32.factory.bin no ESP32 DevKit 30pin que tenho. Após isso, fiz o upgrade do firmware tasmota32.bin. Considero que estes são os correctos, pois os outros que estão no teu github são para o ESP32-S e ESP32-C.
No [configure others] mantive: {“NAME”:“ESP32-DevKit”,“GPIO”:[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,1,1,1,0,1,1,1,0,0,0,0,1,1,1,1,1,0,0,1],“FLAG”:0,“BASE”:1}
[Configure module] Coloquei GPIO1 → TCP Tx e GPIO2-> TCP Rx. O script ficou desactivado (sem dados electricos no menu principal e informa script não activo).
Apaguei no file manager os ficheiros correspondentes ao EB1 e mantive os do EB3 (para o sistema trifasico), realizando o rename do script-E3 para script.
[Configure module] Coloquei GPIO16 → Serial RX (corresponde ao U2_RXD) e no GPIO17 → Serial Tx (corresponde ao U2_TXD).
Atribuir ao GPIO1->none e GPIO3->none, ficando apenas a configuração para os pinos 16 e 17 (quando mantenho atribuido algo ao GPIO1 e GPIO3, não aparece indicações de energia, que considero script parado).
Não liguei o cabo HAN nem configurei o MQTT para apontar para o meu servidor (estou apenas em testes).
Restart → Agora identifico actividade nos leds do TTL-RS485, ligado a porta 16-RX <-> TTL RX e 17<->TTL TX.
Se não atribuir o GPIO16->serial RX / GPIO17-> serial RX, não tenho actividade nos leds do TTL.
Estranho, o led que pisca é o RX…
No entanto o script indica as configurações monofásicas iniciais… Mas o script é do EB3, ou seja trifásico… Acredito que continua a ler no codigo o teu nativo e não editado…
A actividade dos leds do TTL vai-se repetindo após alguns segundos.
Inverti a posição dos pinos da porta serie2 RX <-> TX TTL e serie2 TX <-> RX TTL, o led que pisca é o do TX (que me parece mais correcto…).
Envio as informações da configuração do ESP32… não acredito que esteja OK, pois não aparece as infdrmações correctas…
O facto de atribuirmos os pinos no tasmota ele usa mesmo o hardware serial e não uma emulação por softwareserial ?
Configuração actual:
ESP32-DevKit
Tasmota
NTP 2024-11-19 23:11:15 Heap 106.7 kB
Init 100 % TelePeriod 10 Version 20043
Wifi WifiManager Power 15 dBm Topic edpbox99
EB3 Consumo Net. 0.000 kWh
EB3 Excedente Net. 0.000 kWh
[LP-0000-00.csv] [Charts JS]
Easy HAN ® V2 7.273
CPU Freq 160 MHz
MB Status Error 23s
MB Index 0
MB Serial 8N99
MB Type EB99 / 99
MB Latency 0 ms
MB Timeout 1500 ms
MB Delay Wait 1000 ms
MB Delay Error 35000 ms
Clock 00:00:00
Voltage L1 0.0 V
Current L1 0.0 A
Power Import 0 W
Power Export 0 W
Power Factor 0.000 φ
Frequency 0.0 Hz
Energy T1 Vazio 0.000 kWh
Energy T2 Ponta 0.000 kWh
Energy T3 Cheias 0.000 kWh
Energy Total Import 0.000 kWh
Energy Total Export 0.000 kWh
Diagrama de Carga Load Profile
LP 1 Date 0000-00-00
LP 1 Time 00:00 Z
LP 2 AMR 0
IDs: 0 0 0 0 0 0 0 0
Realtime Netmetering (qs) 0.000 kWh
Contract T1 0.00 kVA
Contract T4 0.00 kVA
Tariff 0
EMI Manufacturer Year 0
EMI ? ??? ??? 0
EMI Firmware:
- Core
- App
- Com
…
Module parameters
Module type (ESP32-DevKit)
ESP32-DevKit (1)
IO GPIO0 None
TX GPIO1 None
IO GPIO2 None
RX GPIO3 None
IO GPIO4 None
IO GPIO5 None
FL GPIO9 None
FL GPIO10 None
IO GPIO12 None
IO GPIO13 None
IO GPIO14 None
IO GPIO15 None
IO GPIO16 Serial Rx
IO GPIO17 Serial Tx
IO GPIO18 None
…
edit script
Script enable
D 48
ver=20043
EBx=“EB3”
C=“Net.”
date=""
time=""
clk=""
old=""
wfc=""
wfp=0
cnt=0
wtd=0
hh=0
mm=0
…
Manage File system
Size 0.320 MB - Free 0.248 MB
[Partition_Manager.tapp ]
[charts.html ]
[charts.min.js ]
[discovery-EB3.txt ]
[script.txt ]
[voltage.html ]
[voltage.min.js ]
[vt-0d.csv ]
Obrigado.
O plugin usa o Serial1.
Não podes usar mais nada com serial.
Quando desactivas o plugin só usas um pin.
Se usares dois vai entrar em conflito.
Só podes usar o 16/17 com o plugin
Obrigado pela paciência, mas desculpa porquê é dificil perceber alguns conceitos do EasyHAN e do Tasmota quando de vem do Arduino…
Ok, apenas indiquei no GPIO1 e GPIO3 os TCP Tx/RX no module parameters.
O script ficou desactivado.
Depois coloquei o script V1 (modbus no script) e indiquei as portas RX e TX:
+1,16,mN1,1,9600,EB3,17,15,r010400010001,r0104 …
No restart, o ESP32 parece uma arvore de natal 
mas o mais importante é que o TX pisca regularmente e o RX é reconhecido no boot (atenção que ainda não liguei o cabo a porta HAN).
Também no main menu agora aparece correctamente as variáveis do EB3 trifásico.
Ainda não testei fisicamente a ligação, mas se achares que algo está errado, por favor agradeço o teu feedback.
Mais uma vez obrigado
ESP32-DevKit
Tasmota
| Program Version | 14.3.0 (tasmota32) |
|---|---|
| Build Date & Time | 2024-11-16T21:40:37 |
| Core/SDK Version | 3_1_0/5.3.1.240924 |
| Uptime | 0T00:10:14 |
| Flash Write Count | 133 |
| Boot Count | 43 |
| Restart Reason | Software reset digital core |
| ESP Chip Id | 4578916 (ESP32-D0WDQ6 v1.0) |
|---|---|
| Flash Chip Id | 0x164020 (DIO) |
| Flash Size | 4096 KB |
| Program Flash Size | 4096 KB |
| Program Size | 2078 KB |
| Free Program Space | 801 KB |
| Free Memory | 98.3 KB (frag. 7%) |
| Partition safeboot | 832 KB (used 96%) |
| Partition app0* | 2880 KB (used 72%) |
| Partition fs | 320 KB |
Para desactivar basta usar um pin.
Ao usares os dois activas completamente a bridge.
Mas, nesse aspecto já é domínio do Tasmota.
O motivo de alguns Wemos e Nodemcu não funcionarem com o pin 1 e 3.
É a existência de um pullup forte.
Ao fim destes anos, certas coisas fazem sentido agora.
Tradução adicionada como cortesia, porque sei que estou num fórum que não é em inglês:
Olá a todos,
Peço desculpa por usar o inglês, mas mudámo-nos recentemente para português e ainda estou a aprender a língua.
Achei este tópico muito perspicaz e tem muitas semelhanças com a forma como costumávamos extrair dados modbus de um inversor SunSynk na minha casa anterior.
Neste repositório do github está o código mais recente que usei para esse fim e pode ser facilmente adaptado para ler os registos corretos para as caixas EDP e expô-los como entidades em HA. Sinta-se à vontade para pegar em qualquer parte do código que queira reutilizar.
Eu costumava executar isso em um ESP32 com um chapéu modbus instalado e ele facilmente sondava dados a cada segundo, mas eu o mantive em intervalos de 5 segundos para facilitar o meu HA DB.
A configuração era semelhante à deste utilizador:
(imagem no próximo post)
Agora: Devido à caixa EDP estar longe da minha casa e não haver disponibilidade de um tubo para passar o cabo cat6, decidi instalar um Shelly Pro 3EM na placa principal, para poder ver/calcular a maior parte da informação disponível na caixa EDP. Terei todo o gosto em partilhar a forma como o fiz, mas é um trabalho em curso. Colocarei mais imagens nos próximos posts, devido às limitações das imagens incorporadas para os novos utilizadores
Parece que existe um conhecimento técnico aprofundado por parte das pessoas neste tópico, pelo que gostaria de colocar aqui uma questão simples.
O contador da EDP apresenta um valor total consumido para Vazio, Cheias e Ponta (1.8.1, 1.8.2 e 1.8.3) apesar de eu estar no tarifário “simples”.
Gostaria de saber quando é que o contador muda de cada tarifa para a seguinte, para poder ajustar a leitura total do contador em conformidade. O contador segue o horário abaixo indicado, incorporado na caixa EDP, ou existe outro horário programado na caixa Landis?
Além disso, que datas são utilizadas para determinar as tarifas de verão ou de inverno?
Hi All,
Apologies for using English, but we just recently moved to Portugual and I am still learning the language.
I found this thread very insightful and it has a lot of similarities on how we used to pull modbus data from a SunSynk inverter at my previous house.
In this github repo is the latest code I used for that purpose and it can very easily be adapted to read the correct registers for the EDP boxes and expose it as entities in HA. Feel free to take any bits of code you may want to reuse.
I used to run this on an ESP32 with a modbus hat installed and it easily polled data every second, but I kept it at 5 second intervals to go easier on my HA DB.
It looked similar to this user’s setup:
(image in next post)
Now: Due to the EDP box being far from my house and no availability of a pipe to run the cat6 cable in, I have settled on installing a Shelly Pro 3EM in the main board, so I can see/calculate the majority of information available in the EDP box. I am happy to share how I have done this, it’s a work in progress though. will post more images in next posts, due to embedded image limitations for new users
It seems there is a thorough technical understanding from the people on this thread, so I would like to pose a simple question here.
The EDP meter shows a total consumed value for Vazio, Cheias and Ponta (1.8.1, 1.8.2 and 1.8.3) even though I am on the “simples” tariff.
I would like to know when the meter switches from each tariff to the next so I can adjust my total meter reading accordingly. Does it follow the below timetable built into the EDP box, or is there another schedule programmed inside the Landis box?
Also, what dates are used to determine the summer or winter tariffs?
Follow up from previous post - My sunsynk modbus poller on ESPHome looked similar to this user’s setup:
Hello @Jacques_Aucamp
Can you share with us how you added the sub totals for “Today”, “This week”, “This month”, “This Quarter”, “This year”…, thanks.
Also, your “Setup” sensor and yaml would be nice, if you can share.
Thanks.
Olá a todos
Estive a ajudar um colega a montar um Elfin conectado por modbus com o home assistant (customer component).
Consigo ler os valores corretamente, contudo alguns deles como por exemplo o consumo em amps, fica a transitar entre o valor lido e “unavailable”.
Entretanto também me apercebi que o valor da tarifa (address 11) tem um ouput que difere do que tenho em casa.
Pode isto estar a acontecer por necessitar de ter configurações diferentes para o modelo do contador dele?
- name: ERedes_box_contador_energia
type: tcp
host: <IP>
port: 9502
delay: 1
timeout: 4
retries: 5
#retry_on_empty: true
message_wait_milliseconds: 200
- name: "ERedes Box Current" # 6D
slave: 01
address: 109
input_type: input
#count: 1
data_type: uint16
precision: 1
scale: 0.1
unit_of_measurement: A
device_class: current
scan_interval: 15
Configs do Elfin:
No fundo o meu problema é muito semelhante ao reportado pelo @Cesar_Araujo
Houve alguma solução?
Obrigado!
Olá, eu acabei por mudar para o easyhan, os contadores da e-redes não usam o protocolo standard e por isso temos que fazer maroscas para obter todos os registos. Cansei de fazer patch ao modbus do home assistant sempre que tinha um update. Easyhan, foi directo e simples. E alem disso tenho toda a informação possível.
O mestre nikito vai fazendo os updates e domina os “glitches” dos contadores para ter sempre leituras, mesmo nos casos onde tem o modem da e-redes.
Espero ter ajudado.
Obrigado pelo feedback @Cesar_Araujo
@nikito7 Sabe se existe alguma solução mantendo o Elfin?
Obrigado pela vossa disponibilidade
Actualmente desisti do Elfin. Principalmente do componente modbus do Home Assistant.
Só os Watts e kWh tem problemas.
A corrente deveria funcionar.
A maioria dos contadores são 8N1, Stop bits 1.
Excepto Landis e Ziv, desatualizados ou antigos.
O problema é pior com usb rs485.
Com o Elfin deveria funcionar com o custom_component.
Eu não sigo isso.
Os 32bits tem de ser com o data_type: custom
No easyhan bridge funciona:
Se o pedido modbus falhar fica unavailable
Sem custom:
Logger: homeassistant.config
Source: config.py:942
First occurred: 21:47:19 (1 occurrences)
Last logged: 21:47:19
Invalid config for ‘modbus’ at pkg/active/demo.yaml, line 40: EB2 38 uint32 c1: Size of structure is 4 bytes but count: 1 is 2 bytes ‘modbus->0->sensors->2’, got {‘name’: ‘EB2 38 uint32 c1’, ‘unique_id’: ‘eb2_demo38_c1’, ‘slave’: 1, ‘address’: 38, ‘input_type’: ‘input’, ‘data_type’: ‘custom’, ‘count’: 1, ‘structure’: ‘>L’, ‘precision’: 2, ‘scale’: 0.001, ‘unit_of_measurement’: ‘kWh’, ‘device_class’: ‘energy’, ‘state_class’: ‘total_increasing’}, please check the docs at https://www.home-assistant.io/integrations/modbus Invalid config for ‘modbus’ at pkg/active/demo.yaml, line 67: EB2 22+23 uint32 c2: Size of structure is 8 bytes but count: 2 is 4 bytes ‘modbus->0->sensors->4’, got {‘name’: ‘EB2 22+23 uint32 c2’, ‘unique_id’: ‘eb2_demo22_c2’, ‘slave’: 1, ‘address’: 22, ‘input_type’: ‘input’, ‘count’: 2, ‘data_type’: ‘custom’, ‘structure’: ‘>2L’, ‘scale’: 0.001, ‘precision’: 2}, please check the docs at https://www.home-assistant.io/integrations/modbus Invalid config for ‘modbus’ at pkg/active/demo.yaml, line 80: EB2 clock demo: Size of structure is 12 bytes but count: 1 is 2 bytes ‘modbus->0->sensors->5’, got {‘name’: ‘EB2 clock demo’, ‘unique_id’: ‘eb2_clock_demo’, ‘slave’: 1, ‘address’: 1, ‘input_type’: ‘input’, ‘count’: 1, ‘data_type’: ‘custom’, ‘structure’: ‘>H7BhB’}, please check the docs at https://www.home-assistant.io/integrations/modbus
O custom altera o único codigo que me aceitaram.
Sem isso nem o custom era possível.
Além que o custom não é a forma correta…