Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[AUijtdehaag]

Broodro0ster schreef op donderdag 4 september 2025 @ 10:30:
Ik las dat er een bepaalde update de modbus integratie breekt. Ik krijg nu het voorstel om v151 naar v153 te updaten.

Wie van jullie heeft al v153? Werkt de modbus koppeling nog goed na de update?

Net geupdate, werkt nog prima

[ Voor 22% gewijzigd door AUijtdehaag op 04-09-2025 10:51 ]

[antonboonstra]

pascallj schreef op donderdag 4 september 2025 @ 10:35:
[...]
De Marstek heeft geen Modbus TCP.

Dit is ook al bevestigd met een test? (bijvoorbeeld met Modbus Doctor een connectie proberen te maken)

[pascallj]

antonboonstra schreef op donderdag 4 september 2025 @ 11:40:
[...]

Dit is ook al bevestigd met een test? (bijvoorbeeld met Modbus Doctor een connectie proberen te maken)

Bij de V3 nog niet getest, en ik heb het zelf bij de eerdere versies ook niet getest. Maar het is ook nergens beweerd dat het bestaat. In de firmware is er ook geen aanleiding om aan te nemen dat het er in zit. Maar voel je vrij om het te testen

[dannyro]

AUijtdehaag schreef op donderdag 4 september 2025 @ 10:43:
[...]

Net geupdate, werkt nog prima

[Afbeelding]

V154 ook geen probleem. Wel geen hamerelay meer.

[AUijtdehaag]

@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)

[ Voor 21% gewijzigd door AUijtdehaag op 04-09-2025 12:15 ]

[SatScan]

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)

154 werkt niet met de add-on daarom ben ik terug naar 153 gegaan.
Ik heb niet gemerkt of gemeten dat 154 beter is dan 153.

[amvolleb]

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)

Ik heb hetzelfde probleem helaas (unexpected keyword argument 'slave' in modbus_client.py)

[Hangover_ohoo]

amvolleb schreef op donderdag 4 september 2025 @ 12:50:
[...]

Ik heb hetzelfde probleem helaas (unexpected keyword argument 'slave' in modbus_client.py)

Hier ook. Exact hetzelfde. Rollback HA (via backup) uitgevoerd en daarna werkte eea weer feiloos gelukkig.

[amvolleb]

Hangover_ohoo schreef op donderdag 4 september 2025 @ 12:57:
[...]


Hier ook. Exact hetzelfde. Rollback HA (via backup) uitgevoerd en daarna werkte eea weer feiloos gelukkig.

Ik lees op de github pagina in de issues lijst dat de fix waarschijnlijk simpel is:

code:

1.4 Simple replacements
please replace parametersasfollows
• slave= with device_id=
• slaves= with device_ids=

Dus hopelijk snel een update van deze mooie integratie

[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).