Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[thuisbatterij]

HIer de afbeelding met uitleg van pins op de modubs aansluiting

[Broodro0ster]

tdolder schreef op donderdag 4 september 2025 @ 08:21:
Meer mensen last van een broken Marstek HACS integratie van @[RNMC] Viper na update HomeAssistant naar 2025.9?

De EW11's geven aan dat ze connected zijn met HA ip,

HA Log:
Logger: custom_components.marstek_modbus.helpers.modbus_client
Bron: custom_components/marstek_modbus/helpers/modbus_client.py:126
integratie: Marstek Venus Modbus (documentatie)
Eerst voorgekomen: 07:04:36 (12 gebeurtenissen)
Laatst gelogd: 07:59:43

Modbus client not connected, attempting reconnect before register 33008 (0x80F0)
Modbus client not connected, attempting reconnect before register 35100 (0x891C)
Modbus client not connected, attempting reconnect before register 42020 (0xA424)
Modbus client not connected, attempting reconnect before register 36100 (0x8D04)
Modbus client not connected, attempting reconnect before register 31000 (0x7918)

Bedankt om ons te waarschuwen.

De Huawei modbus integratie heeft ook een fix gekregen voor HA 2025.9 die je niet mag updaten als je nog op 2025.8 zit. Dus volgens mij is er iets gewijzigd binnen HA dat te maken heeft met modbus.
Hopelijk volgt er snel een update.

[pascallj]

thuisbatterij schreef op donderdag 4 september 2025 @ 13:25:
HIer de afbeelding met uitleg van pins op de modubs aansluiting

[Afbeelding]

Dit komt inderdaad overeen met de metingen van @FirefoxNL. Ik was nog niet helemaal uit die puzzel, maar de puzzel wordt een stuk makkelijker als je de mogelijke antwoorden al weet. Bedankt!

Dus resumé (er staan nog al wat diagrammen in het schema):

Pin 1 - RS485-B
Pin 2 - RS485-A
Pin 4-5 - GND
Pin 7-8 - +5V (voeding)

[FirefoxNL]

pascallj schreef op donderdag 4 september 2025 @ 13:34:
[...]
Dit komt inderdaad overeen met de metingen van @FirefoxNL. Ik was nog niet helemaal uit die puzzel, maar de puzzel wordt een stuk makkelijker als je de mogelijke antwoorden al weet. Bedankt!

Dus resumé (er staan nog al wat diagrammen in het schema):

Pin 1 - RS485-B
Pin 2 - RS485-A
Pin 4-5 - GND
Pin 7-8 - +5V (voeding)

Kijk, top! @pascallj en @thuisbatterij bedankt!
Ik ga vanavond mijn Elfin aansluiten en zal hier nog even wat foto's posten, kan dat misschien in de start post als instructie. Dan test ik ook gelijk of de registers nog hetzelfde zijn.

[dannyro]

AUijtdehaag schreef op donderdag 4 september 2025 @ 12:13:
@dannyro
Ik moet soms na een HA update, de addons hamerelay en hm2mqtt handmatig even herstarten
Ik log er mijn batterij spanningen mee naar influxdb, dat zou jammer zijn als ik die moet missen.

Hoe kom je aan V154, die zie ik niet in de app (V153 is de laatste volgens de app)

Ik had spontaan een update gekregen voor de BMS V215 update. Toen heb ik wat moeilijkheden ondervonden met deze installatie, en had ik raad gevraagd via de feedback optie in de app. Maar ik kan daar toch niet afblijven, en na enkele pogingen op verschillende manieren werkte mijn Marstek terug zoals het hoorde. Dit heb ik ook direct aan Hame laten weten via de app. Enkele dagen later kreeg ik toch V154 aangeboden. Ik heb deze probleemloos geïnstalleerd. Ik zat op V151. Ik merk daar weinig tot geen verschillen in. Alleen de HameRelay niet meer werkt.

[[RNMC] Viper]

tdolder schreef op donderdag 4 september 2025 @ 08:21:
Meer mensen last van een broken Marstek HACS integratie van @[RNMC] Viper na update HomeAssistant naar 2025.9?

De EW11's geven aan dat ze connected zijn met HA ip,

HA Log:
Logger: custom_components.marstek_modbus.helpers.modbus_client
Bron: custom_components/marstek_modbus/helpers/modbus_client.py:126
integratie: Marstek Venus Modbus (documentatie)
Eerst voorgekomen: 07:04:36 (12 gebeurtenissen)
Laatst gelogd: 07:59:43

Modbus client not connected, attempting reconnect before register 33008 (0x80F0)
Modbus client not connected, attempting reconnect before register 35100 (0x891C)
Modbus client not connected, attempting reconnect before register 42020 (0xA424)
Modbus client not connected, attempting reconnect before register 36100 (0x8D04)
Modbus client not connected, attempting reconnect before register 31000 (0x7918)

Fix in nieuwe versie staat klaar 2025.9.1. Sinds versie 2025.9.0 zit er dynamic polling en background update, helaas door update van Home Assistant was er snel een fix nodig. Feedback is welkom.

[superduper1969]

TS aangepast:
- 4-9-2025 Modbus connector V3

[amvolleb]

[RNMC] Viper schreef op donderdag 4 september 2025 @ 17:34:
[...]

Fix in nieuwe versie staat klaar 2025.9.1. Sinds versie 2025.9.0 zit er dynamic polling en background update, helaas door update van Home Assistant was er snel een fix nodig. Feedback is welkom.

Bij mij werkt het weer met 2025.9.1
Dank je wel!

[pascallj]

[RNMC] Viper schreef op donderdag 4 september 2025 @ 17:34:
[...]

Fix in nieuwe versie staat klaar 2025.9.1. Sinds versie 2025.9.0 zit er dynamic polling en background update, helaas door update van Home Assistant was er snel een fix nodig. Feedback is welkom.

Wel heel verwarrend dat je HA versie nummers gebruikt voor jouw integratie. Ik dacht namelijk even dat je een officiële integratie had en de fix in HA 2025.9.1 zat. Maar HA 2025.9.1 is nog helemaal niet uit.

[Kammika]

Hoi,

wat een mooie zinvol draadje is dit op tweakers. Heb op basis daarvan mijn bestelling van Marstek+Elfin EW11+wat kabeltjes gedaan. Gisteren binnengekomen en vandaag draait het allemaal.

Wat ik alleen niet helemaal goed uit de documentatie haal is hoe ik de update snelheid wat omhoog krijg.

De SOC en Laad/Ontlaadsnelheid worden gelezen door EVCC. En daarvoor heb ik nodig dat die waardes eigenlijk max 5 seconden oud zijn. Maar de update snelheden van zowel de marstek_venus_battery_1_control.yaml als de marstek_venus_modbus integratie lijken veel hoger.

Kan ik dat op een manier instellen ergens?

[FirefoxNL]

Kammika schreef op donderdag 4 september 2025 @ 21:31:
Hoi,

wat een mooie zinvol draadje is dit op tweakers. Heb op basis daarvan mijn bestelling van Marstek+Elfin EW11+wat kabeltjes gedaan. Gisteren binnengekomen en vandaag draait het allemaal.

Wat ik alleen niet helemaal goed uit de documentatie haal is hoe ik de update snelheid wat omhoog krijg.

De SOC en Laad/Ontlaadsnelheid worden gelezen door EVCC. En daarvoor heb ik nodig dat die waardes eigenlijk max 5 seconden oud zijn. Maar de update snelheden van zowel de marstek_venus_battery_1_control.yaml als de marstek_venus_modbus integratie lijken veel hoger.

Kan ik dat op een manier instellen ergens?

Ik gebruik zelf de Elfin in combinatie met de yaml van WargamingPlayer. Je kan daarin de scan_interval aanpassen. Heb die zelf van 10 naar 5 seconden gezet, dat vond ik eerst snel genoeg. Sneller heb ik nog niet geprobeerd maar kan je even mee experimenteren of het dan nog stabiel blijft draaien.

[FirefoxNL]

FirefoxNL schreef op donderdag 4 september 2025 @ 14:11:
[...]
Ik ga vanavond mijn Elfin aansluiten en zal hier nog even wat foto's posten, kan dat misschien in de start post als instructie. Dan test ik ook gelijk of de registers nog hetzelfde zijn.

Helaas nog geen update. Ik krijg met het kabeltje waar ik gister mee gemeten heb gaat de Elfin nog niet aan. Ik heb nog een Elfin aan mijn V2 hangen en die doet het ook niet op dit kabeltje dus ik sluit niet uit dat ik een ader kapot gesneden/getrokken heb. Morgen even een andere UTP kabel opofferen.

[pascallj]

FirefoxNL schreef op donderdag 4 september 2025 @ 21:42:
[...]


Helaas nog geen update. Ik krijg met het kabeltje waar ik gister mee gemeten heb gaat de Elfin nog niet aan. Ik heb nog een Elfin aan mijn V2 hangen en die doet het ook niet op dit kabeltje dus ik sluit niet uit dat ik een ader kapot gesneden/getrokken heb. Morgen even een andere UTP kabel opofferen.

Dat is eenvoudig te meten door opnieuw te kijken of je spanningen hebt op de kabels. Je weet nu waar je moet zoeken.

Het kan ook zijn dat er niet genoeg vermogen vanuit de Marstek aanwezig is. Je kunt de Elfin ook even voeden op een andere manier en alleen RS485 A en B aansluiten.

[Kammika]

FirefoxNL schreef op donderdag 4 september 2025 @ 21:38:
[...]


Ik gebruik zelf de Elfin in combinatie met de yaml van WargamingPlayer. Je kan daarin de scan_interval aanpassen. Heb die zelf van 10 naar 5 seconden gezet, dat vond ik eerst snel genoeg. Sneller heb ik nog niet geprobeerd maar kan je even mee experimenteren of het dan nog stabiel blijft draaien.

[Afbeelding]

Dat had ik al geprobeerd. Maar dacht dat dat geen effect had. Ik ga het morgen nog eens proberen…! Tx!

[Kammika]

FirefoxNL schreef op donderdag 4 september 2025 @ 21:42:
[...]


Helaas nog geen update. Ik krijg met het kabeltje waar ik gister mee gemeten heb gaat de Elfin nog niet aan. Ik heb nog een Elfin aan mijn V2 hangen en die doet het ook niet op dit kabeltje dus ik sluit niet uit dat ik een ader kapot gesneden/getrokken heb. Morgen even een andere UTP kabel opofferen.

Ik had eerst exact hetzelfde issue. Toen eerst op een 0 en +5v van een breadboard aangesloten (met de a en b naar de Marstek), daarmee het bordje afgeconfigureerd. Toen ik daar de 0 en 5v terug deed naar de Marstek bleef het werken…

Waarom die het eerst niet gelijk op de
Marstek deed: geen idee: de kabels waren op exact dezelfde manier aangesloten…

[WargamingPlayer]

pascallj schreef op donderdag 4 september 2025 @ 19:03:
[...]


Wel heel verwarrend dat je HA versie nummers gebruikt voor jouw integratie. Ik dacht namelijk even dat je een officiële integratie had en de fix in HA 2025.9.1 zat. Maar HA 2025.9.1 is nog helemaal niet uit.

Ik gebruik ook de zelfde nummering. Jaartal van de fix, maand van de fix en het volgenummer.

[HiHaHors]

Volgens mij klopt de info van Marstek over de V3 RS485 pinout niet. Ik meet op pin 4&5 +5 Volt t.o.v. pin 7&8. Precies omgedraaid dus.

[pascallj]

HiHaHors schreef op vrijdag 5 september 2025 @ 07:24:
Volgens mij klopt de info van Marstek over de V3 RS485 pinout niet. Ik meet op pin 4&5 +5 Volt t.o.v. pin 7&8. Precies omgedraaid dus.

Ja je hebt gelijk! Sorry ik weet niet waar ik gisteren zat met m'n gedachten. Heb nogmaals de metingen van @FirefoxNL vergeleken en het is inderdaad andersom. Oeps! Ik hoop dat je PCB goede polariteit protectie heeft!

Qua potentiaal t.o.v. GND is het dan zo:

+5,47 V (+5V)
+5,35 V (RS485-B / U+)
+0,05 V (RS485-A / U-) (waarschijnlijk weggelaten in de meting vanwege 0-meting)
GND (GND)

Dus nieuwe resumé...:
Pin 1 - RS485-B
Pin 2 - RS485-A
Pin 4-5 - +5V (voeding)
Pin 7-8 - GND

offtopic:
Zo zie je dus maar weer dat we lui worden als we alle antwoorden zo op een presenteerblaadje krijgen...

[ Voor 7% gewijzigd door pascallj op 05-09-2025 08:47 ]

[PoltergeistBE]

Tweede Marstek is onderweg hier, extra Seriëel naar RS485 is nodig voor die uit te kunnen lezen gok ik?

[pascallj]

PoltergeistBE schreef op vrijdag 5 september 2025 @ 09:22:
Tweede Marstek is onderweg hier, extra Seriëel naar RS485 is nodig voor die uit te kunnen lezen gok ik?

Je kunt de batterij in theorie een ander adres geven en hem aan hetzelfde Modbus netwerk hangen, maar dat vereist wel wat instelwerk. Zit ook niet in de standaard Elfin configuratie verwerkt (ook niet in de LilyGo).

[HiHaHors]

LilyGo heeft het overleefd. Helaas zie ik allemaal van dit soort meldingen:

[09:37:50][D][modbus_controller:039]: Modbus command to device=1 register=0xA424 no response received - removed from send queue
[09:37:50][D][modbus_controller:039]: Modbus command to device=1 register=0xA7F8 no response received - removed from send queue

Betekent dit dat de registers anders zijn dan de V2.0 versie?

[pascallj]

HiHaHors schreef op vrijdag 5 september 2025 @ 09:43:
LilyGo heeft het overleefd. Helaas zie ik allemaal van dit soort meldingen:

[09:37:50][D][modbus_controller:039]: Modbus command to device=1 register=0xA424 no response received - removed from send queue
[09:37:50][D][modbus_controller:039]: Modbus command to device=1 register=0xA7F8 no response received - removed from send queue

Betekent dit dat de registers anders zijn dan de V2.0 versie?

Dat zou heel goed kunnen. Of geactiveerd moet worden o.i.d. Dat is bij bijvoorbeeld de B2500 van Marstek wel zo.

Je kunt nog proberen om A en B om te draaien, dat kan geen kwaad.

Welke LilyGo gebruik je met welk configuratiebestand? We zien hier nog wel eens dat mensen de verkeerde configuratie pakken voor hun bord.

[ Voor 9% gewijzigd door pascallj op 05-09-2025 09:49 ]

[HiHaHors]

pascallj schreef op vrijdag 5 september 2025 @ 09:45:
[...]


Dat zou heel goed kunnen. Of geactiveerd moet worden o.i.d. Dat is bij bijvoorbeeld de B2500 van Marstek wel zo.

Je kunt nog proberen om A en B om te draaien, dat kan geen kwaad.

Heb A en B omgedraaid: allemaal modbus errors...

[pascallj]

HiHaHors schreef op vrijdag 5 september 2025 @ 09:50:
[...]


Heb A en B omgedraaid: allemaal modbus errors...

Welke LilyGo gebruik je met welk configuratiebestand? We zien hier nog wel eens dat mensen de verkeerde configuratie pakken voor hun bord.

[HiHaHors]

pascallj schreef op vrijdag 5 september 2025 @ 09:52:
[...]


Welke LilyGo gebruik je met welk configuratiebestand? We zien hier nog wel eens dat mensen de verkeerde configuratie pakken voor hun bord.

Ik heb de LilyGO T-CAN485 - ESP32. Configuratie is lilygo-rs485.yaml van Superduper1969.

[Kammika]

FirefoxNL schreef op donderdag 4 september 2025 @ 21:38:
[...]


Ik gebruik zelf de Elfin in combinatie met de yaml van WargamingPlayer. Je kan daarin de scan_interval aanpassen. Heb die zelf van 10 naar 5 seconden gezet, dat vond ik eerst snel genoeg. Sneller heb ik nog niet geprobeerd maar kan je even mee experimenteren of het dan nog stabiel blijft draaien.

[Afbeelding]

ik heb scan_interval naar 5 gezet. Ik zie de updates met heel wisselende intervallen. Soms wel een minuut, soms 30 sec. Soms 20 sec, maar dan heb ik het wel gehad. Lijkt het toch niet te zijn. Iemand een idee?

Verder lukt me manuele besturing vanuit HA ook nog niet.
- Als ik de switch Marstek 1 RS485 Control Mode Switch op aan zet, dan stopt alle leveren/terugleveren... (verwacht gedrag, ik wil het nl zelf gaan besturen).
- Maar heb niet de controles om dit verder te besturen zoals hierboven beschreven is: Ik heb wel Marstek Forcible Charge Power en Marstek Forcible Discharge Power, maar dat zijn sensoren, geen input_numbers.
- Ik mis ook de hierboven beschreven selector Marstek Forcible Charge/Discharge

Ik zie deze input_selector en input_numbers uberhaupt ook niet in de YAML terugkomen, daarentegen wel een script: script.marstek_1_set_forcible_charge, die weer de input_number.marstek_1_discharging_charging_power
kennelijk als trigger heeft. Maar als ik die waarde zet, gebeurt er niets.

Dus hoe werkt dat precies als je de YAML van Wargaming player gebruikt?

EDIT:
Ik heb een workaround voor de 5 seconde updates gevonden met deze automatisering, dan wel periodieke updates. Maar lijkt me wat omslachtig, hou me dus aanbevolen als iemand een beter truc weet...

code:

alias: Update Modbus
description: ""
triggers:
  - trigger: time_pattern
    seconds: /5
conditions: []
actions:
  - action: homeassistant.update_entity
    data:
      entity_id:
        - sensor.marstek_1_ac_power
        - sensor.marstek_1_battery_power
mode: single

[ Voor 21% gewijzigd door Kammika op 05-09-2025 12:17 ]

[SatScan]

Kammika schreef op vrijdag 5 september 2025 @ 11:48:
[...]

ik heb scan_interval naar 5 gezet. Ik zie de updates met heel wisselende intervallen. Soms wel een minuut, soms 30 sec. Soms 20 sec, maar dan heb ik het wel gehad. Lijkt het toch niet te zijn. Iemand een idee?

Verder lukt me manuele besturing vanuit HA ook nog niet.
- Als ik de switch Marstek 1 RS485 Control Mode Switch op aan zet, dan stopt alle leveren/terugleveren... (verwacht gedrag, ik wil het nl zelf gaan besturen).
- Maar heb niet de controles om dit verder te besturen zoals hierboven beschreven is: Ik heb wel Marstek Forcible Charge Power en Marstek Forcible Discharge Power, maar dat zijn sensoren, geen input_numbers.
- Ik mis ook de hierboven beschreven selector Marstek Forcible Charge/Discharge

Dus hoe werkt dat precies als je de YAML van Wargaming player gebruikt?

@WargamingPlayer heb jij een idee ;-)

[FirefoxNL]

pascallj schreef op vrijdag 5 september 2025 @ 08:23:
[...]
Ja je hebt gelijk! Sorry ik weet niet waar ik gisteren zat met m'n gedachten. Heb nogmaals de metingen van @FirefoxNL vergeleken en het is inderdaad andersom. Oeps! Ik hoop dat je PCB goede polariteit protectie heeft!

Qua potentiaal t.o.v. GND is het dan zo:

+5,47 V (+5V)
+5,35 V (RS485-B / U+)
+0,05 V (RS485-A / U-) (waarschijnlijk weggelaten in de meting vanwege 0-meting)
GND (GND)

Dus nieuwe resumé...:
Pin 1 - RS485-B
Pin 2 - RS485-A
Pin 4-5 - +5V (voeding)
Pin 7-8 - GND

offtopic:
Zo zie je dus maar weer dat we lui worden als we alle antwoorden zo op een presenteerblaadje krijgen...

Kijk, dat werkt inderdaad! Even de GND en 5V omgedraaid en de Elfin krijgt nu ook stroom!
Ik heb tussen A (2) en GND (7 & 8 ) inderdaad 0,04 V gemeten maar had die weggelaten in mijn reactie. Ik nam aan dat dat een meetfoutje was...

Het bericht van @HiHaHors stemt me nog niet heel positief over de registers...

[WargamingPlayer]

SatScan schreef op vrijdag 5 september 2025 @ 11:50:
[...]


@WargamingPlayer heb jij een idee ;-)

Ik zou graag ven moeten kijken. Ik heb besturing voor een groot gedeelte er niet in zitten. Alleen maar de forceable power optie en backup poort volgens mij. Overige besturing nog niet helemaal, maar zodra ik van vakantie terug ben binnenkort ga ik er even naar kijken.

Verder alleen maar zetten van Max discharge en charge percentages en min en Max charge/discharge power. En reset en factory reset. Andere settings nog niet.

Ik ben eigenlijk in afwachting tot een goede integratie van @[RNMC] Viper want dat is dan de beste oplossing.

Ik ben een en ander even snel nagekeken en inderdaad ik had de besturing voor een aantal zaken er uit gesloopt omdat ik deze niet gebruikte. Ga dit wel weer toevoegen wanneer ik meer dan een mbit netwerk heb en mijn laptop en git kan gebruiken.

[ Voor 37% gewijzigd door WargamingPlayer op 05-09-2025 13:18 ]

[Kammika]

WargamingPlayer schreef op vrijdag 5 september 2025 @ 12:53:
[...]

Ik zou graag ven moeten kijken. Ik heb besturing voor een groot gedeelte er niet in zitten. Alleen maar de forceable power optie en backup poort volgens mij. Overige besturing nog niet helemaal, maar zodra ik van vakantie terug ben binnenkort ga ik er even naar kijken.

Verder alleen maar zetten van Max discharge en charge percentages en min en Max charge/discharge power. En reset en factory reset. Andere settings nog niet.

Ik ben eigenlijk in afwachting tot een goede integratie van @[RNMC] Viper want dat is dan de beste oplossing.

Ik ben een en ander even snel nagekeken en inderdaad ik had de besturing voor een aantal zaken er uit gesloopt omdat ik deze niet gebruikte. Ga dit wel weer toevoegen wanneer ik meer dan een mbit netwerk heb en mijn laptop en git kan gebruiken.

a top heel fijn.

De integratie van @[RNMC] Viper doet het helaas niet bij mij.

Ik krijg allemaal van dit soort fouten in de log dan:

code:

2025-09-05 15:02:35.388 WARNING (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Expected 2 registers for uint16 at register 36000 (0x8CA0), got 0. Retrying once...
2025-09-05 15:02:35.444 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Exception during Modbus read: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
Traceback (most recent call last):
  File "/config/custom_components/marstek_modbus/helpers/modbus_client.py", line 139, in _read_once
    result = await self.client.read_holding_registers(
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        address=register, count=count, slave=self.unit_id
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
TypeError: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
2025-09-05 15:02:35.445 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Failed to read required registers after retry at register 31000 (0x7918)
2025-09-05 15:02:35.446 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Exception during Modbus read: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
Traceback (most recent call last):
  File "/config/custom_components/marstek_modbus/helpers/modbus_client.py", line 139, in _read_once
    result = await self.client.read_holding_registers(
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        address=register, count=count, slave=self.unit_id
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
TypeError: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
2025-09-05 15:02:35.448 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Failed to read required registers after retry at register 31100 (0x797C)
2025-09-05 15:02:35.449 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Exception during Modbus read: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
Traceback (most recent call last):
  File "/config/custom_components/marstek_modbus/helpers/modbus_client.py", line 139, in _read_once
    result = await self.client.read_holding_registers(
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        address=register, count=count, slave=self.unit_id
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
TypeError: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
2025-09-05 15:02:35.453 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Failed to read required registers after retry at register 31102 (0x797E)
2025-09-05 15:02:35.463 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Exception during Modbus read: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
Traceback (most recent call last):
  File "/config/custom_components/marstek_modbus/helpers/modbus_client.py", line 139, in _read_once
    result = await self.client.read_holding_registers(
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        address=register, count=count, slave=self.unit_id
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
TypeError: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
2025-09-05 15:02:35.467 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Failed to read required registers after retry at register 31101 (0x797D)
2025-09-05 15:02:35.468 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Exception during Modbus read: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
Traceback (most recent call last):
  File "/config/custom_components/marstek_modbus/helpers/modbus_client.py", line 139, in _read_once
    result = await self.client.read_holding_registers(
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        address=register, count=count, slave=self.unit_id
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
TypeError: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'

[pascallj]

Kammika schreef op vrijdag 5 september 2025 @ 15:12:
[...]

a top heel fijn.

De integratie van @[RNMC] Viper doet het helaas niet bij mij.

Ik krijg allemaal van dit soort fouten in de log dan:

code:

2025-09-05 15:02:35.388 WARNING (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Expected 2 registers for uint16 at register 36000 (0x8CA0), got 0. Retrying once...
2025-09-05 15:02:35.444 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Exception during Modbus read: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
Traceback (most recent call last):
  File "/config/custom_components/marstek_modbus/helpers/modbus_client.py", line 139, in _read_once
    result = await self.client.read_holding_registers(
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        address=register, count=count, slave=self.unit_id
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
TypeError: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
2025-09-05 15:02:35.445 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Failed to read required registers after retry at register 31000 (0x7918)
2025-09-05 15:02:35.446 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Exception during Modbus read: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
Traceback (most recent call last):
  File "/config/custom_components/marstek_modbus/helpers/modbus_client.py", line 139, in _read_once
    result = await self.client.read_holding_registers(
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        address=register, count=count, slave=self.unit_id
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
TypeError: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
2025-09-05 15:02:35.448 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Failed to read required registers after retry at register 31100 (0x797C)
2025-09-05 15:02:35.449 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Exception during Modbus read: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
Traceback (most recent call last):
  File "/config/custom_components/marstek_modbus/helpers/modbus_client.py", line 139, in _read_once
    result = await self.client.read_holding_registers(
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        address=register, count=count, slave=self.unit_id
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
TypeError: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
2025-09-05 15:02:35.453 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Failed to read required registers after retry at register 31102 (0x797E)
2025-09-05 15:02:35.463 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Exception during Modbus read: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
Traceback (most recent call last):
  File "/config/custom_components/marstek_modbus/helpers/modbus_client.py", line 139, in _read_once
    result = await self.client.read_holding_registers(
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        address=register, count=count, slave=self.unit_id
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
TypeError: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
2025-09-05 15:02:35.467 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Failed to read required registers after retry at register 31101 (0x797D)
2025-09-05 15:02:35.468 ERROR (MainThread) [custom_components.marstek_modbus.helpers.modbus_client] Exception during Modbus read: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'
Traceback (most recent call last):
  File "/config/custom_components/marstek_modbus/helpers/modbus_client.py", line 139, in _read_once
    result = await self.client.read_holding_registers(
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        address=register, count=count, slave=self.unit_id
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
TypeError: ModbusClientMixin.read_holding_registers() got an unexpected keyword argument 'slave'

Zie: [RNMC] Viper in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"

[Kammika]

[RNMC] Viper schreef op donderdag 4 september 2025 @ 17:34:
[...]

Fix in nieuwe versie staat klaar 2025.9.1. Sinds versie 2025.9.0 zit er dynamic polling en background update, helaas door update van Home Assistant was er snel een fix nodig. Feedback is welkom.

a toppers hier op het forum met de snelle reacties!!

Dit was idd het issue. Wel gek dat HACS niet aangaf dat er een nieuwe versie was, maar na update deed die het idd!

Ik ga ook eens met deze plugin experimenteren.

[FirefoxNL]

Het lijkt er haast op dat de Modbus registers standaard grotendeels uitgeschakeld zijn.
Met een beetje hulp van AI even een scriptje geschreven wat alle 65500 Modbus registers uitleest:

code:

from pymodbus.client import ModbusTcpClient
from pymodbus.exceptions import ModbusException

HOST = "10.30.30.167"
PORT = 502

START_ADDR = 0
END_ADDR = 65500
BLOCK_SIZE = 10  

def scan_registers(client: ModbusTcpClient, start, end, block_size):
    for addr in range(start, end, block_size):
        try:
            rr = client.read_holding_registers(addr, count=block_size)

            if rr.isError():
                continue  # skip invalid ranges

            values = rr.registers
            if values:
                print(f"{addr:05d}–{addr+block_size-1:05d}: {values}")

        except ModbusException as e:
            print(f"Error at {addr}: {e}")
        except Exception as e:
            print(f"Unexpected error at {addr}: {e}")

def main():
    client = ModbusTcpClient(HOST, port=PORT)
    if not client.connect():
        print("Failed to connect to Modbus server")
        return

    try:
        scan_registers(client, START_ADDR, END_ADDR, BLOCK_SIZE)
    finally:
        client.close()

if __name__ == "__main__":
    try:
        main()
    except KeyboardInterrupt:
        pass

Maar dit levert alleen de volgende resultaten op:
30300–30309: [1, 3, 1, 60, 13872, 13106, 13122, 16707, 14404, 14644]
37000–37009: [1, 0, 0, 0, 0, 45, 240, 3290, 3284, 0]

30300 = WiFi Status
30301 = BT Status
30303 = WiFi Signal Strength

Deze sensors zijn ook aanwezig in de yaml integratie van WargamingPlayer. Voor de rest zijn er dus geen leesbare holding registers die een response terugsturen.

[pascallj]

FirefoxNL schreef op vrijdag 5 september 2025 @ 15:45:
Het lijkt er haast op dat de Modbus registers standaard grotendeels uitgeschakeld zijn.
Met een beetje hulp van AI even een scriptje geschreven wat alle 65500 Modbus registers uitleest:

[...]


Maar dit levert alleen de volgende resultaten op:
30300–30309: [1, 3, 1, 60, 13872, 13106, 13122, 16707, 14404, 14644]
37000–37009: [1, 0, 0, 0, 0, 45, 240, 3290, 3284, 0]

30300 = WiFi Status
30301 = BT Status
30303 = WiFi Signal Strength

Deze sensors zijn ook aanwezig in de yaml integratie van WargamingPlayer. Voor de rest zijn er dus geen leesbare holding registers die een response terugsturen.

Wat is de reden dat je bent gaan scannen? Krijg je met de standaard integratie geen resultaten?

Je scant met een block size van 10. Dat betekent dat je alleen een geldig resultaat krijg als er 10 achtereenvolgende registers een geldige waarde hebben. En aangezien het ook in stappen van 10 gaat, moet dit blok dus ook nog eens beginnen op een veelvoud van 10. Op het al het andere zal je dus sowieso geen geldig resultaat krijgen.

Wat je tot nu toe hebt is volgens mij exact hetzelfde als bij de V2.

Bekijk ook mijn onofficiële Modbus documentatie voor de huidige registers zoals we die kennen: https://docs.google.com/s...9238506&single=true&pli=1

[FirefoxNL]

pascallj schreef op vrijdag 5 september 2025 @ 15:52:
[...]
Wat is de reden dat je bent gaan scannen? Krijg je met de standaard integratie geen resultaten?

Klopt inderdaad. Alleen de WiFi en BT Status en WiFi Signal Strength kunnen gelezen worden.
De rest van de sensoren is allemaal unavailable.

Je scant met een block size van 10. Dat betekent dat je alleen een geldig resultaat krijg als er 10 achtereenvolgende registers een geldige waarde hebben. En aangezien het ook in stappen van 10 gaat, moet dit blok dus ook nog eens beginnen op een veelvoud van 10. Op het al het andere zal je dus sowieso geen geldig resultaat krijgen.

Check. Weer wat geleerd. Ik zal nog eens proberen met wat kleinere blocksizes te scannen maar mijn kennis van Modbus is vrij beperkt (zeg maar 0) dus ik ben bang dat ik hier niet veel verder mee ga komen.

Bekijk ook mijn onofficiële Modbus documentatie voor de huidige registers zoals we die kennen: https://docs.google.com/s...9238506&single=true&pli=1

Thanks, zal ook eens wat variaties daarop proberen. De registers zoals ze daar staan werken dus (nog) niet.

[FirefoxNL]

Korte update: De registers 37004 t/m 37008 zijn aanwezig. In de V2 firmware waren ze dubbel (32202, 32104, 35010, 35011) maar zijn nu dus nog als enige aanwezig.
Dit zijn dus respectievelijk AC power, Battery SOC, Cell temperature en Max en Min cell voltage.
Door de address waarde in de yaml aan te passen zijn die waarden uit te lezen.

Datatype van 37004 (AC Power) is wel gewijzigd van een s32 naar een int16.

[AUijtdehaag]

@FirefoxNL
37004 had ik ook al gevonden bij de V1V2 dat het niet klopte in de excellijst en is doorgegeven aan @pascallj maar nog niet doorgevoerd.

[ Voor 3% gewijzigd door AUijtdehaag op 05-09-2025 18:30 ]

[pascallj]

FirefoxNL schreef op vrijdag 5 september 2025 @ 18:22:
Korte update: De registers 37004 t/m 37008 zijn aanwezig. In de V2 firmware waren ze dubbel (32202, 32104, 35010, 35011) maar zijn nu dus nog als enige aanwezig.
Dit zijn dus respectievelijk AC power, Battery SOC, Cell temperature en Max en Min cell voltage.
Door de address waarde in de yaml aan te passen zijn die waarden uit te lezen.

Datatype van 37004 (AC Power) is wel gewijzigd van een s32 naar een int16.

Maar verder niets meer kunnen vinden? Ook niet met kleinere blocksizes (1)? Want dan mis je wel een berg data tov V2...

~AUijtdehaag heeft het inderdaad laten weten. Ik wil teveel . De aanpassing nog niet live gezet... Overigens is het wel Signed Int 16 denk ik. De AC Power moet ook negatief kunnen.

[ Voor 5% gewijzigd door pascallj op 05-09-2025 18:46 ]

[FirefoxNL]

pascallj schreef op vrijdag 5 september 2025 @ 18:45:
[...]
Maar verder niets meer kunnen vinden? Ook niet met kleinere blocksizes (1)? Want dan mis je wel een berg data tov V2...

Klopt, er mist inderdaad een hoop. Ik heb nog niet alles kunnen ontcijferen maar hier alvast een uitdraai van alle scans met blocksize 1 tussen 30000 en 46000 met de waarden uit mijn V2 en V3: https://docs.google.com/s...pubhtml?gid=0&single=true

De V3 stond stil op dit moment dus mogelijk dat er door wat lading op te zetten nog wat meer ontcijfert kan worden maar daar ga ik vanavond mee verder. Ik heb nu in elk geval de belangrijkste om mijn energie dashboard te vullen (AC Power en SOC).
Aansturen wordt nog lastig aangezien vooralsnog (onder andere) de RS485 Control Mode ontbreekt.

pascallj schreef op vrijdag 5 september 2025 @ 18:45:
[...]
Overigens is het wel Signed Int 16 denk ik. De AC Power moet ook negatief kunnen.

Klopt inderdaad, uint16 werkt niet. Het moet een signed int zijn, ofwel data_type: int16.

[corsat]

Na 2x korte uitval van de communicatie tussen de ct003 en de beide batterijen wil ik ze onafhankelijk via modbus gaan aansturen, moet ik dit node red gaan inregelen. Ik heb een Shelly die ik wil als input wil gebruiken of kan ik direct mijn p1 input via bijvoorbeeld van mijn youless gebruiken om de batterijen via modbus aan te sturen.

[WargamingPlayer]

Helaas geen goede internet tot morgen avond, dus kan niks testen of aanpassen. Maar zodra ik de mogelijkheid heb kan ik even kijken.
Ik heb geen V3 dus daar kan ik weinig mee helaas.

[Kammika]

[RNMC] Viper schreef op donderdag 4 september 2025 @ 17:34:
[...]

Fix in nieuwe versie staat klaar 2025.9.1. Sinds versie 2025.9.0 zit er dynamic polling en background update, helaas door update van Home Assistant was er snel een fix nodig. Feedback is welkom.

Hij doet het goed je custom integratie!! Echt mooi gemaakt!

1 dingetje werkt bij mij niet lekker: ik kan charging/discharging cuttoff niet goed instellen. die blijven op waardes 1000 (ik denk 100%) en 120 (ik denk 12%?) staan, maakt niet uit hoe ik aan die slider sleep.

Als ik aan de slider sleep geeft die wel netjes de boundaries weer (vb 12-30 voor dedischarging cutoff). Maar dat werkt dus niet.



Alle andere besturingsfuncties werken helemaal top.


NB: Ik ga dit zelf niet gebruiken (maak er automatiseringen van die 'm ook weer terugzetten naar dat die rs485 besturing weer uitgaat als doelpercentage behaald wordt, maar wou het toch eff melden..

EDIT:

En ik heb nog een vraag: Hoe krijg ik de frequentie van het ophalen van de SoC, AC Power en Battery Power omhoog? Voor zoals ik de besturing wil inrichten (met EVCC) heb ik iedere 5 sec de actuele stand nodiug... is dit te configureren in deze custom integratie?

[ Voor 10% gewijzigd door Kammika op 06-09-2025 13:59 ]

[savale]

Hier helaas nog een oudere meterkast. p1 data komt iedere 10 seconden, dus dat gaat niet optimaal werken. Ik zit er aan te denken om de Victron VM-3P75CT in te gaan bouwen. Als ik het goed begrijp kan ik die direct via UDP uitlezen:
https://community.home-as...dbus-config-for-ha/870721
schijnt iedere 0.1 seconden een update te geven.
Iemand ervaringen mee of iets anders in gebruik?

Shelly 3 pro em lijkt me net even handiger / neemt wat minder ruimte op mijn DIN rail in. Beetje onduidelijk alleen wat de update rate is. Iemand enig idee?
https://www.reddit.com/r/.../shelly_pro_3em_via_mqtt/
Zie nu in dit topic ook dat als ik het toch door marstek wil laten regelen de shelly ook gesupport is. Leuke bijkomstigheid.

[ Voor 63% gewijzigd door savale op 06-09-2025 16:45 ]

[Hermarcel]

@savale
Ik heb de VM-3P75CT zowel met Canbus (voor de Victron aansturing) als Ethernet (voor HomeAssistant) aangesloten. De meter ondersteunt Modbus over UDP. Dit is de config die ik gebruik in HomeAssistant:

YAML:

- name: modbus_victron_gridmeter
  type: udp
  host: ipadres/hostname van de meter
  port: 502
  sensors:
    - name: "Grid Power"
      unique_id: Grid_Power
      unit_of_measurement: W
      slave: 1
      address: 0x3080
      data_type: int32
      scan_interval: 2
      device_class: power

    - name: "Grid Import"
      unique_id: Grid_Import
      unit_of_measurement: kWh
      slave: 1
      address: 0x3034
      data_type: uint32
      scale: 0.01
      precision: 2
      scan_interval: 15
      device_class: energy
      state_class: total_increasing

    - name: "Grid Export"
      unique_id: Grid_Export
      unit_of_measurement: kWh
      slave: 1
      address: 0x3036
      data_type: uint32
      scale: 0.01
      precision: 2
      scan_interval: 15
      device_class: energy
      state_class: total_increasing

    #- name: "Grid PENVoltage"
    #  unique_id: Grid_PENvoltage
    #  unit_of_measurement: V
    #  slave: 1
    #  address: 0x3033
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: voltage
    #
    #- name: "Grid Frequency"
    #  unique_id: Grid_Frequency
    #  unit_of_measurement: Hz
    #  slave: 1
    #  address: 0x3032
    #  data_type: uint16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: frequency
    #=============================================
    #=================== L1 ======================
    #=============================================
    #- name: "VM-3P75CT Voltage L1"
    #  unique_id: vm_3p75ct_voltage_l1
    #  unit_of_measurement: V
    #  slave: 1
    #  address: 0x3040
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: voltage
    #- name: "VM-3P75CT Current L1"
    #  unique_id: vm_3p75ct_current_l1
    #  unit_of_measurement: A
    #  slave: 1
    #  address: 0x3041
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: current
    #
    #  # energy forward on L1 on 0x3042 and 0x3043
    #  # energy reverse on L1 on 0x3044 and 0x3045
    #  #             power L1 on 0x3046 and 0x3047
    #
    #  #=============================================
    #  #=================== L2 ======================
    #  #=============================================
    #- name: "VM-3P75CT Voltage L2"
    #  unique_id: vm_3p75ct_voltage_l2
    #  unit_of_measurement: V
    #  slave: 1
    #  address: 0x3048
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: voltage
    #- name: "VM-3P75CT Current L2"
    #  unique_id: vm_3p75ct_current_l2
    #  unit_of_measurement: A
    #  slave: 1
    #  address: 0x3049
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: current
    #
    #  # energy forward on L2 on 0x304A and 0x304B
    #  # energy reverse on L2 on 0x304C and 0x304D
    #  #             power L2 on 0x304E and 0x304F
    #
    #  #=============================================
    #  #=================== L3 ======================
    #  #=============================================
    #- name: "VM-3P75CT Voltage L3"
    #  unique_id: vm_3p75ct_voltage_l3
    #  unit_of_measurement: V
    #  slave: 1
    #  address: 0x3050
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: voltage
    #- name: "VM-3P75CT Current L3"
    #  unique_id: vm_3p75ct_current_l3
    #  unit_of_measurement: A
    #  slave: 1
    #  address: 0x3051
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: current
    #
    #  # energy forward on L3 on 0x3052 and 0x3053
    #  # energy reverse on L3 on 0x3054 and 0x3055
    #  #             power L3 on 0x3056 and 0x3057

Zoals je ziet, heb ik niet alle entiteiten in gebruik. De niet-gebruikte heb ik niet getest.
Verder zie je dat ik verschillende scan_intervals gebruik: Ik denk dat het goed is om, per entiteit, te bepalen hoe vaak je nieuwe data nodig hebt.

Credits: Iemand op het internet. Ik niet in ieder geval.

[[RNMC] Viper]

Kammika schreef op zaterdag 6 september 2025 @ 12:04:
[...]

Hij doet het goed je custom integratie!! Echt mooi gemaakt!

1 dingetje werkt bij mij niet lekker: ik kan charging/discharging cuttoff niet goed instellen. die blijven op waardes 1000 (ik denk 100%) en 120 (ik denk 12%?) staan, maakt niet uit hoe ik aan die slider sleep.

Als ik aan de slider sleep geeft die wel netjes de boundaries weer (vb 12-30 voor dedischarging cutoff). Maar dat werkt dus niet.

[Afbeelding]

Alle andere besturingsfuncties werken helemaal top.


NB: Ik ga dit zelf niet gebruiken (maak er automatiseringen van die 'm ook weer terugzetten naar dat die rs485 besturing weer uitgaat als doelpercentage behaald wordt, maar wou het toch eff melden..

EDIT:

En ik heb nog een vraag: Hoe krijg ik de frequentie van het ophalen van de SoC, AC Power en Battery Power omhoog? Voor zoals ik de besturing wil inrichten (met EVCC) heb ik iedere 5 sec de actuele stand nodiug... is dit te configureren in deze custom integratie?

Goed dat je het zegt, valt mij nu ook hier op, zal het komende week even onderzoeken.

[WargamingPlayer]

[RNMC] Viper schreef op zaterdag 6 september 2025 @ 22:36:
[...]

Goed dat je het zegt, valt mij nu ook hier op, zal het komende week even onderzoeken.

De waarde van Modbus register is 120 voor 11%. Je moet er eigenlijk een offset van 10 voor aftrekken bij lezen en een offset van 10 bij optellen wanneer je de waarde zet.
De slider moet je eigenlijk maken van 11.0 naar 30.0 in stapjes van 0.1.
Het zetten van de slider doe je doormiddel van 10 aftrekken van de Modbus waarde en dan delen door 10. (120 wordt dan 110 en dan na delen 11.0, 310 wordt dan 300 en na delen 30.0). Bij het schrijven van het register doe je: Slider waarde * 10 plus 10, 11.0% wordt dan 120, 30.0 wordt dan 131.
Misschien kan je in je settings voor sensoren iets doen met een read en witte offset veld.

Bij mij vertikte de Marstek een waarde van 110 te accepteren en (iedere waarde lager dan 120 werd niet geaccepteerd) en een waarde hoger dan 310 ook niet.

[ Voor 13% gewijzigd door WargamingPlayer op 07-09-2025 12:33 ]

[[RNMC] Viper]

WargamingPlayer schreef op zondag 7 september 2025 @ 12:29:
[...]

De waarde van Modbus register is 120 voor 11%. Je moet er eigenlijk een offset van 10 voor aftrekken bij lezen en een offset van 10 bij optellen wanneer je de waarde zet.
De slider moet je eigenlijk maken van 11.0 naar 30.0 in stapjes van 0.1.
Het zetten van de slider doe je doormiddel van 10 aftrekken van de Modbus waarde en dan delen door 10. (120 wordt dan 110 en dan na delen 11.0, 310 wordt dan 300 en na delen 30.0). Bij het schrijven van het register doe je: Slider waarde * 10 plus 10, 11.0% wordt dan 120, 30.0 wordt dan 131.
Misschien kan je in je settings voor sensoren iets doen met een read en witte offset veld.

Bij mij vertikte de Marstek een waarde van 110 te accepteren en (iedere waarde lager dan 120 werd niet geaccepteerd) en een waarde hoger dan 310 ook niet.

Snap het punt, maar vind het wel gek om iets te corrigeren wat blijkbaar niet goed in de modbus zit. Waarom 120 lezen schrijven, terwijl hij door trekt naar 110.

[pascallj]

[RNMC] Viper schreef op zondag 7 september 2025 @ 15:01:
[...]

Snap het punt, maar vind het wel gek om iets te corrigeren wat blijkbaar niet goed in de modbus zit. Waarom 120 lezen schrijven, terwijl hij door trekt naar 110.

Gewoon delen door 10 lijkt mij voldoende. Of je nu 11 of 12 als weergegeven minimum instelt maakt niet uit. Kwestie van interpretatie. Stoppen na 12 of stoppen op 12.

[WargamingPlayer]

pascallj schreef op zondag 7 september 2025 @ 15:07:
[...]

Gewoon delen door 10 lijkt mij voldoende. Of je nu 11 of 12 als weergegeven minimum instelt maakt niet uit. Kwestie van interpretatie. Stoppen na 12 of stoppen op 12.

Ik ben misschien een zeur (ik weet het, maar tja gevalletje OCD), maar ik houd er van dat de waarde in de App overeenkomt met wat ik in HA zie. Conformiteit en uniformiteit. Dat is het zelfde als wij hebben met audits, vraagt de auditor, ik zie dat jullie disk size monitoren op 10% vrije ruimte maar wanneer ik naar jullie rapportage query kijk staat daar “and volumeusage >90”. En dan iedere keer moeten zeggen. “Ja maar wij weten dat dit we dit bedoelen” en de auditor zegt, ja maar dat staat er niet.

Overigens het is @[RNMC] Viper zijn integratie dus hij is vrij om te doen wat hij wil. Wanneer ik python geleerd heb pas ik het zelf wel aan. En complimenten voor zijn mooie werk.

[ Voor 10% gewijzigd door WargamingPlayer op 07-09-2025 15:27 ]

[[RNMC] Viper]

WargamingPlayer schreef op zondag 7 september 2025 @ 15:24:
[...]

Ik ben misschien een zeur (ik weet het, maar tja gevalletje OCD), maar ik houd er van dat de waarde in de App overeenkomt met wat ik in HA zie. Conformiteit en uniformiteit. Dat is het zelfde als wij hebben met audits, vraagt de auditor, ik zie dat jullie disk size monitoren op 10% vrije ruimte maar wanneer ik naar jullie rapportage query kijk staat daar “and volumeusage >90”. En dan iedere keer moeten zeggen. “Ja maar wij weten dat dit we dit bedoelen” en de auditor zegt, ja maar dat staat er niet.

Overigens het is @[RNMC] Viper zijn integratie dus hij is vrij om te doen wat hij wil. Wanneer ik python geleerd heb pas ik het zelf wel aan. En complimenten voor zijn mooie werk.

Dank, het staat je vrij om te forken en dit stukje aan te passen. Dit is ook mijn eerste Python project, geboren uit noodzaak. Alles via de modbus integratie laten lopen is ook niet echt praktisch, omdat ik veelal overstapt ben naar gui in Home Assistant.

Ben ook nog steeds op zoek naar het schakelen van de 800 discharge limit, zeker omdat ik niet afhankelijk wil zijn van cloud. Ben benieuwd wat de API ons gaat brengen.

[FirefoxNL]

Zoals beloofd ook nog even een foto voor het aansluiten van de Elfin op de V3. @superduper1969 Misschien dat je dit in de start post kan verwerken aangezien de info van Marstek niet juist is?

Voor een 'normale' T-568B UTP kabel is de aansluitvolgorde als volgt:

• A : Oranje-wit
• + : Blauw (en/of Blauw-wit)
• - : Bruin (en/of Bruin-Wit)
• B : Oranje

Daarnaast ook het MAC address, battery power en AC voltage nog gevonden in de V3 en bijgewerkt in mijn sheet. Zonder documentatie ga ik niet veel verder komen verwacht ik.

@thuisbatterij Kunnen jullie eens bij Marstek vragen of ze al documentatie hebben van de Modbus koppeling voor de V3 en of er in komende updates meer registers beschikbaar gesteld worden?

[ Voor 8% gewijzigd door FirefoxNL op 07-09-2025 15:56 ]

[superduper1969]

FirefoxNL schreef op zondag 7 september 2025 @ 15:55:
Zoals beloofd ook nog even een foto voor het aansluiten van de Elfin op de V3. @superduper1969 Misschien dat je dit in de start post kan verwerken aangezien de info van Marstek niet juist is?

Voor een 'normale' T-568B UTP kabel is de aansluitvolgorde als volgt:

• A : Oranje-wit
• + : Blauw (en/of Blauw-wit)
• - : Bruin (en/of Bruin-Wit)
• B : Oranje

[Afbeelding]

Daarnaast ook het MAC address, battery power en AC voltage nog gevonden in de V3 en bijgewerkt in mijn sheet. Zonder documentatie ga ik niet veel verder komen verwacht ik.

@thuisbatterij Kunnen jullie eens bij Marstek vragen of ze al documentatie hebben van de Modbus koppeling voor de V3 en of er in komende updates meer registers beschikbaar gesteld worden?

Ik zal het woensdag verwerken, dan ben ik weer thuis. Op de telefoon is dat best wel een gedoe.

[WargamingPlayer]

[RNMC] Viper schreef op zondag 7 september 2025 @ 15:53:
[...]

Dank, het staat je vrij om te forken en dit stukje aan te passen. Dit is ook mijn eerste Python project, geboren uit noodzaak. Alles via de modbus integratie laten lopen is ook niet echt praktisch, omdat ik veelal overstapt ben naar gui in Home Assistant.

Ben ook nog steeds op zoek naar het schakelen van de 800 discharge limit, zeker omdat ik niet afhankelijk wil zijn van cloud. Ben benieuwd wat de API ons gaat brengen.

Dat laatste krijg ik dus ook niet aan de praat met Modbus. Ik heb verschillende dingen geprobeerd maar het lukt niet.

[BjornVanc]

Hoe zorgen jullie dat de Lilygo voeding krijgt? Heb al tijdje adapter via backup voeding aangesloten maar gisteren was batterij zo plat dat de lilygo geen stroom meer kreeg…. Batterij stond nog op 11%… Hoe zou ik dit kunnen oplossen?

[AUijtdehaag]

@BjornVanc
Voeding gewoon via de modbus stekker?

[ Voor 7% gewijzigd door AUijtdehaag op 08-09-2025 08:03 ]

[BjornVanc]

@AUijtdehaag
Ik heb voeding daar net aangekoppeld en in parallel die van Lily. Zonder die voeding krijgt de Lily geen stroom,

Maar ik zie wel dat ik de modus anders heb aangesloten….

Goed dat ik weet dat voeding via modus komt! Pas ik aan. Merci!🙏

[ Voor 34% gewijzigd door BjornVanc op 08-09-2025 08:22 ]

[Maxwp]

FirefoxNL schreef op zondag 7 september 2025 @ 15:55:
Zoals beloofd ook nog even een foto voor het aansluiten van de Elfin op de V3. @superduper1969 Misschien dat je dit in de start post kan verwerken aangezien de info van Marstek niet juist is?

Voor een 'normale' T-568B UTP kabel is de aansluitvolgorde als volgt:

• A : Oranje-wit
• + : Blauw (en/of Blauw-wit)
• - : Bruin (en/of Bruin-Wit)
• B : Oranje

[Afbeelding]

Daarnaast ook het MAC address, battery power en AC voltage nog gevonden in de V3 en bijgewerkt in mijn sheet. Zonder documentatie ga ik niet veel verder komen verwacht ik.

@thuisbatterij Kunnen jullie eens bij Marstek vragen of ze al documentatie hebben van de Modbus koppeling voor de V3 en of er in komende updates meer registers beschikbaar gesteld worden?

ze hebben de modbus registrrs aangepast op de v3 ?
Waarom niet gelijk gehouden pfff weer zo typisch

[savale]

Hermarcel schreef op zaterdag 6 september 2025 @ 18:59:
@savale
Ik heb de VM-3P75CT zowel met Canbus (voor de Victron aansturing) als Ethernet (voor HomeAssistant) aangesloten. De meter ondersteunt Modbus over UDP. Dit is de config die ik gebruik in HomeAssistant:

YAML:

- name: modbus_victron_gridmeter
  type: udp
  host: ipadres/hostname van de meter
  port: 502
  sensors:
    - name: "Grid Power"
      unique_id: Grid_Power
      unit_of_measurement: W
      slave: 1
      address: 0x3080
      data_type: int32
      scan_interval: 2
      device_class: power

    - name: "Grid Import"
      unique_id: Grid_Import
      unit_of_measurement: kWh
      slave: 1
      address: 0x3034
      data_type: uint32
      scale: 0.01
      precision: 2
      scan_interval: 15
      device_class: energy
      state_class: total_increasing

    - name: "Grid Export"
      unique_id: Grid_Export
      unit_of_measurement: kWh
      slave: 1
      address: 0x3036
      data_type: uint32
      scale: 0.01
      precision: 2
      scan_interval: 15
      device_class: energy
      state_class: total_increasing

    #- name: "Grid PENVoltage"
    #  unique_id: Grid_PENvoltage
    #  unit_of_measurement: V
    #  slave: 1
    #  address: 0x3033
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: voltage
    #
    #- name: "Grid Frequency"
    #  unique_id: Grid_Frequency
    #  unit_of_measurement: Hz
    #  slave: 1
    #  address: 0x3032
    #  data_type: uint16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: frequency
    #=============================================
    #=================== L1 ======================
    #=============================================
    #- name: "VM-3P75CT Voltage L1"
    #  unique_id: vm_3p75ct_voltage_l1
    #  unit_of_measurement: V
    #  slave: 1
    #  address: 0x3040
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: voltage
    #- name: "VM-3P75CT Current L1"
    #  unique_id: vm_3p75ct_current_l1
    #  unit_of_measurement: A
    #  slave: 1
    #  address: 0x3041
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: current
    #
    #  # energy forward on L1 on 0x3042 and 0x3043
    #  # energy reverse on L1 on 0x3044 and 0x3045
    #  #             power L1 on 0x3046 and 0x3047
    #
    #  #=============================================
    #  #=================== L2 ======================
    #  #=============================================
    #- name: "VM-3P75CT Voltage L2"
    #  unique_id: vm_3p75ct_voltage_l2
    #  unit_of_measurement: V
    #  slave: 1
    #  address: 0x3048
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: voltage
    #- name: "VM-3P75CT Current L2"
    #  unique_id: vm_3p75ct_current_l2
    #  unit_of_measurement: A
    #  slave: 1
    #  address: 0x3049
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: current
    #
    #  # energy forward on L2 on 0x304A and 0x304B
    #  # energy reverse on L2 on 0x304C and 0x304D
    #  #             power L2 on 0x304E and 0x304F
    #
    #  #=============================================
    #  #=================== L3 ======================
    #  #=============================================
    #- name: "VM-3P75CT Voltage L3"
    #  unique_id: vm_3p75ct_voltage_l3
    #  unit_of_measurement: V
    #  slave: 1
    #  address: 0x3050
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: voltage
    #- name: "VM-3P75CT Current L3"
    #  unique_id: vm_3p75ct_current_l3
    #  unit_of_measurement: A
    #  slave: 1
    #  address: 0x3051
    #  data_type: int16
    #  scale: 0.01
    #  precision: 2
    #  scan_interval: 1
    #  device_class: current
    #
    #  # energy forward on L3 on 0x3052 and 0x3053
    #  # energy reverse on L3 on 0x3054 and 0x3055
    #  #             power L3 on 0x3056 and 0x3057

Zoals je ziet, heb ik niet alle entiteiten in gebruik. De niet-gebruikte heb ik niet getest.
Verder zie je dat ik verschillende scan_intervals gebruik: Ik denk dat het goed is om, per entiteit, te bepalen hoe vaak je nieuwe data nodig hebt.

Credits: Iemand op het internet. Ik niet in ieder geval.

Bedankt hiervoor! Voor de duidelijkheid: enkel dus de VM-3P75CT met een LAN kabel aansluiten is genoeg om de data in home assistant te krijgen? Dus geen extra Victron kastjes of iets dergelijks nog nodig? Oftewel werkt dat ook nog als je je modbus verbinding los zou koppelen?

[Hermarcel]

@savale Correct

[FirefoxNL]

Maxwp schreef op maandag 8 september 2025 @ 08:39:
[...]
ze hebben de modbus registrrs aangepast op de v3 ?
Waarom niet gelijk gehouden pfff weer zo typisch

Yup. En niet zo'n beetje ook zoals je ziet. Naast dat ze allemaal verwisseld zijn mist meer dan de helft en daarbij alle registers om hem via Modbus te kunnen aansturen. Hopelijk komen die met een firmware update nog beschikbaar.

[savale]

FirefoxNL schreef op maandag 8 september 2025 @ 10:40:
[...]


Yup. En niet zo'n beetje ook zoals je ziet. Naast dat ze allemaal verwisseld zijn mist meer dan de helft en daarbij alle registers om hem via Modbus te kunnen aansturen. Hopelijk komen die met een firmware update nog beschikbaar.

pfft... Goed om dit te checken bij Marstek zelf? Dan heb je dus niks aan de modbus koppelijk met een v3

[FirefoxNL]

savale schreef op maandag 8 september 2025 @ 10:48:
[...]
pfft... Goed om dit te checken bij Marstek zelf? Dan heb je dus niks aan de modbus koppelijk met een v3

Voor nu is het alleen uitlezen van bijvoorbeeld state of charge en huidig vermogen inderdaad. Heb al een mailtje gestuurd naar de mannen van @thuisbatterij of zij bij Marstek willen navragen. Als ik daar reactie op krijg zal ik dat hier posten als ze dat zelf nog niet gedaan hebben.

[Demkes]

Ik heb mijn Elfin ew11A inmiddels ook aan de praat voor de v3.0. De Modbus registers zijn nog een uitdaging. Hopelijk horen we hierover snel meer van @thuisbatterij.

Wellicht is er iemand geholpen met de kabel zoals ik deze gemaakt heb.

[HexaFox]

@Demkes hier sinds kort ook een v3. Ik had eerst de WIFI geconfigureerd en nadien beslist om de vaste kabel te gebruiken. Zelfs na een factory reset blijft de Marstek de WIFI als primair nemen. Ik zie op beide een IP adres, als ik de WIFI op de router verbreek neemt de UTP niet over. Heb ticket aangemaakt bij Marstek maar misschien dat jij een andere werkwijze had?

[Demkes]

HexaFox schreef op maandag 8 september 2025 @ 15:37:
@Demkes hier sinds kort ook een v3. Ik had eerst de WIFI geconfigureerd en nadien beslist om de vaste kabel te gebruiken. Zelfs na een factory reset blijft de Marstek de WIFI als primair nemen. Ik zie op beide een IP adres, als ik de WIFI op de router verbreek neemt de UTP niet over. Heb ticket aangemaakt bij Marstek maar misschien dat jij een andere werkwijze had?

Ik moet eerlijk bekennen dat ik zojuist tot de zelfde conclusie ben gekomen. Beide zijn verbonden en krijgen een ip maar de wifi blijft primair.

Wanneer ik het mac adres van de wifi in mijn router blokkeer wordt de verbinding verbroken en pakt de utp het niet over.

Ik heb ook een factory reset gedaan en de wifi configuratie overgeslagen tijdens de setup. Toch pakt hij de oude wifi config weer op.

Ik zal ook een ticket bij Marstek aanmaken.

[pascallj]

@Demkes @HexaFox: we zien een vergelijkbaar fenomeen bij de V2 en eerder; de WiFi credentials blijven altijd bewaard, ook na een factory reset.

Een workaround om te forceren dat de WiFi niet meer kan verbinden kan zijn om even een tijdelijk hotspot op te zetten met een niet-bestaande WiFi SSID, hiermee de batterij tijdelijk te verbinden en daarna de hotspot uitzetten en SSID weer wijzigen. Misschien pakt de V3 dan (na een restart) wel de ethernet verbinding weer op.

[r03n_d]

Ik gebruik een lilygo icm de config uit de OP van @superduper1969, maar er gaat bij mij iets mis met de efficiëntie berekening. Elke dag piekt deze ergens >15.000%:

[WargamingPlayer]

r03n_d schreef op maandag 8 september 2025 @ 18:58:
Ik gebruik een lilygo icm de config uit de OP van @superduper1969, maar er gaat bij mij iets mis met de efficiëntie berekening. Elke dag piekt deze ergens >15.000%: [Afbeelding]

Je moet ook niet per dag rekenen maar per week of per maand of per kwartaal. Per dag zit je altijd fout. Want wanneer is je startpunt? Je zou het per 24 uur kunnen doen maar dan met je dat dus als volgt doen:
kWh in gemeten van 00:00 tot 00:00 de volgende dag. KWh uit gemeten over de zelfde periode.
Dan bereken je de RTE over 24 uur exact om 00:00. Je hebt dus alleen een RTE per 24 uur.

[r03n_d]

WargamingPlayer schreef op maandag 8 september 2025 @ 19:20:
[...]

Je moet ook niet per dag rekenen maar per week of per maand of per kwartaal. Per dag zit je altijd fout. Want wanneer is je startpunt? Je zou het per 24 uur kunnen doen maar dan met je dat dus als volgt doen:
kWh in gemeten van 00:00 tot 00:00 de volgende dag. KWh uit gemeten over de zelfde periode.
Dan bereken je de RTE over 24 uur exact om 00:00. Je hebt dus alleen een RTE per 24 uur.

Dat wil ik wel begrijpen, maar deze ‘helper’ wordt automatisch toegevoegd door de yaml config, en geeft dus waardes aan die niet echt bruikbaar zijn. Ook kan je ze niet in de GUI aanpassen, dan moet je de yaml aanpassen.

[ Voor 7% gewijzigd door r03n_d op 08-09-2025 21:37 ]

[thuisbatterij]

FirefoxNL schreef op zondag 7 september 2025 @ 15:55:
Zoals beloofd ook nog even een foto voor het aansluiten van de Elfin op de V3. @superduper1969 Misschien dat je dit in de start post kan verwerken aangezien de info van Marstek niet juist is?

Voor een 'normale' T-568B UTP kabel is de aansluitvolgorde als volgt:

• A : Oranje-wit
• + : Blauw (en/of Blauw-wit)
• - : Bruin (en/of Bruin-Wit)
• B : Oranje

[Afbeelding]

Daarnaast ook het MAC address, battery power en AC voltage nog gevonden in de V3 en bijgewerkt in mijn sheet. Zonder documentatie ga ik niet veel verder komen verwacht ik.

@thuisbatterij Kunnen jullie eens bij Marstek vragen of ze al documentatie hebben van de Modbus koppeling voor de V3 en of er in komende updates meer registers beschikbaar gesteld worden?

Ik heb de vraag open staan zodra ik een reactie heb met documentatie dan stuur ik het door

[HiHaHors]

Heb meerdere keren een vraag gesteld via de Feedback knop in de Marstek app, maar tot nu toe nul respons. Werkt dit bij jullie wel?

[pascallj]

HiHaHors schreef op dinsdag 9 september 2025 @ 09:37:
Heb meerdere keren een vraag gesteld via de Feedback knop in de Marstek app, maar tot nu toe nul respons. Werkt dit bij jullie wel?

Je hebt soms wat geduld nodig, maar vaak wel. Na een week vraag ik soms opnieuw om reactie.

[r03n_d]

HiHaHors schreef op dinsdag 9 september 2025 @ 09:37:
Heb meerdere keren een vraag gesteld via de Feedback knop in de Marstek app, maar tot nu toe nul respons. Werkt dit bij jullie wel?

Eenmaal gedaan, een week of anderhalf later kreeg ik een reactie via de mail.

[savale]

thuisbatterij schreef op maandag 8 september 2025 @ 22:45:
[...]


Ik heb de vraag open staan zodra ik een reactie heb met documentatie dan stuur ik het door

Top, mag hopen dat we ook de v3 via modbus kunnen aansturen!

[superduper1969]

TS aangepast:
- 10-9-2025 Modbus kabel V3 @FirefoxNL
- 10-9-2025 Modbus registers V2 vs V3 @FirefoxNL

[WargamingPlayer]

superduper1969 schreef op woensdag 10 september 2025 @ 12:13:
TS aangepast:
- 10-9-2025 Modbus kabel V3 @FirefoxNL
- 10-9-2025 Modbus registers V2 vs V3 @FirefoxNL

Perfect!

Maar kunnen de V3 registers niet ook in @pascallj zijn sheet worden meegenomen in extra kolom, bijvoorbeeld V1, V2, V3, All, V1+V2 , V2+V3?

[ Voor 6% gewijzigd door WargamingPlayer op 10-09-2025 12:23 ]

[pascallj]

WargamingPlayer schreef op woensdag 10 september 2025 @ 12:22:
[...]

Perfect!

Maar kunnen de V3 registers niet ook in @pascallj zijn sheet worden meegenomen in extra tabblad?

Zeker dat zou kunnen, maar wacht daar nog eventjes mee tot er meer bekend wordt. Mocht dat niet gebeuren, dan zal ik alles wat we tot nu toe hebben erin zetten.

Mocht iemand overigens een V3 willen doneren kan ik ook zelf testen

[ Voor 8% gewijzigd door pascallj op 10-09-2025 12:23 ]

[bvansteenselen]

goedemiddag,

ik heb de ew geinstaleerd echter komt bij mij de modbus niet in integraties, ik heb hacks er al wel in terwijl dit ook een package is

@[RNMC] Viper is er een aangepaste Yaml voor docker sinds de nieuwe update van Ha?

het is inmiddels gelukt doormiddel van deze link https://www.hacs.xyz/docs/faq/custom_repositories/

[ Voor 20% gewijzigd door bvansteenselen op 12-09-2025 17:10 . Reden: is gelukt ]

[[RNMC] Viper]

Goed om te horen.

[ Voor 85% gewijzigd door [RNMC] Viper op 12-09-2025 17:22 ]

[gho]

HELP HELP BESTE TWEAKERS !!

Ondanks de instructies van Superduper 1969 loop ik toch tegen problemen aan bij de ModBus koppeling van de LilyGo aan de Marstek Venus v2 batterij hierbij gebruik ik overigens de hardware HA -GREEN en TP Link Deco _lot.
Home Assistant is voorzien van SecretsYaml, plus extra WiFi aangevulde IP use_adress.

 Met Marstek handvat V2 Batterij gekozen voor de lilygo-rs485-2.yaml, neem aan dat dit de juiste versie is. (??)

- Batterij en CT003 werken al maanden Ok met elkaar:
- Voor ESP Home builder TOCH GEEN WiFI connectie.
Wat trouwens ook al bij het compilereer proces al wordt vermeld, ra ra??? Zie bijlage

ESPHome builder in HA-GREEN heeft naast EDIT-LOGS knop GEEN VIEUW knop, doch VISIT knop waarbij je wordt doorgelinkt naar de TP Link Webpage.

Kortom geheel geen teken van leven, de LilyGo geeft wel een rode LED bij koppeling met de PC

Zend hierbij de loggegevens, hopelijk kunnen jullie mij ondersteuning hierbij bieden a.u.b.

Alvast erg bedankt, groeten George

hierbij Compileer log:
INFO ESPHome 2025.7.5
INFO Reading configuration /config/esphome/lilygo-rs485.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing lilygo-rs485-2 (board: esp32dev; framework: arduino; platform: https://github.com/pioard.../platform-espressif32.zip)
--------------------------------------------------------------------------------
Library Manager: Installing ESP32Async/AsyncTCP @ 3.4.5
INFO Installing ESP32Async/AsyncTCP @ 3.4.5
Unpacking [####################################] 100%
Library Manager: AsyncTCP@3.4.5 has been installed!
INFO AsyncTCP@3.4.5 has been installed!
Library Manager: Installing ESP32Async/ESPAsyncWebServer @ 3.7.10
INFO Installing ESP32Async/ESPAsyncWebServer @ 3.7.10
Unpacking [####################################] 100%
Library Manager: ESPAsyncWebServer@3.7.10 has been installed!
INFO ESPAsyncWebServer@3.7.10 has been installed!
Library Manager: Resolving dependencies...
INFO Resolving dependencies...
Library Manager: Installing esphome/noise-c @ 0.1.10
INFO Installing esphome/noise-c @ 0.1.10
Unpacking [####################################] 100%
Library Manager: noise-c@0.1.10 has been installed!
INFO noise-c@0.1.10 has been installed!
Library Manager: Resolving dependencies...
INFO Resolving dependencies...
Library Manager: Installing esphome/libsodium @ 1.10020.7
INFO Installing esphome/libsodium @ 1.10020.7
Unpacking [####################################] 100%
Library Manager: libsodium@1.10020.7 has been installed!
INFO libsodium@1.10020.7 has been installed!
Library Manager: Installing bblanchon/ArduinoJson @ 7.4.2
INFO Installing bblanchon/ArduinoJson @ 7.4.2
Unpacking [####################################] 100%
Library Manager: ArduinoJson@7.4.2 has been installed!
INFO ArduinoJson@7.4.2 has been installed!
Library Manager: Installing makuna/NeoPixelBus @ 2.8.0
INFO Installing makuna/NeoPixelBus @ 2.8.0
Unpacking [####################################] 100%
Library Manager: NeoPixelBus@2.8.0 has been installed!
INFO NeoPixelBus@2.8.0 has been installed!
Library Manager: Resolving dependencies...
INFO Resolving dependencies...
Library Manager: Installing SPI
INFO Installing SPI
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
- framework-arduinoespressif32 @ 3.1.3
- framework-arduinoespressif32-libs @ 5.3.0+sha.489d7a2b3a
- tool-esptoolpy @ 4.8.6
- tool-mklittlefs @ 3.2.0
- tool-riscv32-esp-elf-gdb @ 14.2.0+20240403
- tool-xtensa-esp-elf-gdb @ 14.2.0+20240403
- toolchain-xtensa-esp-elf @ 13.2.0+20240530
Installing Arduino Python dependencies
Collecting wheel>=0.35.1
Downloading wheel-0.45.1-py3-none-any.whl.metadata (2.3 kB)
Downloading wheel-0.45.1-py3-none-any.whl (72 kB)
Installing collected packages: wheel
Successfully installed wheel-0.45.1
Dependency Graph
|-- Networking @ 3.1.3
|-- AsyncTCP @ 3.4.5
|-- WiFi @ 3.1.3
|-- FS @ 3.1.3
|-- Update @ 3.1.3
|-- ESPAsyncWebServer @ 3.7.10
|-- ESPmDNS @ 3.1.3
|-- noise-c @ 0.1.10
|-- ArduinoJson @ 7.4.2
|-- NeoPixelBus @ 2.8.0
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/api/api_connection.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/api/api_frame_helper.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/api/api_pb2.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/api/api_pb2_service.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/api/api_server.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/api/list_entities.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/api/proto.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/api/subscribe_state.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/binary_sensor/automation.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/binary_sensor/binary_sensor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/binary_sensor/filter.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/copy/sensor/copy_sensor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/esp32/core.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/esp32/gpio.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/esp32/helpers.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/esp32/preferences.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/esphome/ota/ota_esphome.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/gpio/output/gpio_binary_output.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/json/json_util.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/light/addressable_light.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/light/automation.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/light/esp_color_correction.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/light/esp_hsv_color.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/light/esp_range_view.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/light/light_call.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/light/light_json_schema.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/light/light_output.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/light/light_state.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/logger/logger.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/logger/logger_esp32.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/logger/task_log_buffer.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/md5/md5.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/mdns/mdns_component.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/mdns/mdns_esp32.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/modbus/modbus.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/modbus_controller/binary_sensor/modbus_binarysensor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/modbus_controller/modbus_controller.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/modbus_controller/number/modbus_number.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/modbus_controller/select/modbus_select.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/modbus_controller/sensor/modbus_sensor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/modbus_controller/text_sensor/modbus_textsensor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/network/util.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/number/automation.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/number/number.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/number/number_call.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/number/number_traits.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/ota/ota_backend.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/ota/ota_backend_arduino_esp32.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/output/automation.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/output/float_output.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/safe_mode/safe_mode.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/select/select.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/select/select_call.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/select/select_traits.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/sensor/automation.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/sensor/filter.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/sensor/sensor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/socket/bsd_sockets_impl.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/socket/socket.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/status/status_binary_sensor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/template/sensor/template_sensor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/template/text_sensor/template_text_sensor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/text_sensor/filter.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/text_sensor/text_sensor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/uart/uart.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/uart/uart_component.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/uart/uart_component_esp32_arduino.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/uart/uart_debugger.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/version/version_text_sensor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/web_server/list_entities.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/web_server/web_server.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/web_server/web_server_v1.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/web_server_base/web_server_base.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/wifi/wifi_component.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/wifi/wifi_component_esp32_arduino.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/wifi_info/wifi_info_text_sensor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/components/wifi_signal/wifi_signal_sensor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/core/application.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/core/color.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/core/component.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/core/component_iterator.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/core/controller.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/core/entity_base.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/core/helpers.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/core/log.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/core/ring_buffer.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/core/scheduler.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/core/string_ref.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/core/time.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/esphome/core/util.cpp.o
Compiling .pioenvs/lilygo-rs485-2/src/main.cpp.o
Building .pioenvs/lilygo-rs485-2/bootloader.bin
Creating esp32 image...
Successfully created esp32 image.
Generating partitions .pioenvs/lilygo-rs485-2/partitions.bin
In file included from .piolibdeps/lilygo-rs485-2/NeoPixelBus/src/internal/methods/NeoEsp32RmtMethod.h:49,
from .piolibdeps/lilygo-rs485-2/NeoPixelBus/src/internal/NeoMethods.h:59,
from .piolibdeps/lilygo-rs485-2/NeoPixelBus/src/NeoPixelBus.h:43,
from src/esphome/components/neopixelbus/neopixelbus_light.h:12,
from src/esphome.h:56,
from src/main.cpp:3:
/data/cache/platformio/packages/framework-arduinoespressif32-libs/esp32/include/driver/deprecated/driver/rmt.h:18:2: warning: #warning "The legacy RMT driver is deprecated, please use driver/rmt_tx.h and/or driver/rmt_rx.h" [-Wcpp]
18 | #warning "The legacy RMT driver is deprecated, please use driver/rmt_tx.h and/or driver/rmt_rx.h"
| ^~~~~~~
Compiling .pioenvs/lilygo-rs485-2/lib4c5/Network/NetworkClient.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib4c5/Network/NetworkEvents.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib4c5/Network/NetworkInterface.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib4c5/Network/NetworkManager.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib4c5/Network/NetworkServer.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib4c5/Network/NetworkUdp.cpp.o
Compiling .pioenvs/lilygo-rs485-2/liba30/AsyncTCP/AsyncTCP.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib64d/WiFi/AP.cpp.o
Archiving .pioenvs/lilygo-rs485-2/lib4c5/libNetwork.a
Compiling .pioenvs/lilygo-rs485-2/lib64d/WiFi/STA.cpp.o
Archiving .pioenvs/lilygo-rs485-2/liba30/libAsyncTCP.a
Compiling .pioenvs/lilygo-rs485-2/lib64d/WiFi/WiFi.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib64d/WiFi/WiFiAP.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib64d/WiFi/WiFiGeneric.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib64d/WiFi/WiFiMulti.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib64d/WiFi/WiFiSTA.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib64d/WiFi/WiFiScan.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib01c/FS/FS.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib01c/FS/vfs_api.cpp.o
Archiving .pioenvs/lilygo-rs485-2/lib64d/libWiFi.a
Compiling .pioenvs/lilygo-rs485-2/libbc6/Update/HttpsOTAUpdate.cpp.o
Compiling .pioenvs/lilygo-rs485-2/libbc6/Update/Updater.cpp.o
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/AsyncEventSource.cpp.o
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/AsyncJson.cpp.o
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/AsyncMessagePack.cpp.o
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/AsyncWebHeader.cpp.o
Archiving .pioenvs/lilygo-rs485-2/lib01c/libFS.a
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/AsyncWebServerRequest.cpp.o
Archiving .pioenvs/lilygo-rs485-2/libbc6/libUpdate.a
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/AsyncWebSocket.cpp.o
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/BackPort_SHA1Builder.cpp.o
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/ChunkPrint.cpp.o
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/Middleware.cpp.o
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/WebAuthentication.cpp.o
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/WebHandlers.cpp.o
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/WebRequest.cpp.o
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/WebResponses.cpp.o
Compiling .pioenvs/lilygo-rs485-2/liba37/ESPAsyncWebServer/WebServer.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib915/ESPmDNS/ESPmDNS.cpp.o
Archiving .pioenvs/lilygo-rs485-2/lib915/libESPmDNS.a
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_core/ed25519/ref10/ed25519_ref10.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_core/salsa/ref/core_salsa_ref.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_hash/crypto_hash.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_hash/sha256/cp/hash_sha256_cp.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_hash/sha256/hash_sha256.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_onetimeauth/crypto_onetimeauth.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_onetimeauth/poly1305/donna/poly1305_donna.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_onetimeauth/poly1305/onetimeauth_poly1305.c.o
Archiving .pioenvs/lilygo-rs485-2/liba37/libESPAsyncWebServer.a
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_scalarmult/crypto_scalarmult.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_scalarmult/curve25519/ref10/x25519_ref10.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_scalarmult/curve25519/scalarmult_curve25519.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_stream/chacha20/ref/chacha20_ref.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_stream/chacha20/stream_chacha20.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_stream/crypto_stream.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_stream/salsa20/ref/salsa20_ref.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_stream/salsa20/stream_salsa20.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_stream/salsa20/xmm6/salsa20_xmm6-asm.S.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_stream/salsa20/xmm6/salsa20_xmm6.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_stream/salsa20/xmm6int/salsa20_xmm6int-avx2.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_stream/salsa20/xmm6int/salsa20_xmm6int-sse2.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/crypto_verify/verify.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/randombytes/internal/randombytes_internal_random.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/randombytes/randombytes.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/randombytes/sysrandom/randombytes_sysrandom.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/sodium/codecs.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/sodium/core.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/sodium/runtime.c.o
Compiling .pioenvs/lilygo-rs485-2/libb0c/libsodium/sodium/utils.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/backend/openssl/cipher-aesgcm.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/backend/ref/cipher-aesgcm.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/backend/ref/cipher-chachapoly.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/backend/ref/dh-curve25519.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/backend/ref/hash-blake2b.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/backend/ref/hash-blake2s.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/backend/ref/hash-sha256.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/backend/sodium/cipher-aesgcm.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/backend/sodium/cipher-chachapoly.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/backend/sodium/dh-curve25519.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/backend/sodium/hash-blake2b.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/backend/sodium/hash-sha256.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/crypto/aes/rijndael-alg-fst.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/crypto/blake2/blake2b.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/crypto/blake2/blake2s.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/crypto/chacha/chacha.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/crypto/donna/curve25519-donna-c64.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/crypto/donna/curve25519-donna.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/crypto/donna/poly1305-donna.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/crypto/sha2/sha256.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/crypto/sha2/sha512.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/crypto/x25519/x25519.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/cipherstate.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/dhstate.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/errors.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/handshakestate.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/hashstate.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/internal.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/names.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/patterns.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/rand_os.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/rand_sodium.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/randstate.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/signstate.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/symmetricstate.c.o
Compiling .pioenvs/lilygo-rs485-2/lib9cf/noise-c/protocol/util.c.o
Compiling .pioenvs/lilygo-rs485-2/lib6b4/SPI/SPI.cpp.o
Archiving .pioenvs/lilygo-rs485-2/lib9cf/libnoise-c.a
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/animations/NeoPixelAnimator.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/HsbColor.cpp.o
Archiving .pioenvs/lilygo-rs485-2/libb0c/libsodium.a
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/HslColor.cpp.o
In file included from .piolibdeps/lilygo-rs485-2/NeoPixelBus/src/internal/methods/NeoEsp32RmtMethod.h:49,
from .piolibdeps/lilygo-rs485-2/NeoPixelBus/src/internal/NeoMethods.h:59,
from .piolibdeps/lilygo-rs485-2/NeoPixelBus/src/NeoPixelBus.h:43,
from .piolibdeps/lilygo-rs485-2/NeoPixelBus/src/internal/animations/NeoPixelAnimator.cpp:28:
/data/cache/platformio/packages/framework-arduinoespressif32-libs/esp32/include/driver/deprecated/driver/rmt.h:18:2: warning: #warning "The legacy RMT driver is deprecated, please use driver/rmt_tx.h and/or driver/rmt_rx.h" [-Wcpp]
18 | #warning "The legacy RMT driver is deprecated, please use driver/rmt_tx.h and/or driver/rmt_rx.h"
| ^~~~~~~
Archiving .pioenvs/lilygo-rs485-2/lib6b4/libSPI.a
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/HtmlColor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/HtmlColorNameStrings.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/HtmlColorNames.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/HtmlColorShortNames.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/NeoGammaDynamicTableMethod.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/NeoGammaTableMethod.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/Rgb48Color.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/RgbColor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/RgbColorBase.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/Rgbw64Color.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/RgbwColor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/Rgbww80Color.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/RgbwwColor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/RgbwwwColor.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/colors/SegmentDigit.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/methods/Esp32_i2s.c.o
In file included from /data/cache/platformio/packages/framework-arduinoespressif32-libs/esp32/include/driver/deprecated/driver/i2s.h:23,
from .piolibdeps/lilygo-rs485-2/NeoPixelBus/src/internal/methods/Esp32_i2s.c:53:
/data/cache/platformio/packages/framework-arduinoespressif32-libs/esp32/include/driver/deprecated/driver/adc.h:19:2: warning: #warning "legacy adc driver is deprecated, please migrate to use esp_adc/adc_oneshot.h and esp_adc/adc_continuous.h for oneshot mode and continuous mode drivers respectively" [-Wcpp]
19 | #warning "legacy adc driver is deprecated, please migrate to use esp_adc/adc_oneshot.h and esp_adc/adc_continuous.h for oneshot mode and continuous mode drivers respectively"
| ^~~~~~~
/data/cache/platformio/packages/framework-arduinoespressif32-libs/esp32/include/driver/deprecated/driver/i2s.h:27:2: warning: #warning "This set of I2S APIs has been deprecated, please include 'driver/i2s_std.h', 'driver/i2s_pdm.h' or 'driver/i2s_tdm.h' instead. if you want to keep using the old APIs and ignore this warning, you can enable 'Suppress legacy driver deprecated warning' option under 'I2S Configuration' menu in Kconfig" [-Wcpp]
27 | #warning "This set of I2S APIs has been deprecated, \
| ^~~~~~~
In file included from .piolibdeps/lilygo-rs485-2/NeoPixelBus/src/internal/methods/Esp32_i2s.c:61:
/data/cache/platformio/packages/framework-arduinoespressif32-libs/esp32/include/driver/deprecated/driver/dac.h:16:2: warning: #warning "The legacy DAC driver is deprecated, please use `driver/dac_oneshot.h`, `driver/dac_cosine.h` or `driver/dac_continuous.h` instead" [-Wcpp]
16 | #warning "The legacy DAC driver is deprecated, please use `driver/dac_oneshot.h`, `driver/dac_cosine.h` or `driver/dac_continuous.h` instead"
| ^~~~~~~
.piolibdeps/lilygo-rs485-2/NeoPixelBus/src/internal/methods/Esp32_i2s.c:780:1: warning: ignoring attribute 'section (".iram1.1")' because it conflicts with previous 'section (".iram1.0")' [-Wattributes]
780 | {
| ^
.piolibdeps/lilygo-rs485-2/NeoPixelBus/src/internal/methods/Esp32_i2s.c:133:16: note: previous declaration here
133 | void IRAM_ATTR i2sDmaISR(void* arg);
| ^~~~~~~~~
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/methods/NeoEsp32RmtMethod.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/methods/NeoEsp8266I2sMethodCore.cpp.o
In file included from .piolibdeps/lilygo-rs485-2/NeoPixelBus/src/internal/methods/NeoEsp32RmtMethod.h:49,
from .piolibdeps/lilygo-rs485-2/NeoPixelBus/src/internal/methods/NeoEsp32RmtMethod.cpp:36:
/data/cache/platformio/packages/framework-arduinoespressif32-libs/esp32/include/driver/deprecated/driver/rmt.h:18:2: warning: #warning "The legacy RMT driver is deprecated, please use driver/rmt_tx.h and/or driver/rmt_rx.h" [-Wcpp]
18 | #warning "The legacy RMT driver is deprecated, please use driver/rmt_tx.h and/or driver/rmt_rx.h"
| ^~~~~~~
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/methods/NeoEsp8266UartMethod.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/methods/NeoEspBitBangMethod.cpp.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/methods/NeoPixelAvr.c.o
Compiling .pioenvs/lilygo-rs485-2/lib931/NeoPixelBus/internal/methods/Rp2040/NeoRp2040PioMonoProgram.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/ColorFormat.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/Esp.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/FirmwareMSC.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/FunctionalInterrupt.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/HEXBuilder.cpp.o
Archiving .pioenvs/lilygo-rs485-2/lib931/libNeoPixelBus.a
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/HWCDC.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/HardwareSerial.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/IPAddress.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/MD5Builder.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/MacAddress.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/Print.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/SHA1Builder.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/Stream.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/StreamString.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/Tone.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/USB.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/USBCDC.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/USBMSC.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/WMath.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/WString.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/base64.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/cbuf.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/chip-debug-report.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-adc.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-bt.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-cpu.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-dac.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-gpio.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-i2c-slave.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-i2c.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-ledc.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-matrix.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-misc.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-periman.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-psram.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-rgb-led.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-rmt.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-sigmadelta.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-spi.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-time.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-timer.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-tinyusb.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-touch-ng.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-touch.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/esp32-hal-uart.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/firmware_msc_fat.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/freertos_stats.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/libb64/cdecode.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/libb64/cencode.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/main.cpp.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/stdlib_noniso.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/wiring_pulse.c.o
Compiling .pioenvs/lilygo-rs485-2/FrameworkArduino/wiring_shift.c.o
Archiving .pioenvs/lilygo-rs485-2/libFrameworkArduino.a
Linking .pioenvs/lilygo-rs485-2/firmware.elf
RAM: [= ] 14.8% (used 48392 bytes from 327680 bytes)
Flash: [======= ] 72.7% (used 1334020 bytes from 1835008 bytes)
Building .pioenvs/lilygo-rs485-2/firmware.bin
Creating esp32 image...
Successfully created esp32 image.
esp32_create_combined_bin([".pioenvs/lilygo-rs485-2/firmware.bin"], [".pioenvs/lilygo-rs485-2/firmware.elf"])
SHA digest in image updated
Wrote 0x155c70 bytes to file /data/build/lilygo-rs485-2/.pioenvs/lilygo-rs485-2/firmware.factory.bin, ready to flash to offset 0x0
esp32_copy_ota_bin([".pioenvs/lilygo-rs485-2/firmware.bin"], [".pioenvs/lilygo-rs485-2/firmware.elf"])
======================== [SUCCESS] Took 825.66 seconds ========================
INFO Successfully compiled program.
INFO Resolving IP address of lilygo-rs485-2.local in mDNS
INFO Resolving IP address of lilygo-rs485-2.local
ERROR Error resolving IP address of lilygo-rs485-2.local. Is it connected to WiFi?
ERROR (If this error persists, please set a static IP address: https://esphome.io/components/wifi.html#manual-ips)
ERROR Error resolving IP address: Error resolving address with mDNS: Did not respond. Maybe the device is offline., [Errno -5] No address associated with hostname

[superduper1969]

gho schreef op zaterdag 13 september 2025 @ 09:39:
HELP HELP BESTE TWEAKERS !!

The legacy RMT driver is deprecated, please use driver/rmt_tx.h and/or driver/rmt_rx.h"

Je gebruikt in ieder geval oude code want ik ben al tijden over naar een nieuwe led driver.
En als je geen wifi hebt is er wat mis met je Secrets.
Er is een aparte Secrets voor ESP-Home zie rechterbovenhoek.


Alles tussen " " ?

[gho]

Dank voor de snelle reactie, secrets staan ook bij mij rechtsboven vermeld tussen aanhalingstekens.

Waar en hoe vind ik de nieuw led driver en hoe te verwerken?

[r03n_d]

[b]gho schreef op zaterdag 13 september 2025 @ 09:39:

Met Marstek handvat V2 Batterij gekozen voor de lilygo-rs485-2.yaml, neem aan dat dit de juiste versie is. (??)

Nee, van hoe ik het begrijp is die alleen voor als je meerdere batterijen hebt. Gebruik gewoon de lilygo-rs485.yaml. Die gebruik ik ook met de V2 en werkt goed.

[ Voor 16% gewijzigd door r03n_d op 13-09-2025 12:16 . Reden: URL toegevoegd ]

[gho]

Ok dan ga ik alles overnieuw doen met de gewone eerste versie en misschien ligt het daar inderdaad aan, bedankt voor de reactie u hoort binnenkort of dat wel werkt

[gho]

gewone versie geïnstalleerd, en toch zelfde foutmelding

WARNING Can't connect to ESPHome API for lilygo-rs485 @ 192.....: Error connecting to [AddrInfo(family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, proto=6, sockaddr=IPv4Sockaddr(address='192....', port=6053))]: [Errno 111] Connect call failed ('192...., 6053) (SocketAPIError)

terwijl de juiste secrets.yaml is benoemd...

[pascallj]

gho schreef op zaterdag 13 september 2025 @ 14:27:
gewone versie geïnstalleerd, en toch zelfde foutmelding

WARNING Can't connect to ESPHome API for lilygo-rs485 @ 192.....: Error connecting to [AddrInfo(family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, proto=6, sockaddr=IPv4Sockaddr(address='192....', port=6053))]: [Errno 111] Connect call failed ('192...., 6053) (SocketAPIError)

terwijl de juiste secrets.yaml is benoemd...

Heb je de LilyGo überhaupt wel een keer via USB geflashed? Hij probeert na het compileren via WiFi te gaan flashen, maar als er nog geen werkende firmware opstaat (die je dus de eerste keer via USB geflashed hebt) zit het apparaat niet in je netwerk en kan het dus niet draadloos geflashed worden.

Als je dat wel al een keer gedaan hebt, moet het apparaat wel op hetzelfde netwerk zitten als Home assistant. Ze moeten elkaar kunnen bereiken, dus geen IOT- of gastnetwerk met scheiding tussen de clients o.i.d.

[gho]

NFO Trying to connect to lilygo-rs485 @ 192......in the background
en
vervolgens in groen
INFO Successfully resolved lilygo-rs485 @ 192.... in 0.000s

wel verbinding doch klaarblijkelijk niet via secrets .yaml..

[gho]

pascallj schreef op zaterdag 13 september 2025 @ 14:38:
[...]


Heb je de LilyGo überhaupt wel een keer via USB geflashed? Hij probeert na het compileren via WiFi te gaan flashen, maar als er nog geen werkende firmware opstaat (die je dus de eerste keer via USB geflashed hebt) zit het apparaat niet in je netwerk en kan het dus niet draadloos geflashed worden.

Als je dat wel al een keer gedaan hebt, moet het apparaat wel op hetzelfde netwerk zitten als Home assistant. Ze moeten elkaar kunnen bereiken, dus geen IOT- of gastnetwerk met scheiding tussen de clients o.i.d.

Ja wel via USB geflashed na bin bestand te hebben opgeslagen, AHA ik zal de boel van mijn IOT verbinding moeten halen naar de gewone, eerst dat in gang zetten, dank u

[pascallj]

gho schreef op zaterdag 13 september 2025 @ 14:56:
[...]


Ja wel via USB geflashed na bin bestand te hebben opgeslagen, AHA ik zal de boel van mijn IOT verbinding moeten halen naar de gewone, eerst dat in gang zetten, dank u

Een IOT netwerk zou wel kunnen, alleen vaak wordt er daar standaard cliënt scheiding toegepast. Als je dat los kan uitzetten, is het ook goed.

Maar ik zie in je vorige bericht dat je nu wel verbinding krijgt met het flashen via WiFi. Is dat ook op de Green of op een ander apparaat?

[gho]

pascallj schreef op zaterdag 13 september 2025 @ 14:58:
[...]


Een IOT netwerk zou wel kunnen, alleen vaak wordt er daar standaard cliënt scheiding toegepast. Als je dat los kan uitzetten, is het ook goed.

Maar ik zie in je vorige bericht dat je nu wel verbinding krijgt met het flashen via WiFi. Is dat ook op de Green of op een ander apparaat?

Nee dat is de log via USB koppeling met de LilY waarin eerst de Wifi foutmelding komt welke zich vrij snel zelf hersteld en wel verbinding zegt te hebben..

[pascallj]

gho schreef op zaterdag 13 september 2025 @ 15:03:
[...]

Nee dat is de log via USB koppeling met de LilY waarin eerst de Wifi foutmelding komt welke zich vrij snel zelf hersteld en wel verbinding zegt te hebben..

Die 'succesfully resolved' melding geeft toch echt aan dat hij het apparaat heeft kunnen vinden op het netwerk. Dus als dat ook op de Green is (ik heb geen idee of dat allemaal kan, ik doe zelf altijd alles in de terminal), dan is het geen verbindingsprobleem (meer).

[gho]

pascallj schreef op zaterdag 13 september 2025 @ 15:07:
[...]


Die 'succesfully resolved' melding geeft toch echt aan dat hij het apparaat heeft kunnen vinden op het netwerk. Dus als dat ook op de Green is (ik heb geen idee of dat allemaal kan, ik doe zelf altijd alles in de terminal), dan is het geen verbindingsprobleem (meer).

Klopt dat er weliswaar in 2e instantie na foutmelding pas verbinding is gemaakt via ip adres, maar m.i ook dat de secrets.yaml geen verbinding, daarvan heb Iot Wifi verwijderd en TpLink Deco vermeld met zelfde non wifiverbinding start.
Weet niet of het aan hardware Home assistant green ligt waarbij EspHome geen view knop maar visit knop

[superduper1969]

gho schreef op zaterdag 13 september 2025 @ 16:29:
[...]
Weet niet of het aan hardware Home assistant green ligt waarbij EspHome geen view knop maar visit knop

Knop heet inderdaad "Visit", ik heb het aangepast in startpost.
lilygo-rs485.yaml is voor de eerste batterij maakt niet uit voor een V1 of V2
lilygo-rs485-2.yaml is voor de 2e
lilygo-rs485-3.yaml is voor de 3e
MarstekVenus-Lilygo-T-POE-Pro.yaml is voor de versie met een UTP aansluiting.

Als je lilygo-rs485.yaml een paar weken/maanden geleden hebt gedownload moet je dat opnieuw doen voor de meeste recente versie. Daar zit de fix in voor de LED driver = obsolete meldingen.

Bekijk nog een keer een filmpje over ESP home, misschien kom je er dan achter wat je anders doet.
https://www.youtube.com/watch?v=UI8Xjl7nwsI

En anders kun je screenshots van foutmeldingen in een AI zoals Gemini plakken om je een hint te geven.

[ Voor 57% gewijzigd door superduper1969 op 13-09-2025 20:14 ]

[gho]

superduper1969 schreef op zaterdag 13 september 2025 @ 19:57:
[...]

Knop heet inderdaad "Visit", ik heb het aangepast in startpost.
lilygo-rs485.yaml is voor de eerste batterij maakt niet uit voor een V1 of V2
lilygo-rs485-2.yaml is voor de 2e
lilygo-rs485-3.yaml is voor de 3e
MarstekVenus-Lilygo-T-POE-Pro.yaml is voor de versie met een UTP aansluiting.

Als je lilygo-rs485.yaml een paar weken/maanden geleden hebt gedownload moet je dat opnieuw doen voor de meeste recente versie. Daar zit de fix in voor de LED driver = obsolete meldingen.

Bekijk nog een keer een filmpje over ESP home, misschien kom je er dan achter wat je anders doet.
https://www.youtube.com/watch?v=UI8Xjl7nwsI

En anders kun je screenshots van foutmeldingen in een AI zoals Gemini plakken om je een hint te geven.

Dank Superduper, zal video goed bekijken en vlgs mij heb ik de versie van ca 3 weken gedownload, maar voor de zekerheid opnieuw doen.
Hopelijk lukt het de Wifi alsnog via secrets te activeren met niet Lot netwerk,..

superduper1969 schreef op zaterdag 13 september 2025 @ 19:57:
[...]

Knop heet inderdaad "Visit", ik heb het aangepast in startpost.
lilygo-rs485.yaml is voor de eerste batterij maakt niet uit voor een V1 of V2
lilygo-rs485-2.yaml is voor de 2e
lilygo-rs485-3.yaml is voor de 3e
MarstekVenus-Lilygo-T-POE-Pro.yaml is voor de versie met een UTP aansluiting.

Als je lilygo-rs485.yaml een paar weken/maanden geleden hebt gedownload moet je dat opnieuw doen voor de meeste recente versie. Daar zit de fix in voor de LED driver = obsolete meldingen.

Bekijk nog een keer een filmpje over ESP home, misschien kom je er dan achter wat je anders doet.
https://www.youtube.com/watch?v=UI8Xjl7nwsI

En anders kun je screenshots van foutmeldingen in een AI zoals Gemini plakken om je een hint te geven.

Dank Superduper, zal video goed bekijken, knelpunt lijkt me dat aanwezige Secret.yaml Wifi niet koppelt. Zal Lot wijzigen in reguliere TP Link en verder speuren, doch altijd open voor suggesties en tips

[gho]

Sorry dacht dat eerste quote verdwenen was vandaar

[pj]

Nav post in 'gewone' topic hier maar verder:

Ik heb inmiddels de code van @fonske (MarstekVenus-M5stackRS485) in die van @superduper1969 (MarstekVenus-LilygoRS485) gezet, En daarmee krijg waardes in EVCC.

Helaas krijg ik inderdaad dropouts van Vermogen (AC Power) en Laden (Soc). Zoals @AUijtdehaag al voorspelde.

battery 1 power: read failed: dial tcp 192.168.0.220:502: i/o timeout

5 seconden geleden
2025-09-14 11:01:03.246510846 +0200 CEST m=+1596.609295094 !! 4145ms read failed: read tcp 192.168.0.150:52154->192.168.0.220:502: i/o timeout\n2025-09-14 11:01:07.418712794 +0200 CEST m=+1600.781497046 !! 3000ms read failed: dial tcp 192.168.0.220:502: i/o timeout\n2025-09-14 11:01:10.46199585 +0200 CEST m=+1603.824780102 !! 3000ms read failed: dial tcp 192.168.0.220:502: i/o timeout

5 minuten geleden
battery 1 soc: read failed: read tcp 192.168.0.150:54960->192.168.0.220:502: i/o timeout

18 minuten geleden
battery 1 power: read failed: modbus: response data size '2' does not match request quantity '2'
2

18 minuten geleden
2025-09-14 10:43:30.578358171 +0200 CEST m=+543.941142363 !! 442ms read failed: modbus: response data is empty\n2025-09-14 10:43:31.039003301 +0200 CEST m=+544.401787552 !! 967ms read failed: modbus: response data is empty\n2025-09-14 10:43:32.049106568 +0200 CEST m=+545.411890820 !! 962ms read failed: modbus: response data is empty\n2025-09-14 10:43:33.041261414 +0200 CEST m=+546.404045665 !! 2450ms read failed: modbus: response data size '2' does not match request quantity '2'\n2025-09-14 10:43:35.541024628 +0200 CEST m=+548.903808877 !! 3579ms read failed: modbus: response unit id '255' does not match request '1'\n2025-09-14 10:43:39.262989913 +0200 CEST m=+552.625774200 !! 2229ms read failed: modbus: response data size '2' does not match request quantity '2'

19 minuten geleden
2025-09-14 10:42:15.101661399 +0200 CEST m=+468.464445649 !! 1449ms read failed: modbus: response data is empty\n2025-09-14 10:42:16.563949109 +0200 CEST m=+469.926733357 !! 991ms read failed: modbus: response data is empty\n2025-09-14 10:42:17.576538947 +0200 CEST m=+470.939323198 !! 982ms read failed: modbus: response data is empty\n2025-09-14 10:42:18.627349459 +0200 CEST m=+471.990133707 !! 939ms read failed: modbus: response data is empty\n2025-09-14 10:42:19.627052523 +0200 CEST m=+472.989836774 !! 944ms read failed: modbus: response data is empty\n2025-09-14 10:42:20.677320484 +0200 CEST m=+474.040104732 !! 921ms read failed: modbus: response data is empty\n2025-09-14 10:42:21.717244148 +0200 CEST m=+475.080028400 !! 2370ms read failed: modbus: response data is empty\n2025-09-14 10:42:24.321957487 +0200 CEST m=+477.684741739 !! 1072ms read failed: modbus: response data size '2' does not match request quantity '2'

Het lijkt erop dat de het modbusbericht out of sync loopt met het verzenden via de modbus_bridge.

Ik heb te weinig kaas gegeten van ESP32 om te weten welke richting ik op moet zoeken. Pielen met de intervals maakt iig weinig uit.

Iemand?

code:

esphome:
  name: lilygo-rs485
  friendly_name: LILYGO RS485
  min_version: 2024.11.0
  name_add_mac_suffix: false

esp32:
  board: esp32dev
  framework:
    type: arduino

## Modbus TCP/IP external component
external_components:
  - source:
      type: git
      url: https://github.com/rosenrot00/esphome_modbus_bridge
    components: [modbus_bridge]
    refresh: always

# Enable logging
logger:
  # level: VERY_VERBOSE
  
# Enable Home Assistant API
api:
  encryption:
    key: "PS5dgQCKNf1ryMlYxyRdlQaQ1CKoTO+bzpDp22B8Pkk="

ota:
  - platform: esphome
    password: "5714500323d3bd5904a30838b1ace193"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Lilygo-Rs485 Fallback Hotspot"
    password: "GBDjgqkttbFLa93eFCaj"

web_server:
  port: 80
  version: 3
  include_internal: False
#  ota: False
  local: True
  sorting_groups:
    - id: Info
      name: "Info"
      sorting_weight: -40
    - id: Control
      name: "Control"
      sorting_weight: -30
    - id: Status
      name: "Status"
      sorting_weight: -20
    - id: Diagnostic
      name: "Diagnostic"
      sorting_weight: -10

# Set pins required for LilyGo T-CAN485 board
output:
  - platform: gpio
    id: ENABLE_PIN # Enable the chip
    pin:
      number: GPIO19
      inverted: true

  - platform: gpio
    id: SE_PIN # Enable autodirection
    pin:
      number: GPIO17
      inverted: true

  - platform: gpio
    id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip
    pin:
      number: GPIO16
      inverted: true

# Configure UART
uart:
  - id: mod_bus
    rx_pin: GPIO21
    tx_pin: GPIO22
    baud_rate: 115200
    data_bits: 8
    stop_bits: 1
    parity: NONE

## Configure MODBUS TCP/IP bridge
modbus_bridge:
    uart_id: mod_bus
    id: mb_bridge
    tcp_port: 502               # TCP port
    tcp_poll_interval: 500      # ms between TCP polls
    tcp_client_timeout: 100000   # ms inactivity until TCP client is disconnected
    tcp_allowed_clients: 1      # clamped to minimum 1, use with care as it increases memory usage
    rtu_response_timeout: 5000  # ms, clamped internally to minimum of 10 ms)

modbus:
  - uart_id: mod_bus
    id: modbus1
    send_wait_time: 20ms

modbus_controller:
  - id: mt
    address: 0x1
    modbus_id: modbus1
    command_throttle: 20ms
    update_interval: 2s

# Tekstsensoren
text_sensor:
  - platform: modbus_controller
    name: "Device Name"
    icon: mdi:rename-outline
    id: device_name
    modbus_controller_id: mt
    register_type: holding
    address: 31000
    register_count: 10
    response_size: 20
    skip_updates: 60 # 5 minutes
    entity_category: diagnostic
    web_server:
      sorting_group_id: Diagnostic
      sorting_weight: 7

  - platform: template
    name: "Software Version"
    id: software_version_text
    icon: mdi:factory
    update_interval: never  # updates only when sensor triggers
    entity_category: diagnostic
    web_server:
      sorting_group_id: Diagnostic
      sorting_weight: 8

  - platform: template
    name: "Firmware Version"
    id: firmware_version_text
    icon: mdi:factory
    update_interval: never  # updates only when sensor triggers
    entity_category: diagnostic
    web_server:
      sorting_group_id: Diagnostic
      sorting_weight: 9

  - platform: template
    name: "BMS Version"
    id: bms_version_text
    icon: mdi:factory
    update_interval: never  # updates only when sensor triggers
    entity_category: diagnostic
    web_server:
      sorting_group_id: Diagnostic
      sorting_weight: 10

  # - name: "Marstek SN Code"
  #   platform: modbus_controller
  #   modbus_controller_id: mt
  #   register_type: holding
  #   address: 31200
  #   register_count: 10
  #   response_size: 20
  #   skip_updates: 60 # 5 minutes

  - platform: template
    name: "Marstek Inverter State"
    lambda: |-
      switch (int(id(inverter_state).state)) {
        case 0: return std::string("Sleep");
        case 1: return std::string("Standby");
        case 2: return std::string("Charge");
        case 3: return std::string("Discharge");
        case 4: return std::string("Fault");
        case 5: return std::string("Idle");
        case 6: return std::string("AC bypass");
        default: return std::string("Unknown");
      };
    update_interval: 5s
    web_server:
      sorting_group_id: Info
      sorting_weight: 4

  - platform: wifi_info
    ip_address:
      name: ESP IP
      icon: mdi:ip
      web_server:
        sorting_group_id: Diagnostic
        sorting_weight: 4
    ssid:
      name: ESP SSID
      icon: mdi:wifi
      web_server:
        sorting_group_id: Diagnostic
        sorting_weight: 3

  - platform: version
    name: ESP Version
    hide_timestamp: true
    disabled_by_default: false
    icon: mdi:new-box
    entity_category: diagnostic
    web_server:
      sorting_group_id: Diagnostic
      sorting_weight: 2

  - platform: modbus_controller
    id: wifi_status
    name: "Wifi status"
    modbus_controller_id: mt
    register_type: holding
    address: 30300
    raw_encode: NONE
    icon: mdi:wifi-alert
    entity_category: diagnostic
    skip_updates: 20
    lambda: |-
      uint16_t int_mode = (data[item->offset] << 8) + data[item->offset+1];
      ESP_LOGD("main","Parsed operation mode int : %d", int_mode);
      std::string mode_str;
      switch (int_mode) {
        case 0:  mode_str = "Disconnected"; break;
        case 1:  mode_str = "Connected"; break;                                                              
      }
      return mode_str;
    web_server:
      sorting_group_id: Diagnostic
      sorting_weight: 20

  - platform: modbus_controller
    id: bt_status
    name: "BT status"
    modbus_controller_id: mt
    register_type: holding
    address: 30301
    raw_encode: NONE
    icon: mdi:home-heart
    entity_category: diagnostic
    skip_updates: 20
    lambda: |-
      uint16_t int_mode = (data[item->offset] << 8) + data[item->offset+1];
      ESP_LOGD("main","Parsed operation mode int : %d", int_mode);
      std::string mode_str;
      switch (int_mode) {
        case 0:  mode_str = "Off"; break;
        case 1:  mode_str = "Active after boot"; break;    
        case 2:  mode_str = "Connected"; break; 
        case 3:  mode_str = "Active"; break;                                                           
      }
      return mode_str;
    web_server:
      sorting_group_id: Diagnostic
      sorting_weight: 21

  - platform: modbus_controller
    id: cloud_status
    name: "Cloud status"
    modbus_controller_id: mt
    register_type: holding
    address: 30302
    raw_encode: NONE
    icon: mdi:home-heart
    entity_category: diagnostic
    skip_updates: 20
    lambda: |-
      uint16_t int_mode = (data[item->offset] << 8) + data[item->offset+1];
      ESP_LOGD("main","Parsed operation mode int : %d", int_mode);
      std::string mode_str;
      switch (int_mode) {
        case 0:  mode_str = "Disconnected"; break;
        case 1:  mode_str = "Connected"; break;                                                              
      }
      return mode_str;
    web_server:
      sorting_group_id: Diagnostic
      sorting_weight: 22

  - platform: modbus_controller
    id: power_restriction_discharge
    name: "Power restriction"
    modbus_controller_id: mt
    register_type: holding
    address: 41010
    raw_encode: NONE
    icon: mdi:home-heart
    entity_category: diagnostic
    skip_updates: 20
    lambda: |-
      uint16_t int_mode = (data[item->offset] << 8) + data[item->offset+1];
      ESP_LOGD("main","Parsed operation mode int : %d", int_mode);
      std::string mode_str;
      switch (int_mode) {
        case 0:  mode_str = "Off"; break;
        case 1:  mode_str = "800W limited"; break;                                                              
      }
      return mode_str;
    web_server:
      sorting_group_id: Diagnostic
      sorting_weight: 23

# Binaire sensoren
binary_sensor:
  - platform: modbus_controller
    name: "Marstek PLL Abnormal Restart"
    id: "lilygo_rs485_marstek_pll_abnormal_restart"
    icon: mdi:flash-triangle
    modbus_controller_id: mt
    register_type: holding
    address: 36000
    bitmask: 0x01

  - platform: modbus_controller
    name: "Marstek Overtemperature Limit"
    icon: mdi:thermometer-alert
    id: "lilygo_rs485_marstek_overtemperature_limit"
    modbus_controller_id: mt
    register_type: holding
    address: 36000
    bitmask: 0x02

  - platform: modbus_controller
    name: "Marstek Low Temperature Limit"
    icon: mdi:thermometer-alert
    id: "lilygo_rs485_marstek_low_temperature_limit"
    modbus_controller_id: mt
    register_type: holding
    address: 36000
    bitmask: 0x04

  - platform: modbus_controller
    name: "Marstek Fan Abnormal Warning"
    icon: mdi:fan-alert
    id: "lilygo_rs485_marstek_fan_abnormal_warning"
    modbus_controller_id: mt
    register_type: holding
    address: 36000
    bitmask: 0x08

  - platform: modbus_controller
    name: "Marstek Low Battery SOC Warning"
    icon: mdi:battery-off-outline
    id: "lilygo_rs485_marstek_low_battery_soc_warning"
    modbus_controller_id: mt
    register_type: holding
    address: 36000
    bitmask: 0x16

  - platform: modbus_controller
    name: "Marstek Output Overcurrent Warning"
    icon: mdi:flash-triangle
    id: "lilygo_rs485_marstek_output_overcurrent_warning"
    modbus_controller_id: mt
    register_type: holding
    address: 36000
    bitmask: 0x32

  - platform: modbus_controller
    name: "Marstek Abnormal Line Sequence Detection"
    icon: mdi:flash-triangle
    id: "lilygo_rs485_marstek_abnormal_line_sequence_detection"
    modbus_controller_id: mt
    register_type: holding
    address: 36000
    bitmask: 0x64

  - platform: modbus_controller
    name: "Marstek Wifi Abnormal"
    icon: mdi:wifi-alert
    id: "lilygo_rs485_marstek_wifi_abnormal"
    modbus_controller_id: mt
    register_type: holding
    address: 36001
    bitmask: 0x01

  - platform: modbus_controller
    name: "Marstek BLE abnormal"
    icon: mdi:bluetooth-off
    id: "lilygo_rs485_marstek_ble_abnormal"
    modbus_controller_id: mt
    register_type: holding
    address: 36001
    bitmask: 0x02

  - platform: modbus_controller
    name: "Marstek Network abnormal"
    icon: mdi:network-off
    id: "lilygo_rs485_marstek_network_abnormal"
    modbus_controller_id: mt
    register_type: holding
    address: 36001
    bitmask: 0x04

  - platform: modbus_controller
    name: "Marstek CT connection abnormal"
    icon: mdi:robot-vacuum-alert
    id: "lilygo_rs485_marstek_ct_connection_abnormal"
    modbus_controller_id: mt
    register_type: holding
    address: 36001
    bitmask: 0x08

  - platform: modbus_controller
    name: "Marstek Grid overvoltage"
    icon: mdi:flash-triangle
    id: "lilygo_rs485_marstek_grid_overvoltage"
    modbus_controller_id: mt
    register_type: holding
    address: 36100
    bitmask: 0x01

  - platform: modbus_controller
    name: "Marstek Grid undervoltage"
    icon: mdi:flash-triangle-outline
    id: "lilygo_rs485_marstek_grid_undervoltage"
    modbus_controller_id: mt
    register_type: holding
    address: 36100
    bitmask: 0x02

  - platform: modbus_controller
    name: "Marstek Grid overfrequency"
    icon: mdi:flash-triangle
    id: "lilygo_rs485_marstek_grid_overfrequency"
    modbus_controller_id: mt
    register_type: holding
    address: 36100
    bitmask: 0x04

  - platform: modbus_controller
    name: "Marstek Grid underfrequency"
    icon: mdi:flash-triangle
    id: "lilygo_rs485_marstek_grid_underfrequency"
    modbus_controller_id: mt
    register_type: holding
    address: 36100
    bitmask: 0x08

  - platform: modbus_controller
    name: "Marstek Grid peak voltage abnormal"
    icon: mdi:alert-plus
    id: "lilygo_rs485_marstek_grid_peak_voltage_abnormal"
    modbus_controller_id: mt
    register_type: holding
    address: 36100
    bitmask: 0x10

  - platform: modbus_controller
    name: "Marstek Current Dcover"
    icon: mdi:flash-triangle
    id: "lilygo_rs485_marstek_current_dcover"
    modbus_controller_id: mt
    register_type: holding
    address: 36100
    bitmask: 0x20

  - platform: modbus_controller
    name: "Marstek Voltage Dcover"
    icon: mdi:flash-triangle
    id: "lilygo_rs485_marstek_voltage_dcover"
    modbus_controller_id: mt
    register_type: holding
    address: 36100
    bitmask: 0x40

  - platform: modbus_controller
    name: "Marstek BAT overvoltage"
    icon: mdi:flash-triangle
    id: "lilygo_rs485_marstek_bat_overvoltage"
    modbus_controller_id: mt
    register_type: holding
    address: 36101
    bitmask: 0x01

  - platform: modbus_controller
    name: "Marstek BAT undervoltage"
    icon: mdi:flash-triangle-outline
    id: "lilygo_rs485_marstek_bat_undervoltage"
    modbus_controller_id: mt
    register_type: holding
    address: 36101
    bitmask: 0x02

  - platform: modbus_controller
    name: "Marstek BAT overcurrent"
    icon: mdi:wave-undercurrent
    id: "lilygo_rs485_marstek_bat_overcurrent"
    modbus_controller_id: mt
    register_type: holding
    address: 36101
    bitmask: 0x04

  - platform: modbus_controller
    name: "Marstek BAT low SOC"
    icon: mdi:battery-off-outline
    id: "lilygo_rs485_marstek_bat_low_soc"
    modbus_controller_id: mt
    register_type: holding
    address: 36101
    bitmask: 0x08

  - platform: modbus_controller
    name: "Marstek BAT communication failure"
    icon: mdi:flash-triangle
    id: "lilygo_rs485_marstek_bat_communication_failure"
    modbus_controller_id: mt
    register_type: holding
    address: 36101
    bitmask: 0x10

  - platform: modbus_controller
    name: "Marstek BMS protect"
    icon: mdi:flash-triangle
    id: "lilygo_rs485_marstek_bms_protect"
    modbus_controller_id: mt
    register_type: holding
    address: 36101
    bitmask: 0x20

  - platform: status
    name: "WiFi Status"
    id: "lilygo_rs485_wifi_status"

# Sensoren
sensor:
  - name: "Marstek Battery Wifi Signal Strength"
    id: lilygo_rs485_marstek_battery_wifi_signal_strenght
    icon: mdi:wifi
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 30303
    value_type: U_WORD
    unit_of_measurement: "dBm"
    filters:
      - multiply: -1
    accuracy_decimals: 0   
    web_server:
      sorting_group_id: Diagnostic
      sorting_weight: 7

  - platform: copy # Reports the Battery signal strength in %
    source_id: lilygo_rs485_marstek_battery_wifi_signal_strenght
    name: "Marstek Battery Wifi Signal"
    id: battery_wifi_signal_proc
    filters:
      - lambda: return min(max(2 * (x + 100.0), 0.0), 100.0);
    unit_of_measurement: " %"
    entity_category: diagnostic
    device_class: ""
    icon: mdi:wifi
    web_server:
      sorting_group_id: Diagnostic
      sorting_weight: 6

  - platform: modbus_controller
    id: inverter_state  # No name, since it's internal
    icon: mdi:state-machine
    modbus_controller_id: mt
    register_type: holding
    address: 35100
    value_type: U_WORD
    internal: true # Hides from Home Assistant
    web_server:
      sorting_group_id: Info
      sorting_weight: 30

  - platform: modbus_controller
    id: software_version # No name, since it's internal
    icon: mdi:factory
    modbus_controller_id: mt
    register_type: holding
    address: 31100
    value_type: U_WORD
    accuracy_decimals: 0
    skip_updates: 60 # 5 minutes
    internal: true # Hides from Home Assistant
    on_value:
      then:
        - lambda: |-
            int version = (int)x;
            char buf[5];
            sprintf(buf, "V%d", version);
            id(software_version_text).publish_state(buf);

  - platform: modbus_controller
    id: firmware_version # No name, since it's internal
    icon: mdi:factory
    modbus_controller_id: mt
    register_type: holding
    address: 31101
    value_type: U_WORD
    accuracy_decimals: 0
    skip_updates: 60 # 5 minutes
    internal: true # Hides from Home Assistant
    on_value:
      then:
        - lambda: |-
            int version = (int)x;
            char buf[5];
            sprintf(buf, "V%d", version);
            id(firmware_version_text).publish_state(buf);

  - platform: modbus_controller
    id: bms_version
    icon: mdi:factory
    modbus_controller_id: mt
    register_type: holding
    address: 31102
    value_type: U_WORD
    accuracy_decimals: 0
    skip_updates: 60 # 5 minutes
    internal: true
    on_value:
      then:
        - lambda: |-
            int version = (int)x;
            char buf[5];
            sprintf(buf, "V%d", version);
            id(bms_version_text).publish_state(buf);
  
  - name: "Marstek Battery Voltage (Average)"
    id: "lilygo_rs485_marstek_battery_voltage_average"
    icon: mdi:sine-wave
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 32100
    value_type: U_WORD
    unit_of_measurement: "V"
    device_class: voltage
    accuracy_decimals: 2
    state_class: measurement
    filters:
      - multiply: 0.01
    web_server:
      sorting_group_id: Info
      sorting_weight: 16
    
  - name: "Marstek Battery Current (Average)"
    id: "lilygo_rs485_marstek_battery_current_average"
    icon: mdi:current-dc
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 32101
    value_type: S_WORD
    unit_of_measurement: "A"
    device_class: current
    accuracy_decimals: 2
    state_class: measurement
    filters:
      - multiply: 0.01
    web_server:
      sorting_group_id: Info
      sorting_weight: 15

  - name: "Marstek Battery Power"
    id: "lilygo_rs485_marstek_battery_power"
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 32102
    value_type: S_DWORD
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    accuracy_decimals: 0
    skip_updates: 2 # 10 seconds
    web_server:
      sorting_group_id: Info
      sorting_weight: 14

  - name: "Marstek Battery State Of Charge"
    id: "lilygo_rs485_marstek_battery_state_of_charge" # Was marstek_soc
    platform: modbus_controller
    device_class: battery
    state_class: measurement
    modbus_controller_id: mt
    register_type: holding
    address: 32104
    value_type: U_WORD
    unit_of_measurement: "%"
    accuracy_decimals: 0
    web_server:
      sorting_group_id: Info
      sorting_weight: 5

# Slow Sensor
  - name: "Marstek Battery Total Energy"
    id: "lilygo_rs485_marstek_battery_total_energy" # Was marstek_total_energy
    icon: mdi:battery-charging-100
    platform: modbus_controller
    device_class: energy_storage
    state_class: measurement
    modbus_controller_id: mt
    register_type: holding
    address: 32105 
    value_type: U_WORD
    unit_of_measurement: "kWh"
    accuracy_decimals: 3
    filters:
      - multiply: 0.001 # Firmware 148: 0.001 / Firmware 147: 0.01
    skip_updates: 60 # 5 minutes
    web_server:
      sorting_group_id: Info
      sorting_weight: 7

  - platform: template
    name: "Marstek Battery Remaining Capacity"
    id: "lilygo_rs485_marstek_battery_remaining_capacity"
    icon: mdi:battery-arrow-down-outline
    unit_of_measurement: "kWh"
    accuracy_decimals: 2
    update_interval: 300s
    lambda: |-
      if (id(lilygo_rs485_marstek_battery_total_energy).has_state() && id(lilygo_rs485_marstek_battery_state_of_charge).has_state()) {
        float total_energy = id(lilygo_rs485_marstek_battery_total_energy).state;
        float soc = id(lilygo_rs485_marstek_battery_state_of_charge).state / 100.0;
        return roundf(total_energy * soc * 100) / 100; // Ensures two decimal places
      }
      return NAN;
    web_server:
      sorting_group_id: Info
      sorting_weight: 6

  - name: "Marstek AC Voltage"
    id: "lilygo_rs485_marstek_ac_voltage"
    icon: mdi:current-ac
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 32200
    value_type: U_WORD
    unit_of_measurement: "V"
    device_class: voltage
    state_class: measurement
    accuracy_decimals: 1
    filters:
      - multiply: 0.1
    web_server:
      sorting_group_id: Info
      sorting_weight: 3

  - name: "Marstek AC Current"
    id: "lilygo_rs485_marstek_ac_current"
    icon: mdi:current-ac
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 32201
    value_type: U_WORD
    unit_of_measurement: "A"
    device_class: current
    state_class: measurement
    accuracy_decimals: 2
    filters:
      - multiply: 0.01
    web_server:
      sorting_group_id: Info
      sorting_weight: 2

# Slow Sensor
  - name: "Marstek AC Power"
    id: "lilygo_rs485_marstek_ac_power"
    icon: mdi:flash
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 32202
    value_type: S_DWORD
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    accuracy_decimals: 0
    skip_updates: 2 # 10 seconds
    web_server:
      sorting_group_id: Info
      sorting_weight: 1

#  - name: "Marstek AC Offgrid Voltage"
#    id: "lilygo_rs485_marstek_ac_offgrid_voltage"
#    icon: mdi:sine-wave
#    platform: modbus_controller
#    modbus_controller_id: mt
#    state_class: measurement
#    register_type: holding
#    address: 32300
#    value_type: U_WORD
#    unit_of_measurement: "V"
#    device_class: voltage
#    accuracy_decimals: 2
#    filters:
#      - multiply: 0.1
#    web_server:
#      sorting_group_id: Info
#      sorting_weight: 26

#  - name: "Marstek AC Offgrid Current"
#    id: "lilygo_rs485_marstek_ac_offgrid_current"
#    icon: mdi:current-ac
#    platform: modbus_controller
#    state_class: measurement
#    modbus_controller_id: mt
#    register_type: holding
#    address: 32301
#    value_type: U_WORD
#    unit_of_measurement: "A"
#    device_class: current
#    accuracy_decimals: 2
#    filters:
#      - multiply: 0.01
#    web_server:
#      sorting_group_id: Info
#      sorting_weight: 27

#  - name: "Marstek AC Offgrid Power"
#    id: "lilygo_rs485_marstek_ac_offgrid_power"
#    icon: mdi:flash
#    platform: modbus_controller
#    state_class: measurement
#    modbus_controller_id: mt
#    register_type: holding
#    address: 32302
#    value_type: S_DWORD
#    unit_of_measurement: "W"
#    device_class: power
#    state_class: measurement
#    accuracy_decimals: 0
#    web_server:
#      sorting_group_id: Info
#      sorting_weight: 28

  - name: "Marstek Total Charging Energy"
    id: "lilygo_rs485_marstek_total_charging_energy"
    icon: mdi:chart-bar
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 33000
    value_type: U_DWORD
    unit_of_measurement: "kWh"
    device_class: energy
    state_class: total_increasing
    accuracy_decimals: 2
    filters:
      - multiply: 0.01
    register_count: 2
    web_server:
      sorting_group_id: Info
      sorting_weight: 12

  - name: "Marstek Total Discharging Energy"
    id: "lilygo_rs485_marstek_total_discharging_energy"
    icon: mdi:chart-bar
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 33002
    value_type: U_DWORD
    unit_of_measurement: "kWh"
    device_class: energy
    state_class: total_increasing
    accuracy_decimals: 2
    filters:
      - multiply: 0.01
    register_count: 2
    web_server:
      sorting_group_id: Info
      sorting_weight: 13

  - name: "Marstek Daily Charging Energy"
    id: "lilygo_rs485_marstek_daily_charging_energy"
    icon: mdi:chart-bar
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 33004
    value_type: U_DWORD
    unit_of_measurement: "kWh"
    device_class: energy
    state_class: total_increasing
    accuracy_decimals: 2
    filters:
      - multiply: 0.01
    register_count: 2
    web_server:
      sorting_group_id: Info
      sorting_weight: 8

  - name: "Marstek Daily Discharging Energy"
    id: "lilygo_rs485_marstek_daily_discharging_energy"
    icon: mdi:chart-bar
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 33006
    value_type: U_DWORD
    unit_of_measurement: "kWh"
    device_class: energy
    state_class: total_increasing
    accuracy_decimals: 2
    filters:
      - multiply: 0.01
    register_count: 2
    web_server:
      sorting_group_id: Info
      sorting_weight: 9

# Slow Sensor
  - name: "Marstek Monthly Charging Energy"
    id: "lilygo_rs485_marstek_monthly_charging_energy"
    icon: mdi:chart-bar
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 33008
    value_type: U_DWORD
    unit_of_measurement: "kWh"
    device_class: energy
    state_class: total_increasing
    accuracy_decimals: 2
    filters:
      - multiply: 0.01
    register_count: 2
    skip_updates: 60 # 5 minutes
    web_server:
      sorting_group_id: Info
      sorting_weight: 10

# Slow Sensor
  - name: "Marstek Monthly Discharging Energy"
    id: "lilygo_rs485_marstek_monthly_discharging_energy"
    icon: mdi:chart-bar
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 33010
    value_type: U_DWORD
    unit_of_measurement: "kWh"
    device_class: energy
    state_class: total_increasing
    accuracy_decimals: 2
    filters:
      - multiply: 0.01
    register_count: 2
    skip_updates: 60 # 5 minutes
    web_server:
      sorting_group_id: Info
      sorting_weight: 11

  - name: "Marstek Internal Temperature"
    id: "lilygo_rs485_marstek_internal_temperature"
    icon: mdi:thermometer
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 35000
    value_type: S_WORD
    unit_of_measurement: "°C"
    device_class: temperature
    state_class: measurement
    accuracy_decimals: 1
    filters:
      - multiply: 0.1
    skip_updates: 60 # 5 minutes
    web_server:
      sorting_group_id: Info
      sorting_weight: 19

  - name: "Marstek Internal MOS1 Temperature"
    id: "lilygo_rs485_marstek_internal_mos1_temperature"
    icon: mdi:thermometer
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 35001
    value_type: S_WORD
    unit_of_measurement: "°C"
    device_class: temperature
    state_class: measurement
    accuracy_decimals: 1
    filters:
      - multiply: 0.1
    skip_updates: 60 # 5 minutes
    web_server:
      sorting_group_id: Info
      sorting_weight: 20

# Slow Sensor    
  - name: "Marstek Internal MOS2 Temperature"
    id: "lilygo_rs485_marstek_internal_mos2_temperature"
    icon: mdi:thermometer
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 35002
    value_type: S_WORD
    unit_of_measurement: "°C"
    device_class: temperature
    state_class: measurement
    accuracy_decimals: 1
    skip_updates: 60 # 5 minutes
    filters:
      - multiply: 0.1
    web_server:
      sorting_group_id: Info
      sorting_weight: 21

  - name: "Marstek Max. Cell Temperature"
    id: "lilygo_rs485_marstek_max_cell_temperature"
    icon: mdi:thermometer
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 35010
    value_type: S_WORD
    unit_of_measurement: "°C"
    device_class: temperature
    state_class: measurement
    accuracy_decimals: 1
    skip_updates: 60 # 5 minutes
    filters:
      - multiply: 1
    web_server:
      sorting_group_id: Info
      sorting_weight: 22
    
  - name: "Marstek Min. Cell Temperature"
    id: "lilygo_rs485_marstek_min_cell_temperature"
    icon: mdi:thermometer
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 35011
    value_type: S_WORD
    unit_of_measurement: "°C"
    device_class: temperature
    state_class: measurement
    accuracy_decimals: 1
    filters:
      - multiply: 1
    web_server:
      sorting_group_id: Info
      sorting_weight: 23
    
  - name: "Marstek Battery Charge Voltage Limit"
    id: "lilygo_rs485_marstek_battery_charge_voltage_limit"
    icon: mdi:sine-wave
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 35110
    value_type: U_WORD
    unit_of_measurement: "V"
    device_class: voltage
    accuracy_decimals: 1
    state_class: measurement
    filters:
      - multiply: 0.1
    web_server:
      sorting_group_id: Info
      sorting_weight: 16

  - name: "Marstek Battery Charge Current Limit"
    id: "lilygo_rs485_marstek_battery_charge_current_limit"
    icon: mdi:current-dc
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 35111
    value_type: S_WORD
    unit_of_measurement: "A"
    device_class: current
    accuracy_decimals: 0
    state_class: measurement
    skip_updates: 60 # 5 minutes
    filters:
      - multiply: 0.01
    web_server:
      sorting_group_id: Info
      sorting_weight: 17

  - name: "Marstek Battery Discharge Current Limit"
    id: "lilygo_rs485_marstek_battery_discharge_current_limit"
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 35112
    value_type: S_WORD
    unit_of_measurement: "A"
    device_class: current
    accuracy_decimals: 0
    skip_updates: 60 # 5 minutes
    state_class: measurement
    filters:
      - multiply: 0.01
    web_server:
      sorting_group_id: Info
      sorting_weight: 18

  - name: "Marstek Battery Maximum Cell Voltage"
    platform: modbus_controller
    icon: mdi:sine-wave
    modbus_controller_id: mt
    register_type: holding
    address: 37007
    value_type: U_WORD
    unit_of_measurement: "V"
    device_class: voltage
    accuracy_decimals: 2
    state_class: measurement
    filters:
      - multiply: 0.001
    id: marstek_max_cell_voltage
    skip_updates: 10
    web_server:
      sorting_group_id: Info
      sorting_weight: 24

  - name: "Marstek Battery Minimum Cell Voltage"
    platform: modbus_controller
    icon: mdi:sine-wave
    modbus_controller_id: mt
    register_type: holding
    address: 37008
    value_type: U_WORD
    unit_of_measurement: "V"
    device_class: voltage
    accuracy_decimals: 2
    state_class: measurement
    filters:
      - multiply: 0.001
    id: marstek_min_cell_voltage
    skip_updates: 10
    web_server:
      sorting_group_id: Info
      sorting_weight: 25

  - platform: template
    name: "Marstek Battery Cell Voltage Delta"
    icon: mdi:sine-wave
    unit_of_measurement: "V"
    device_class: voltage
    accuracy_decimals: 3
    state_class: measurement
    lambda: |-
      if (isnan(id(marstek_max_cell_voltage).state) || isnan(id(marstek_min_cell_voltage).state)) {
        return NAN;
      }
      return id(marstek_max_cell_voltage).state - id(marstek_min_cell_voltage).state;
    web_server:
      sorting_group_id: Info
      sorting_weight: 26
  
  - platform: wifi_signal
    name: "WiFi Signal Strength"
    icon: mdi:wifi
    id: "wifi_strength" # Was wifi_strength
    update_interval: 30s
    web_server:
      sorting_group_id: Diagnostic
      sorting_weight: 6

  # An internal sensor to check Modbus communication status.
  - platform: modbus_controller
    modbus_controller_id: mt
    name: "Modbus Status"
    icon: mdi:transit-connection
    id: "modbus_status" # Was modbus_status
    register_type: holding
    address: 32104  # Using the Battery SOC register as a reference
    value_type: U_WORD
    internal: true
    web_server:
      sorting_group_id: Diagnostic
      sorting_weight: 15

# Instellingen en modi (Select en Number)
select:
  - name: "Marstek RS485 Control Mode"
    id: "lilygo_rs485_marstek_rs485_control_mode"
    icon: mdi:connection
    platform: modbus_controller
    modbus_controller_id: mt
    address: 42000
    value_type: U_WORD
    optionsmap:
      "enable": 21930
      "disable": 21947
    skip_updates: 2 # 10 seconds
    web_server:
      sorting_group_id: Control
      sorting_weight: 1

  - name: "Marstek Forcible Charge/Discharge" 
    id: "lilygo_rs485_marstek_forcible_chargedischarge"
    platform: modbus_controller
    modbus_controller_id: mt
    address: 42010
    value_type: U_WORD
    optionsmap:
      "stop": 0
      "charge": 1
      "discharge": 2
    skip_updates: 2 # 10 seconds
    web_server:
      sorting_group_id: Control
      sorting_weight: 4

  - name: "Marstek Backup Function"
    id: "lilygo_rs485_marstek_backup_function"
    platform: modbus_controller
    modbus_controller_id: mt
    address: 41200
    value_type: U_WORD
    optionsmap:
      "enable": 0
      "disable": 1
    skip_updates: 2 # 10 seconds
    web_server:
      sorting_group_id: Control
      sorting_weight: 3 

  - name: "Marstek User Work Mode"
    id: "lilygo_rs485_marstek_user_work_mode"
    icon: mdi:auto-mode
    platform: modbus_controller
    modbus_controller_id: mt
    address: 43000
    value_type: U_WORD
    optionsmap:
      "manual": 0
      "anti-feed": 1
      "ai": 2
    skip_updates: 2 # 10 seconds
    web_server:
      sorting_group_id: Control
      sorting_weight: 2

number:
  - name: "Marstek Forcible Charge Power"
    id: "lilygo_rs485_marstek_forcible_charge_power"
    icon: mdi:tune-variant
    mode: box
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 42020
    value_type: U_WORD
    unit_of_measurement: "W"
    min_value: 0
    max_value: 2500
    step: 1
    skip_updates: 2 # 10 seconds
    web_server:
      sorting_group_id: Control
      sorting_weight: 5

  - name: "Marstek Charge To SOC"
    id: "lilygo_rs485_marstek_charge_to_soc"
    icon: mdi:battery-charging-medium 
    mode: box
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 42011
    value_type: U_WORD
    unit_of_measurement: "%"
    min_value: 12
    max_value: 100
    step: 1
    web_server:
      sorting_group_id: Control
      sorting_weight: 9

  - name: "Marstek Forcible Discharge Power"
    id: "lilygo_rs485_marstek_forcible_discharge_power"
    icon: mdi:tune-variant
    mode: box
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 42021
    value_type: U_WORD
    unit_of_measurement: "W"
    min_value: 0
    max_value: 2500
    step: 1
    skip_updates: 2 # 10 seconds
    web_server:
      sorting_group_id: Control
      sorting_weight: 6

  - name: "Marstek Charging Cutoff Capacity"
    id: "lilygo_rs485_marstek_charging_cutoff_capacity"
    icon: mdi:battery-90
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 44000
    value_type: U_WORD
    unit_of_measurement: "%"
    min_value: 80
    max_value: 100
    multiply: 10

  - name: "Marstek Discharging Cutoff Capacity"
    id: "lilygo_rs485_marstek_discharging_cutoff_capacity"
    icon: mdi:battery-10
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 44001
    value_type: U_WORD
    unit_of_measurement: "%"
    min_value: 12
    max_value: 30
    multiply: 10

  - name: "Marstek Max. Charge Power"
    id: "lilygo_rs485_marstek_max_charge_power"
    icon: mdi:tune-variant
    mode: box
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 44002
    value_type: U_WORD
    unit_of_measurement: "W"
    min_value: 0
    max_value: 2500
    step: 1

# Slow Sensor
  - name: "Marstek Max. Discharge Power"
    id: "lilygo_rs485_marstek_max_discharge_power"
    icon: mdi:tune-variant
    mode: box
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 44003
    value_type: U_WORD
    unit_of_measurement: "W"
    min_value: 0
    max_value: 2500
    step: 1
    skip_updates: 2 # 10 seconds

###############################################################################
# LED
###############################################################################
light:
  - platform: esp32_rmt_led_strip
    rgb_order: GRB
    chipset: WS2812
    pin: GPIO4
    num_leds: 1
    name: "Status LED"
    id: status_led

interval:
  - interval: 5s
    then:
      - lambda: |-
          ESP_LOGD("status", "Modbus: %.0f, WiFi: %.0f", id(modbus_status).state, id(wifi_strength).state);
      - if:
          condition:
            lambda: |-
              return !isnan(id(modbus_status).state) && id(wifi_strength).state > -80;
          then:
            - light.turn_on:
                id: status_led
                red: 0%
                green: 100%  # 🟢 Green = Modbus OK & WiFi strong
                blue: 0%
          else:
            - if:
                condition:
                  lambda: |-
                    return isnan(id(modbus_status).state) && id(wifi_strength).state < -80;
                then:
                  - light.turn_on:
                      id: status_led
                      red: 100%  # 🟣 Purple = Both Modbus & WiFi failed
                      green: 0%
                      blue: 100%
                else:
                  - if:
                      condition:
                        lambda: |-
                          return id(wifi_strength).state < -80;
                      then:
                        - light.turn_on:
                            id: status_led
                            red: 0%
                            green: 0%
                            blue: 100%  # 🔵 Blue = Weak WiFi signal (< -80 dBm)
                      else:
                        - light.turn_on:
                            id: status_led
                            red: 100%  # 🔴 Red = Modbus error, WiFi OK
                            green: 0%
                            blue: 0%

[superduper1969]

pj schreef op zondag 14 september 2025 @ 11:02:
Nav post in 'gewone' topic hier maar verder:

Ik heb inmiddels de code van @fonske (MarstekVenus-M5stackRS485) in die van @superduper1969 (MarstekVenus-LilygoRS485) gezet, En daarmee krijg waardes in EVCC.

Helaas krijg ik inderdaad dropouts van Vermogen (AC Power) en Laden (Soc). Zoals @AUijtdehaag al voorspelde.


[...]


Het lijkt erop dat de het modbusbericht out of sync loopt met het verzenden via de modbus_bridge.

Ik heb te weinig kaas gegeten van ESP32 om te weten welke richting ik op moet zoeken. Pielen met de intervals maakt iig weinig uit.

Iemand?


[...]

Ik heb de log in Gemini gegooid maar daar kom ik niet veel verder mee maar jij misschien wel?

Ik heb in de lilygo-rs485.yaml een aantal sensoren aangemerkt als "Slow Sensor"
Dit zijn sensoren waarbij de Marstek Fimware langer doet over het genereren van het antwoord dan de maximale tijd die ervoor staat in Modbus, daar is dus niet veel aan te doen.
Voor de Home Assistant/ESPHome integratie maakt dit niet uit maar misschien wel voor EVCC?

Ik zal een poging wagen.

[superduper1969]

@pj
Probeer dit eens?
Afgeleid van: https://github.com/rosenrot00/esphome_modbus_bridge
Ik kan natuurlijk niets testen.
Natuurlijk wel je keys & OTA PW aanpassen.

code:

esphome:
  name: lilygo2rs485bridge
  friendly_name: LILYGO2RS485Bridge
  min_version: 2024.11.0
  name_add_mac_suffix: false

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:
  # level: VERY_VERBOSE
  
# Enable Home Assistant API
api:
  encryption:
    key: "YourKeyHere"

ota:
  - platform: esphome
    password: "YourPasswordHere"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Lilygo-Rs485 Fallback Hotspot"
    password: "GBDjgqkttbFLa93eFCaj"

external_components:
  - source:
      type: git
      url: https://github.com/rosenrot00/esphome_modbus_bridge
    components: [modbus_bridge]

# Set pins required for LilyGo T-CAN485 board
output:
  - platform: gpio
    id: ENABLE_PIN # Enable the chip
    pin:
      number: GPIO19
      inverted: true

  - platform: gpio
    id: SE_PIN # Enable autodirection
    pin:
      number: GPIO17
      inverted: true

  - platform: gpio
    id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip
    pin:
      number: GPIO16
      inverted: true

uart:
  id: uart_bus
    rx_pin: GPIO21
    tx_pin: GPIO22
    baud_rate: 115200
    data_bits: 8
    stop_bits: 1
    parity: NONE
    rx_buffer_size: 256         # min. 256 recommended; increase for very long RTU responses

modbus_bridge:
  id: mb_bridge
  uart_id: uart_bus
  tcp_port: 502               # TCP port
  tcp_poll_interval: 50       # ms between TCP polls
  tcp_client_timeout: 60000   # ms inactivity until TCP client is disconnected
  tcp_allowed_clients: 4      # clamped to minimum 1, use with care as it increases memory usage
  rtu_response_timeout: 3000  # ms, clamped internally to minimum of 10 ms)

switch:
  - platform: template
    name: "Modbus Bridge Debug"
    id: modbus_debug_switch
    restore_mode: RESTORE_DEFAULT_OFF  # debug disabled by default; persists across reboots
    turn_on_action:
      - lambda: |-
          id(mb_bridge).set_debug(true);
          id(modbus_debug_switch).publish_state(true);
    turn_off_action:
      - lambda: |-
          id(mb_bridge).set_debug(false);
          id(modbus_debug_switch).publish_state(false);

[AUijtdehaag]

superduper1969 schreef op zondag 14 september 2025 @ 12:36:
@pj
Probeer dit eens?
Afgeleid van: https://github.com/rosenrot00/esphome_modbus_bridge
Ik kan natuurlijk niets testen.
Natuurlijk wel je keys & OTA PW aanpassen.

code:

esphome:
  name: lilygo2rs485bridge
  friendly_name: LILYGO2RS485Bridge
  min_version: 2024.11.0
  name_add_mac_suffix: false

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:
  # level: VERY_VERBOSE
  
# Enable Home Assistant API
api:
  encryption:
    key: "YourKeyHere"

ota:
  - platform: esphome
    password: "YourPasswordHere"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Lilygo-Rs485 Fallback Hotspot"
    password: "GBDjgqkttbFLa93eFCaj"

external_components:
  - source:
      type: git
      url: https://github.com/rosenrot00/esphome_modbus_bridge
    components: [modbus_bridge]

# Set pins required for LilyGo T-CAN485 board
output:
  - platform: gpio
    id: ENABLE_PIN # Enable the chip
    pin:
      number: GPIO19
      inverted: true

  - platform: gpio
    id: SE_PIN # Enable autodirection
    pin:
      number: GPIO17
      inverted: true

  - platform: gpio
    id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip
    pin:
      number: GPIO16
      inverted: true

uart:
  id: uart_bus
    rx_pin: GPIO21
    tx_pin: GPIO22
    baud_rate: 115200
    data_bits: 8
    stop_bits: 1
    parity: NONE
    rx_buffer_size: 256         # min. 256 recommended; increase for very long RTU responses

modbus_bridge:
  id: mb_bridge
  uart_id: uart_bus
  tcp_port: 502               # TCP port
  tcp_poll_interval: 50       # ms between TCP polls
  tcp_client_timeout: 60000   # ms inactivity until TCP client is disconnected
  tcp_allowed_clients: 4      # clamped to minimum 1, use with care as it increases memory usage
  rtu_response_timeout: 3000  # ms, clamped internally to minimum of 10 ms)

switch:
  - platform: template
    name: "Modbus Bridge Debug"
    id: modbus_debug_switch
    restore_mode: RESTORE_DEFAULT_OFF  # debug disabled by default; persists across reboots
    turn_on_action:
      - lambda: |-
          id(mb_bridge).set_debug(true);
          id(modbus_debug_switch).publish_state(true);
    turn_off_action:
      - lambda: |-
          id(mb_bridge).set_debug(false);
          id(modbus_debug_switch).publish_state(false);

Ik zou er de webserver wel in houden, via de debug switch zie je de communicatie
https://github.com/fonske..._bridge_only.yaml#L77-L85

@jp Beter gewoon de lilygo als modbus bridge gebruiken en de elfin HA yaml gebruiken met modbus tcp/ip
Heb dagen lang geprobeerd de dropouts te verbeteren/verhepen maar dat is niet gelukt. Dus het is OF/OF en niet EN/EN

[NoFate]

Weet iemand of je via modbus een echte factory reset kan doen? Een volledige wipe, dat alles weg is inclusief wifi etc... Want dat gaat niet via de app, dan is blijven er nog restanten over...