AUijtdehaag schreef op zaterdag 28 februari 2026 @ 18:49:
[...]

Mapping? (Als niet ict’er ken ik het begrip niet)
Het is een kwestie van de yamls kopieeren en de nodered flow en meer niet
Koppel een willekeurige p1 meter aan de p1_meter template sensor

Vragen kan altijd (me Fonske)
Stel dat bij integratie Viper de ene entity number.marstek_charge_power heet en bij de andere number.marstek_power_charge, dan is de mapping de hernoeming van de eerste naar de tweede. Technisch gezien is een mapping meer een verwijzing, zoals een persoonsnaam naar een telefoonnummer in het telefoonboek (bij gebrek aan een recenter voorbeeld), maar dat terzijde.

De vraag is dus welke entities allemaal hernoemd moeten worden om de code werkend te krijgen met de namen zoals gebruikt in integratie Viper. Of gaat dat automagisch?

Ik weet zelf niet hoe NodeRED werkt icm HA dus kan anders dan de vraag vertalen, er niets nuttigs over zeggen.

  • AUijtdehaag
  • Registratie: Oktober 2006
  • Niet online
@pascallj
Je kan toch gewoon die integratie eruit halen en mijn modbus tcp yamls gebruiken. Dat doet hetzelfde en hoef je niks om te zetten.

Er is volgens mij al eens aan de maker van die integratie gevraagd of hij de entities gelijk wilde maken.
Zodat ook @Tazzios met zijn blueprint maar 1 versie hoeft te maken

Helaas.

Probleem met dat soort dingen is dat het ook vaak te ver uit elkaar groeit.
Ik hou mijn yamls ook bewust in het engels zodat comptabiliteit gewaarbord blijft

Nodered leest de HA entity, als die een andere naam heeft dan wordt het ingewikkeld
Alles opnieuw koppelen in nodered kan, maar staat updates in de weg.
Je kan nu in 1x alle nodered flows importeren. Dan is het niet handig als je alles zelf hebt aangepast

*Auitdehaag gaat wat snellere hardware optuigen om met 1s p1 info te testen
De ingebouwde debug in nodered flows komt soms boven de sec met mijn huidige hardware

[ Voor 28% gewijzigd door AUijtdehaag op 28-02-2026 19:23 ]

PVOutput Github - Div ESP TK: MHI - Clack - Marstek

AUijtdehaag schreef op zaterdag 28 februari 2026 @ 19:14:
@pascallj
Je kan toch gewoon die integratie eruit halen en mijn modbus tcp yamls gebruiken. Dat doet hetzelfde en hoef je niks om te zetten.

Er is volgens mij al eens aan de maker van die integratie gevraagd of hij de entities gelijk wilde maken.
Zodat ook @Tazzios met zijn blueprint maar 1 versie hoeft te maken

Helaas.

Probleem met dat soort dingen is dat het ook vaak te ver uit elkaar groeit.
Ik hou mijn yamls ook bewust in het engels zodat comptabiliteit gewaarbord blijft

Nodered leest de HA entity, als die een andere naam heeft dan wordt het ingewikkeld
Ik gebruik geen van alle integraties hier dus zou dat niet weten, maar volgens mij is Viper een Modbus TCP naar Modbus RTU implementatie met bijvoorbeeld een Elfin. Die van jou is alleen voor V3 via LAN of direct te flashen op een ESP toch? Maar ik ben af en toe het overzicht kwijt van welke integratie wat doet, dus misschien kan het wel.

Met een HA blueprint zou je prima kunnen aangeven van welke entity is voor de actie, welke voor het laad-/ontlaadvermogen etc. Dat is dan de mapping en hou je de automatisering universeel ;). Maar ik snap ook wel dat daar weinig behoeft aan is.

  • AUijtdehaag
  • Registratie: Oktober 2006
  • Niet online
@pascallj
Ik heb voor lilygo en M5stack de code allemaal gelijk getrokken
Als er behoefte is om dat voor de elfin ook te doen hoor ik het graag
Maar sinds er geen v1 of v2 verkocht meer worden is dat wellicht niet meer nodig
Voor venus A heb ik ook de modbus tcp/ip code gezet in de juiste branch op github.

Je zit met de viper integratie met vertalingen van de entities.
Mooiste zou zijn dat HA enkel keek naar de entity-id en niet meer naar de namen. Dat dat fysiek twee verschillende dingen kunnen zijn voor 1 entiteit. Dan is het probleem te takkelen

PVOutput Github - Div ESP TK: MHI - Clack - Marstek


  • Tazzios
  • Registratie: November 2001
  • Laatst online: 23:01

Tazzios

..

AUijtdehaag schreef op zaterdag 28 februari 2026 @ 19:14:
@pascallj
Je kan toch gewoon die integratie eruit halen en mijn modbus tcp yamls gebruiken. Dat doet hetzelfde en hoef je niks om te zetten.

Er is volgens mij al eens aan de maker van die integratie gevraagd of hij de entities gelijk wilde maken.
Zodat ook @Tazzios met zijn blueprint maar 1 versie hoeft te maken

...
Mijn blueprint (er is maar 1 versie*) ondersteunt:
https://github.com/Superduper1969/MarstekVenus-LilygoRS485
https://github.com/fonske/MarstekVenus-M5stackRS485
https://github.com/fonske/MarstekVenus-LilygoRS485
Want dat was (bijna?) allemaal gelijk wat betreft entiteiten.
En
https://github.com/ViperRNMC/marstek_venus_modbus/tree/main
Bij de laatste heb ik voor elke taal de entiteiten toe moeten voegen.
Het is voor de gebruiker denk wel de makkelijkste optie.

De losse yaml modbus ondersteunen is lastig want in de blueprint dien je 1 device te kiezen. Wat ik toendertijd vond was dat de yaml modbus niet als 1 device wordt gezien.

* of 2 als je die voor de sessy ook meetelt.
Pagina: 1 ... 32 33 Laatste