NL: Marstek Venus E -V2 (5.12 kWv ) (V153 BMS:V215); HW P1 - 4300 pw Jinko panelen/APSystem- Kaifa 3 fase meter,) - WiFi TPLink Deco X20 - HA-Green
Knop heet inderdaad "Visit", ik heb het aangepast in startpost.gho schreef op zaterdag 13 september 2025 @ 16:29:
[...]
Weet niet of het aan hardware Home assistant green ligt waarbij EspHome geen view knop maar visit knop
lilygo-rs485.yaml is voor de eerste batterij maakt niet uit voor een V1 of V2
lilygo-rs485-2.yaml is voor de 2e
lilygo-rs485-3.yaml is voor de 3e
MarstekVenus-Lilygo-T-POE-Pro.yaml is voor de versie met een UTP aansluiting.
Als je lilygo-rs485.yaml een paar weken/maanden geleden hebt gedownload moet je dat opnieuw doen voor de meeste recente versie. Daar zit de fix in voor de LED driver = obsolete meldingen.
Bekijk nog een keer een filmpje over ESP home, misschien kom je er dan achter wat je anders doet.
https://www.youtube.com/watch?v=UI8Xjl7nwsI
En anders kun je screenshots van foutmeldingen in een AI zoals Gemini plakken om je een hint te geven.
[ Voor 57% gewijzigd door superduper1969 op 13-09-2025 20:14 ]
MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
Dank Superduper, zal video goed bekijken en vlgs mij heb ik de versie van ca 3 weken gedownload, maar voor de zekerheid opnieuw doen.superduper1969 schreef op zaterdag 13 september 2025 @ 19:57:
[...]
Knop heet inderdaad "Visit", ik heb het aangepast in startpost.
lilygo-rs485.yaml is voor de eerste batterij maakt niet uit voor een V1 of V2
lilygo-rs485-2.yaml is voor de 2e
lilygo-rs485-3.yaml is voor de 3e
MarstekVenus-Lilygo-T-POE-Pro.yaml is voor de versie met een UTP aansluiting.
Als je lilygo-rs485.yaml een paar weken/maanden geleden hebt gedownload moet je dat opnieuw doen voor de meeste recente versie. Daar zit de fix in voor de LED driver = obsolete meldingen.
Bekijk nog een keer een filmpje over ESP home, misschien kom je er dan achter wat je anders doet.
https://www.youtube.com/watch?v=UI8Xjl7nwsI
En anders kun je screenshots van foutmeldingen in een AI zoals Gemini plakken om je een hint te geven.
Hopelijk lukt het de Wifi alsnog via secrets te activeren met niet Lot netwerk,..
Dank Superduper, zal video goed bekijken, knelpunt lijkt me dat aanwezige Secret.yaml Wifi niet koppelt. Zal Lot wijzigen in reguliere TP Link en verder speuren, doch altijd open voor suggesties en tipssuperduper1969 schreef op zaterdag 13 september 2025 @ 19:57:
[...]
Knop heet inderdaad "Visit", ik heb het aangepast in startpost.
lilygo-rs485.yaml is voor de eerste batterij maakt niet uit voor een V1 of V2
lilygo-rs485-2.yaml is voor de 2e
lilygo-rs485-3.yaml is voor de 3e
MarstekVenus-Lilygo-T-POE-Pro.yaml is voor de versie met een UTP aansluiting.
Als je lilygo-rs485.yaml een paar weken/maanden geleden hebt gedownload moet je dat opnieuw doen voor de meeste recente versie. Daar zit de fix in voor de LED driver = obsolete meldingen.
Bekijk nog een keer een filmpje over ESP home, misschien kom je er dan achter wat je anders doet.
https://www.youtube.com/watch?v=UI8Xjl7nwsI
En anders kun je screenshots van foutmeldingen in een AI zoals Gemini plakken om je een hint te geven.
NL: Marstek Venus E -V2 (5.12 kWv ) (V153 BMS:V215); HW P1 - 4300 pw Jinko panelen/APSystem- Kaifa 3 fase meter,) - WiFi TPLink Deco X20 - HA-Green
Ik heb inmiddels de code van @fonske (MarstekVenus-M5stackRS485) in die van @superduper1969 (MarstekVenus-LilygoRS485) gezet, En daarmee krijg waardes in EVCC.
Helaas krijg ik inderdaad dropouts van Vermogen (AC Power) en Laden (Soc). Zoals @AUijtdehaag al voorspelde.
Het lijkt erop dat de het modbusbericht out of sync loopt met het verzenden via de modbus_bridge.battery 1 power: read failed: dial tcp 192.168.0.220:502: i/o timeout
5 seconden geleden
2025-09-14 11:01:03.246510846 +0200 CEST m=+1596.609295094 !! 4145ms read failed: read tcp 192.168.0.150:52154->192.168.0.220:502: i/o timeout\n2025-09-14 11:01:07.418712794 +0200 CEST m=+1600.781497046 !! 3000ms read failed: dial tcp 192.168.0.220:502: i/o timeout\n2025-09-14 11:01:10.46199585 +0200 CEST m=+1603.824780102 !! 3000ms read failed: dial tcp 192.168.0.220:502: i/o timeout
5 minuten geleden
battery 1 soc: read failed: read tcp 192.168.0.150:54960->192.168.0.220:502: i/o timeout
18 minuten geleden
battery 1 power: read failed: modbus: response data size '2' does not match request quantity '2'
2
18 minuten geleden
2025-09-14 10:43:30.578358171 +0200 CEST m=+543.941142363 !! 442ms read failed: modbus: response data is empty\n2025-09-14 10:43:31.039003301 +0200 CEST m=+544.401787552 !! 967ms read failed: modbus: response data is empty\n2025-09-14 10:43:32.049106568 +0200 CEST m=+545.411890820 !! 962ms read failed: modbus: response data is empty\n2025-09-14 10:43:33.041261414 +0200 CEST m=+546.404045665 !! 2450ms read failed: modbus: response data size '2' does not match request quantity '2'\n2025-09-14 10:43:35.541024628 +0200 CEST m=+548.903808877 !! 3579ms read failed: modbus: response unit id '255' does not match request '1'\n2025-09-14 10:43:39.262989913 +0200 CEST m=+552.625774200 !! 2229ms read failed: modbus: response data size '2' does not match request quantity '2'
19 minuten geleden
2025-09-14 10:42:15.101661399 +0200 CEST m=+468.464445649 !! 1449ms read failed: modbus: response data is empty\n2025-09-14 10:42:16.563949109 +0200 CEST m=+469.926733357 !! 991ms read failed: modbus: response data is empty\n2025-09-14 10:42:17.576538947 +0200 CEST m=+470.939323198 !! 982ms read failed: modbus: response data is empty\n2025-09-14 10:42:18.627349459 +0200 CEST m=+471.990133707 !! 939ms read failed: modbus: response data is empty\n2025-09-14 10:42:19.627052523 +0200 CEST m=+472.989836774 !! 944ms read failed: modbus: response data is empty\n2025-09-14 10:42:20.677320484 +0200 CEST m=+474.040104732 !! 921ms read failed: modbus: response data is empty\n2025-09-14 10:42:21.717244148 +0200 CEST m=+475.080028400 !! 2370ms read failed: modbus: response data is empty\n2025-09-14 10:42:24.321957487 +0200 CEST m=+477.684741739 !! 1072ms read failed: modbus: response data size '2' does not match request quantity '2'
Ik heb te weinig kaas gegeten van ESP32 om te weten welke richting ik op moet zoeken. Pielen met de intervals maakt iig weinig uit.
Iemand?
code:
esphome: name: lilygo-rs485 friendly_name: LILYGO RS485 min_version: 2024.11.0 name_add_mac_suffix: false esp32: board: esp32dev framework: type: arduino ## Modbus TCP/IP external component external_components: - source: type: git url: https://github.com/rosenrot00/esphome_modbus_bridge components: [modbus_bridge] refresh: always # Enable logging logger: # level: VERY_VERBOSE # Enable Home Assistant API api: encryption: key: "PS5dgQCKNf1ryMlYxyRdlQaQ1CKoTO+bzpDp22B8Pkk=" ota: - platform: esphome password: "5714500323d3bd5904a30838b1ace193" wifi: ssid: !secret wifi_ssid password: !secret wifi_password # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: "Lilygo-Rs485 Fallback Hotspot" password: "GBDjgqkttbFLa93eFCaj" web_server: port: 80 version: 3 include_internal: False # ota: False local: True sorting_groups: - id: Info name: "Info" sorting_weight: -40 - id: Control name: "Control" sorting_weight: -30 - id: Status name: "Status" sorting_weight: -20 - id: Diagnostic name: "Diagnostic" sorting_weight: -10 # Set pins required for LilyGo T-CAN485 board output: - platform: gpio id: ENABLE_PIN # Enable the chip pin: number: GPIO19 inverted: true - platform: gpio id: SE_PIN # Enable autodirection pin: number: GPIO17 inverted: true - platform: gpio id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip pin: number: GPIO16 inverted: true # Configure UART uart: - id: mod_bus rx_pin: GPIO21 tx_pin: GPIO22 baud_rate: 115200 data_bits: 8 stop_bits: 1 parity: NONE ## Configure MODBUS TCP/IP bridge modbus_bridge: uart_id: mod_bus id: mb_bridge tcp_port: 502 # TCP port tcp_poll_interval: 500 # ms between TCP polls tcp_client_timeout: 100000 # ms inactivity until TCP client is disconnected tcp_allowed_clients: 1 # clamped to minimum 1, use with care as it increases memory usage rtu_response_timeout: 5000 # ms, clamped internally to minimum of 10 ms) modbus: - uart_id: mod_bus id: modbus1 send_wait_time: 20ms modbus_controller: - id: mt address: 0x1 modbus_id: modbus1 command_throttle: 20ms update_interval: 2s # Tekstsensoren text_sensor: - platform: modbus_controller name: "Device Name" icon: mdi:rename-outline id: device_name modbus_controller_id: mt register_type: holding address: 31000 register_count: 10 response_size: 20 skip_updates: 60 # 5 minutes entity_category: diagnostic web_server: sorting_group_id: Diagnostic sorting_weight: 7 - platform: template name: "Software Version" id: software_version_text icon: mdi:factory update_interval: never # updates only when sensor triggers entity_category: diagnostic web_server: sorting_group_id: Diagnostic sorting_weight: 8 - platform: template name: "Firmware Version" id: firmware_version_text icon: mdi:factory update_interval: never # updates only when sensor triggers entity_category: diagnostic web_server: sorting_group_id: Diagnostic sorting_weight: 9 - platform: template name: "BMS Version" id: bms_version_text icon: mdi:factory update_interval: never # updates only when sensor triggers entity_category: diagnostic web_server: sorting_group_id: Diagnostic sorting_weight: 10 # - name: "Marstek SN Code" # platform: modbus_controller # modbus_controller_id: mt # register_type: holding # address: 31200 # register_count: 10 # response_size: 20 # skip_updates: 60 # 5 minutes - platform: template name: "Marstek Inverter State" lambda: |- switch (int(id(inverter_state).state)) { case 0: return std::string("Sleep"); case 1: return std::string("Standby"); case 2: return std::string("Charge"); case 3: return std::string("Discharge"); case 4: return std::string("Fault"); case 5: return std::string("Idle"); case 6: return std::string("AC bypass"); default: return std::string("Unknown"); }; update_interval: 5s web_server: sorting_group_id: Info sorting_weight: 4 - platform: wifi_info ip_address: name: ESP IP icon: mdi:ip web_server: sorting_group_id: Diagnostic sorting_weight: 4 ssid: name: ESP SSID icon: mdi:wifi web_server: sorting_group_id: Diagnostic sorting_weight: 3 - platform: version name: ESP Version hide_timestamp: true disabled_by_default: false icon: mdi:new-box entity_category: diagnostic web_server: sorting_group_id: Diagnostic sorting_weight: 2 - platform: modbus_controller id: wifi_status name: "Wifi status" modbus_controller_id: mt register_type: holding address: 30300 raw_encode: NONE icon: mdi:wifi-alert entity_category: diagnostic skip_updates: 20 lambda: |- uint16_t int_mode = (data[item->offset] << 8) + data[item->offset+1]; ESP_LOGD("main","Parsed operation mode int : %d", int_mode); std::string mode_str; switch (int_mode) { case 0: mode_str = "Disconnected"; break; case 1: mode_str = "Connected"; break; } return mode_str; web_server: sorting_group_id: Diagnostic sorting_weight: 20 - platform: modbus_controller id: bt_status name: "BT status" modbus_controller_id: mt register_type: holding address: 30301 raw_encode: NONE icon: mdi:home-heart entity_category: diagnostic skip_updates: 20 lambda: |- uint16_t int_mode = (data[item->offset] << 8) + data[item->offset+1]; ESP_LOGD("main","Parsed operation mode int : %d", int_mode); std::string mode_str; switch (int_mode) { case 0: mode_str = "Off"; break; case 1: mode_str = "Active after boot"; break; case 2: mode_str = "Connected"; break; case 3: mode_str = "Active"; break; } return mode_str; web_server: sorting_group_id: Diagnostic sorting_weight: 21 - platform: modbus_controller id: cloud_status name: "Cloud status" modbus_controller_id: mt register_type: holding address: 30302 raw_encode: NONE icon: mdi:home-heart entity_category: diagnostic skip_updates: 20 lambda: |- uint16_t int_mode = (data[item->offset] << 8) + data[item->offset+1]; ESP_LOGD("main","Parsed operation mode int : %d", int_mode); std::string mode_str; switch (int_mode) { case 0: mode_str = "Disconnected"; break; case 1: mode_str = "Connected"; break; } return mode_str; web_server: sorting_group_id: Diagnostic sorting_weight: 22 - platform: modbus_controller id: power_restriction_discharge name: "Power restriction" modbus_controller_id: mt register_type: holding address: 41010 raw_encode: NONE icon: mdi:home-heart entity_category: diagnostic skip_updates: 20 lambda: |- uint16_t int_mode = (data[item->offset] << 8) + data[item->offset+1]; ESP_LOGD("main","Parsed operation mode int : %d", int_mode); std::string mode_str; switch (int_mode) { case 0: mode_str = "Off"; break; case 1: mode_str = "800W limited"; break; } return mode_str; web_server: sorting_group_id: Diagnostic sorting_weight: 23 # Binaire sensoren binary_sensor: - platform: modbus_controller name: "Marstek PLL Abnormal Restart" id: "lilygo_rs485_marstek_pll_abnormal_restart" icon: mdi:flash-triangle modbus_controller_id: mt register_type: holding address: 36000 bitmask: 0x01 - platform: modbus_controller name: "Marstek Overtemperature Limit" icon: mdi:thermometer-alert id: "lilygo_rs485_marstek_overtemperature_limit" modbus_controller_id: mt register_type: holding address: 36000 bitmask: 0x02 - platform: modbus_controller name: "Marstek Low Temperature Limit" icon: mdi:thermometer-alert id: "lilygo_rs485_marstek_low_temperature_limit" modbus_controller_id: mt register_type: holding address: 36000 bitmask: 0x04 - platform: modbus_controller name: "Marstek Fan Abnormal Warning" icon: mdi:fan-alert id: "lilygo_rs485_marstek_fan_abnormal_warning" modbus_controller_id: mt register_type: holding address: 36000 bitmask: 0x08 - platform: modbus_controller name: "Marstek Low Battery SOC Warning" icon: mdi:battery-off-outline id: "lilygo_rs485_marstek_low_battery_soc_warning" modbus_controller_id: mt register_type: holding address: 36000 bitmask: 0x16 - platform: modbus_controller name: "Marstek Output Overcurrent Warning" icon: mdi:flash-triangle id: "lilygo_rs485_marstek_output_overcurrent_warning" modbus_controller_id: mt register_type: holding address: 36000 bitmask: 0x32 - platform: modbus_controller name: "Marstek Abnormal Line Sequence Detection" icon: mdi:flash-triangle id: "lilygo_rs485_marstek_abnormal_line_sequence_detection" modbus_controller_id: mt register_type: holding address: 36000 bitmask: 0x64 - platform: modbus_controller name: "Marstek Wifi Abnormal" icon: mdi:wifi-alert id: "lilygo_rs485_marstek_wifi_abnormal" modbus_controller_id: mt register_type: holding address: 36001 bitmask: 0x01 - platform: modbus_controller name: "Marstek BLE abnormal" icon: mdi:bluetooth-off id: "lilygo_rs485_marstek_ble_abnormal" modbus_controller_id: mt register_type: holding address: 36001 bitmask: 0x02 - platform: modbus_controller name: "Marstek Network abnormal" icon: mdi:network-off id: "lilygo_rs485_marstek_network_abnormal" modbus_controller_id: mt register_type: holding address: 36001 bitmask: 0x04 - platform: modbus_controller name: "Marstek CT connection abnormal" icon: mdi:robot-vacuum-alert id: "lilygo_rs485_marstek_ct_connection_abnormal" modbus_controller_id: mt register_type: holding address: 36001 bitmask: 0x08 - platform: modbus_controller name: "Marstek Grid overvoltage" icon: mdi:flash-triangle id: "lilygo_rs485_marstek_grid_overvoltage" modbus_controller_id: mt register_type: holding address: 36100 bitmask: 0x01 - platform: modbus_controller name: "Marstek Grid undervoltage" icon: mdi:flash-triangle-outline id: "lilygo_rs485_marstek_grid_undervoltage" modbus_controller_id: mt register_type: holding address: 36100 bitmask: 0x02 - platform: modbus_controller name: "Marstek Grid overfrequency" icon: mdi:flash-triangle id: "lilygo_rs485_marstek_grid_overfrequency" modbus_controller_id: mt register_type: holding address: 36100 bitmask: 0x04 - platform: modbus_controller name: "Marstek Grid underfrequency" icon: mdi:flash-triangle id: "lilygo_rs485_marstek_grid_underfrequency" modbus_controller_id: mt register_type: holding address: 36100 bitmask: 0x08 - platform: modbus_controller name: "Marstek Grid peak voltage abnormal" icon: mdi:alert-plus id: "lilygo_rs485_marstek_grid_peak_voltage_abnormal" modbus_controller_id: mt register_type: holding address: 36100 bitmask: 0x10 - platform: modbus_controller name: "Marstek Current Dcover" icon: mdi:flash-triangle id: "lilygo_rs485_marstek_current_dcover" modbus_controller_id: mt register_type: holding address: 36100 bitmask: 0x20 - platform: modbus_controller name: "Marstek Voltage Dcover" icon: mdi:flash-triangle id: "lilygo_rs485_marstek_voltage_dcover" modbus_controller_id: mt register_type: holding address: 36100 bitmask: 0x40 - platform: modbus_controller name: "Marstek BAT overvoltage" icon: mdi:flash-triangle id: "lilygo_rs485_marstek_bat_overvoltage" modbus_controller_id: mt register_type: holding address: 36101 bitmask: 0x01 - platform: modbus_controller name: "Marstek BAT undervoltage" icon: mdi:flash-triangle-outline id: "lilygo_rs485_marstek_bat_undervoltage" modbus_controller_id: mt register_type: holding address: 36101 bitmask: 0x02 - platform: modbus_controller name: "Marstek BAT overcurrent" icon: mdi:wave-undercurrent id: "lilygo_rs485_marstek_bat_overcurrent" modbus_controller_id: mt register_type: holding address: 36101 bitmask: 0x04 - platform: modbus_controller name: "Marstek BAT low SOC" icon: mdi:battery-off-outline id: "lilygo_rs485_marstek_bat_low_soc" modbus_controller_id: mt register_type: holding address: 36101 bitmask: 0x08 - platform: modbus_controller name: "Marstek BAT communication failure" icon: mdi:flash-triangle id: "lilygo_rs485_marstek_bat_communication_failure" modbus_controller_id: mt register_type: holding address: 36101 bitmask: 0x10 - platform: modbus_controller name: "Marstek BMS protect" icon: mdi:flash-triangle id: "lilygo_rs485_marstek_bms_protect" modbus_controller_id: mt register_type: holding address: 36101 bitmask: 0x20 - platform: status name: "WiFi Status" id: "lilygo_rs485_wifi_status" # Sensoren sensor: - name: "Marstek Battery Wifi Signal Strength" id: lilygo_rs485_marstek_battery_wifi_signal_strenght icon: mdi:wifi platform: modbus_controller modbus_controller_id: mt register_type: holding address: 30303 value_type: U_WORD unit_of_measurement: "dBm" filters: - multiply: -1 accuracy_decimals: 0 web_server: sorting_group_id: Diagnostic sorting_weight: 7 - platform: copy # Reports the Battery signal strength in % source_id: lilygo_rs485_marstek_battery_wifi_signal_strenght name: "Marstek Battery Wifi Signal" id: battery_wifi_signal_proc filters: - lambda: return min(max(2 * (x + 100.0), 0.0), 100.0); unit_of_measurement: " %" entity_category: diagnostic device_class: "" icon: mdi:wifi web_server: sorting_group_id: Diagnostic sorting_weight: 6 - platform: modbus_controller id: inverter_state # No name, since it's internal icon: mdi:state-machine modbus_controller_id: mt register_type: holding address: 35100 value_type: U_WORD internal: true # Hides from Home Assistant web_server: sorting_group_id: Info sorting_weight: 30 - platform: modbus_controller id: software_version # No name, since it's internal icon: mdi:factory modbus_controller_id: mt register_type: holding address: 31100 value_type: U_WORD accuracy_decimals: 0 skip_updates: 60 # 5 minutes internal: true # Hides from Home Assistant on_value: then: - lambda: |- int version = (int)x; char buf[5]; sprintf(buf, "V%d", version); id(software_version_text).publish_state(buf); - platform: modbus_controller id: firmware_version # No name, since it's internal icon: mdi:factory modbus_controller_id: mt register_type: holding address: 31101 value_type: U_WORD accuracy_decimals: 0 skip_updates: 60 # 5 minutes internal: true # Hides from Home Assistant on_value: then: - lambda: |- int version = (int)x; char buf[5]; sprintf(buf, "V%d", version); id(firmware_version_text).publish_state(buf); - platform: modbus_controller id: bms_version icon: mdi:factory modbus_controller_id: mt register_type: holding address: 31102 value_type: U_WORD accuracy_decimals: 0 skip_updates: 60 # 5 minutes internal: true on_value: then: - lambda: |- int version = (int)x; char buf[5]; sprintf(buf, "V%d", version); id(bms_version_text).publish_state(buf); - name: "Marstek Battery Voltage (Average)" id: "lilygo_rs485_marstek_battery_voltage_average" icon: mdi:sine-wave platform: modbus_controller modbus_controller_id: mt register_type: holding address: 32100 value_type: U_WORD unit_of_measurement: "V" device_class: voltage accuracy_decimals: 2 state_class: measurement filters: - multiply: 0.01 web_server: sorting_group_id: Info sorting_weight: 16 - name: "Marstek Battery Current (Average)" id: "lilygo_rs485_marstek_battery_current_average" icon: mdi:current-dc platform: modbus_controller modbus_controller_id: mt register_type: holding address: 32101 value_type: S_WORD unit_of_measurement: "A" device_class: current accuracy_decimals: 2 state_class: measurement filters: - multiply: 0.01 web_server: sorting_group_id: Info sorting_weight: 15 - name: "Marstek Battery Power" id: "lilygo_rs485_marstek_battery_power" platform: modbus_controller modbus_controller_id: mt register_type: holding address: 32102 value_type: S_DWORD unit_of_measurement: "W" device_class: power state_class: measurement accuracy_decimals: 0 skip_updates: 2 # 10 seconds web_server: sorting_group_id: Info sorting_weight: 14 - name: "Marstek Battery State Of Charge" id: "lilygo_rs485_marstek_battery_state_of_charge" # Was marstek_soc platform: modbus_controller device_class: battery state_class: measurement modbus_controller_id: mt register_type: holding address: 32104 value_type: U_WORD unit_of_measurement: "%" accuracy_decimals: 0 web_server: sorting_group_id: Info sorting_weight: 5 # Slow Sensor - name: "Marstek Battery Total Energy" id: "lilygo_rs485_marstek_battery_total_energy" # Was marstek_total_energy icon: mdi:battery-charging-100 platform: modbus_controller device_class: energy_storage state_class: measurement modbus_controller_id: mt register_type: holding address: 32105 value_type: U_WORD unit_of_measurement: "kWh" accuracy_decimals: 3 filters: - multiply: 0.001 # Firmware 148: 0.001 / Firmware 147: 0.01 skip_updates: 60 # 5 minutes web_server: sorting_group_id: Info sorting_weight: 7 - platform: template name: "Marstek Battery Remaining Capacity" id: "lilygo_rs485_marstek_battery_remaining_capacity" icon: mdi:battery-arrow-down-outline unit_of_measurement: "kWh" accuracy_decimals: 2 update_interval: 300s lambda: |- if (id(lilygo_rs485_marstek_battery_total_energy).has_state() && id(lilygo_rs485_marstek_battery_state_of_charge).has_state()) { float total_energy = id(lilygo_rs485_marstek_battery_total_energy).state; float soc = id(lilygo_rs485_marstek_battery_state_of_charge).state / 100.0; return roundf(total_energy * soc * 100) / 100; // Ensures two decimal places } return NAN; web_server: sorting_group_id: Info sorting_weight: 6 - name: "Marstek AC Voltage" id: "lilygo_rs485_marstek_ac_voltage" icon: mdi:current-ac platform: modbus_controller modbus_controller_id: mt register_type: holding address: 32200 value_type: U_WORD unit_of_measurement: "V" device_class: voltage state_class: measurement accuracy_decimals: 1 filters: - multiply: 0.1 web_server: sorting_group_id: Info sorting_weight: 3 - name: "Marstek AC Current" id: "lilygo_rs485_marstek_ac_current" icon: mdi:current-ac platform: modbus_controller modbus_controller_id: mt register_type: holding address: 32201 value_type: U_WORD unit_of_measurement: "A" device_class: current state_class: measurement accuracy_decimals: 2 filters: - multiply: 0.01 web_server: sorting_group_id: Info sorting_weight: 2 # Slow Sensor - name: "Marstek AC Power" id: "lilygo_rs485_marstek_ac_power" icon: mdi:flash platform: modbus_controller modbus_controller_id: mt register_type: holding address: 32202 value_type: S_DWORD unit_of_measurement: "W" device_class: power state_class: measurement accuracy_decimals: 0 skip_updates: 2 # 10 seconds web_server: sorting_group_id: Info sorting_weight: 1 # - name: "Marstek AC Offgrid Voltage" # id: "lilygo_rs485_marstek_ac_offgrid_voltage" # icon: mdi:sine-wave # platform: modbus_controller # modbus_controller_id: mt # state_class: measurement # register_type: holding # address: 32300 # value_type: U_WORD # unit_of_measurement: "V" # device_class: voltage # accuracy_decimals: 2 # filters: # - multiply: 0.1 # web_server: # sorting_group_id: Info # sorting_weight: 26 # - name: "Marstek AC Offgrid Current" # id: "lilygo_rs485_marstek_ac_offgrid_current" # icon: mdi:current-ac # platform: modbus_controller # state_class: measurement # modbus_controller_id: mt # register_type: holding # address: 32301 # value_type: U_WORD # unit_of_measurement: "A" # device_class: current # accuracy_decimals: 2 # filters: # - multiply: 0.01 # web_server: # sorting_group_id: Info # sorting_weight: 27 # - name: "Marstek AC Offgrid Power" # id: "lilygo_rs485_marstek_ac_offgrid_power" # icon: mdi:flash # platform: modbus_controller # state_class: measurement # modbus_controller_id: mt # register_type: holding # address: 32302 # value_type: S_DWORD # unit_of_measurement: "W" # device_class: power # state_class: measurement # accuracy_decimals: 0 # web_server: # sorting_group_id: Info # sorting_weight: 28 - name: "Marstek Total Charging Energy" id: "lilygo_rs485_marstek_total_charging_energy" icon: mdi:chart-bar platform: modbus_controller modbus_controller_id: mt register_type: holding address: 33000 value_type: U_DWORD unit_of_measurement: "kWh" device_class: energy state_class: total_increasing accuracy_decimals: 2 filters: - multiply: 0.01 register_count: 2 web_server: sorting_group_id: Info sorting_weight: 12 - name: "Marstek Total Discharging Energy" id: "lilygo_rs485_marstek_total_discharging_energy" icon: mdi:chart-bar platform: modbus_controller modbus_controller_id: mt register_type: holding address: 33002 value_type: U_DWORD unit_of_measurement: "kWh" device_class: energy state_class: total_increasing accuracy_decimals: 2 filters: - multiply: 0.01 register_count: 2 web_server: sorting_group_id: Info sorting_weight: 13 - name: "Marstek Daily Charging Energy" id: "lilygo_rs485_marstek_daily_charging_energy" icon: mdi:chart-bar platform: modbus_controller modbus_controller_id: mt register_type: holding address: 33004 value_type: U_DWORD unit_of_measurement: "kWh" device_class: energy state_class: total_increasing accuracy_decimals: 2 filters: - multiply: 0.01 register_count: 2 web_server: sorting_group_id: Info sorting_weight: 8 - name: "Marstek Daily Discharging Energy" id: "lilygo_rs485_marstek_daily_discharging_energy" icon: mdi:chart-bar platform: modbus_controller modbus_controller_id: mt register_type: holding address: 33006 value_type: U_DWORD unit_of_measurement: "kWh" device_class: energy state_class: total_increasing accuracy_decimals: 2 filters: - multiply: 0.01 register_count: 2 web_server: sorting_group_id: Info sorting_weight: 9 # Slow Sensor - name: "Marstek Monthly Charging Energy" id: "lilygo_rs485_marstek_monthly_charging_energy" icon: mdi:chart-bar platform: modbus_controller modbus_controller_id: mt register_type: holding address: 33008 value_type: U_DWORD unit_of_measurement: "kWh" device_class: energy state_class: total_increasing accuracy_decimals: 2 filters: - multiply: 0.01 register_count: 2 skip_updates: 60 # 5 minutes web_server: sorting_group_id: Info sorting_weight: 10 # Slow Sensor - name: "Marstek Monthly Discharging Energy" id: "lilygo_rs485_marstek_monthly_discharging_energy" icon: mdi:chart-bar platform: modbus_controller modbus_controller_id: mt register_type: holding address: 33010 value_type: U_DWORD unit_of_measurement: "kWh" device_class: energy state_class: total_increasing accuracy_decimals: 2 filters: - multiply: 0.01 register_count: 2 skip_updates: 60 # 5 minutes web_server: sorting_group_id: Info sorting_weight: 11 - name: "Marstek Internal Temperature" id: "lilygo_rs485_marstek_internal_temperature" icon: mdi:thermometer platform: modbus_controller modbus_controller_id: mt register_type: holding address: 35000 value_type: S_WORD unit_of_measurement: "°C" device_class: temperature state_class: measurement accuracy_decimals: 1 filters: - multiply: 0.1 skip_updates: 60 # 5 minutes web_server: sorting_group_id: Info sorting_weight: 19 - name: "Marstek Internal MOS1 Temperature" id: "lilygo_rs485_marstek_internal_mos1_temperature" icon: mdi:thermometer platform: modbus_controller modbus_controller_id: mt register_type: holding address: 35001 value_type: S_WORD unit_of_measurement: "°C" device_class: temperature state_class: measurement accuracy_decimals: 1 filters: - multiply: 0.1 skip_updates: 60 # 5 minutes web_server: sorting_group_id: Info sorting_weight: 20 # Slow Sensor - name: "Marstek Internal MOS2 Temperature" id: "lilygo_rs485_marstek_internal_mos2_temperature" icon: mdi:thermometer platform: modbus_controller modbus_controller_id: mt register_type: holding address: 35002 value_type: S_WORD unit_of_measurement: "°C" device_class: temperature state_class: measurement accuracy_decimals: 1 skip_updates: 60 # 5 minutes filters: - multiply: 0.1 web_server: sorting_group_id: Info sorting_weight: 21 - name: "Marstek Max. Cell Temperature" id: "lilygo_rs485_marstek_max_cell_temperature" icon: mdi:thermometer platform: modbus_controller modbus_controller_id: mt register_type: holding address: 35010 value_type: S_WORD unit_of_measurement: "°C" device_class: temperature state_class: measurement accuracy_decimals: 1 skip_updates: 60 # 5 minutes filters: - multiply: 1 web_server: sorting_group_id: Info sorting_weight: 22 - name: "Marstek Min. Cell Temperature" id: "lilygo_rs485_marstek_min_cell_temperature" icon: mdi:thermometer platform: modbus_controller modbus_controller_id: mt register_type: holding address: 35011 value_type: S_WORD unit_of_measurement: "°C" device_class: temperature state_class: measurement accuracy_decimals: 1 filters: - multiply: 1 web_server: sorting_group_id: Info sorting_weight: 23 - name: "Marstek Battery Charge Voltage Limit" id: "lilygo_rs485_marstek_battery_charge_voltage_limit" icon: mdi:sine-wave platform: modbus_controller modbus_controller_id: mt register_type: holding address: 35110 value_type: U_WORD unit_of_measurement: "V" device_class: voltage accuracy_decimals: 1 state_class: measurement filters: - multiply: 0.1 web_server: sorting_group_id: Info sorting_weight: 16 - name: "Marstek Battery Charge Current Limit" id: "lilygo_rs485_marstek_battery_charge_current_limit" icon: mdi:current-dc platform: modbus_controller modbus_controller_id: mt register_type: holding address: 35111 value_type: S_WORD unit_of_measurement: "A" device_class: current accuracy_decimals: 0 state_class: measurement skip_updates: 60 # 5 minutes filters: - multiply: 0.01 web_server: sorting_group_id: Info sorting_weight: 17 - name: "Marstek Battery Discharge Current Limit" id: "lilygo_rs485_marstek_battery_discharge_current_limit" platform: modbus_controller modbus_controller_id: mt register_type: holding address: 35112 value_type: S_WORD unit_of_measurement: "A" device_class: current accuracy_decimals: 0 skip_updates: 60 # 5 minutes state_class: measurement filters: - multiply: 0.01 web_server: sorting_group_id: Info sorting_weight: 18 - name: "Marstek Battery Maximum Cell Voltage" platform: modbus_controller icon: mdi:sine-wave modbus_controller_id: mt register_type: holding address: 37007 value_type: U_WORD unit_of_measurement: "V" device_class: voltage accuracy_decimals: 2 state_class: measurement filters: - multiply: 0.001 id: marstek_max_cell_voltage skip_updates: 10 web_server: sorting_group_id: Info sorting_weight: 24 - name: "Marstek Battery Minimum Cell Voltage" platform: modbus_controller icon: mdi:sine-wave modbus_controller_id: mt register_type: holding address: 37008 value_type: U_WORD unit_of_measurement: "V" device_class: voltage accuracy_decimals: 2 state_class: measurement filters: - multiply: 0.001 id: marstek_min_cell_voltage skip_updates: 10 web_server: sorting_group_id: Info sorting_weight: 25 - platform: template name: "Marstek Battery Cell Voltage Delta" icon: mdi:sine-wave unit_of_measurement: "V" device_class: voltage accuracy_decimals: 3 state_class: measurement lambda: |- if (isnan(id(marstek_max_cell_voltage).state) || isnan(id(marstek_min_cell_voltage).state)) { return NAN; } return id(marstek_max_cell_voltage).state - id(marstek_min_cell_voltage).state; web_server: sorting_group_id: Info sorting_weight: 26 - platform: wifi_signal name: "WiFi Signal Strength" icon: mdi:wifi id: "wifi_strength" # Was wifi_strength update_interval: 30s web_server: sorting_group_id: Diagnostic sorting_weight: 6 # An internal sensor to check Modbus communication status. - platform: modbus_controller modbus_controller_id: mt name: "Modbus Status" icon: mdi:transit-connection id: "modbus_status" # Was modbus_status register_type: holding address: 32104 # Using the Battery SOC register as a reference value_type: U_WORD internal: true web_server: sorting_group_id: Diagnostic sorting_weight: 15 # Instellingen en modi (Select en Number) select: - name: "Marstek RS485 Control Mode" id: "lilygo_rs485_marstek_rs485_control_mode" icon: mdi:connection platform: modbus_controller modbus_controller_id: mt address: 42000 value_type: U_WORD optionsmap: "enable": 21930 "disable": 21947 skip_updates: 2 # 10 seconds web_server: sorting_group_id: Control sorting_weight: 1 - name: "Marstek Forcible Charge/Discharge" id: "lilygo_rs485_marstek_forcible_chargedischarge" platform: modbus_controller modbus_controller_id: mt address: 42010 value_type: U_WORD optionsmap: "stop": 0 "charge": 1 "discharge": 2 skip_updates: 2 # 10 seconds web_server: sorting_group_id: Control sorting_weight: 4 - name: "Marstek Backup Function" id: "lilygo_rs485_marstek_backup_function" platform: modbus_controller modbus_controller_id: mt address: 41200 value_type: U_WORD optionsmap: "enable": 0 "disable": 1 skip_updates: 2 # 10 seconds web_server: sorting_group_id: Control sorting_weight: 3 - name: "Marstek User Work Mode" id: "lilygo_rs485_marstek_user_work_mode" icon: mdi:auto-mode platform: modbus_controller modbus_controller_id: mt address: 43000 value_type: U_WORD optionsmap: "manual": 0 "anti-feed": 1 "ai": 2 skip_updates: 2 # 10 seconds web_server: sorting_group_id: Control sorting_weight: 2 number: - name: "Marstek Forcible Charge Power" id: "lilygo_rs485_marstek_forcible_charge_power" icon: mdi:tune-variant mode: box platform: modbus_controller modbus_controller_id: mt register_type: holding address: 42020 value_type: U_WORD unit_of_measurement: "W" min_value: 0 max_value: 2500 step: 1 skip_updates: 2 # 10 seconds web_server: sorting_group_id: Control sorting_weight: 5 - name: "Marstek Charge To SOC" id: "lilygo_rs485_marstek_charge_to_soc" icon: mdi:battery-charging-medium mode: box platform: modbus_controller modbus_controller_id: mt register_type: holding address: 42011 value_type: U_WORD unit_of_measurement: "%" min_value: 12 max_value: 100 step: 1 web_server: sorting_group_id: Control sorting_weight: 9 - name: "Marstek Forcible Discharge Power" id: "lilygo_rs485_marstek_forcible_discharge_power" icon: mdi:tune-variant mode: box platform: modbus_controller modbus_controller_id: mt register_type: holding address: 42021 value_type: U_WORD unit_of_measurement: "W" min_value: 0 max_value: 2500 step: 1 skip_updates: 2 # 10 seconds web_server: sorting_group_id: Control sorting_weight: 6 - name: "Marstek Charging Cutoff Capacity" id: "lilygo_rs485_marstek_charging_cutoff_capacity" icon: mdi:battery-90 platform: modbus_controller modbus_controller_id: mt register_type: holding address: 44000 value_type: U_WORD unit_of_measurement: "%" min_value: 80 max_value: 100 multiply: 10 - name: "Marstek Discharging Cutoff Capacity" id: "lilygo_rs485_marstek_discharging_cutoff_capacity" icon: mdi:battery-10 platform: modbus_controller modbus_controller_id: mt register_type: holding address: 44001 value_type: U_WORD unit_of_measurement: "%" min_value: 12 max_value: 30 multiply: 10 - name: "Marstek Max. Charge Power" id: "lilygo_rs485_marstek_max_charge_power" icon: mdi:tune-variant mode: box platform: modbus_controller modbus_controller_id: mt register_type: holding address: 44002 value_type: U_WORD unit_of_measurement: "W" min_value: 0 max_value: 2500 step: 1 # Slow Sensor - name: "Marstek Max. Discharge Power" id: "lilygo_rs485_marstek_max_discharge_power" icon: mdi:tune-variant mode: box platform: modbus_controller modbus_controller_id: mt register_type: holding address: 44003 value_type: U_WORD unit_of_measurement: "W" min_value: 0 max_value: 2500 step: 1 skip_updates: 2 # 10 seconds ############################################################################### # LED ############################################################################### light: - platform: esp32_rmt_led_strip rgb_order: GRB chipset: WS2812 pin: GPIO4 num_leds: 1 name: "Status LED" id: status_led interval: - interval: 5s then: - lambda: |- ESP_LOGD("status", "Modbus: %.0f, WiFi: %.0f", id(modbus_status).state, id(wifi_strength).state); - if: condition: lambda: |- return !isnan(id(modbus_status).state) && id(wifi_strength).state > -80; then: - light.turn_on: id: status_led red: 0% green: 100% # 🟢 Green = Modbus OK & WiFi strong blue: 0% else: - if: condition: lambda: |- return isnan(id(modbus_status).state) && id(wifi_strength).state < -80; then: - light.turn_on: id: status_led red: 100% # 🟣 Purple = Both Modbus & WiFi failed green: 0% blue: 100% else: - if: condition: lambda: |- return id(wifi_strength).state < -80; then: - light.turn_on: id: status_led red: 0% green: 0% blue: 100% # 🔵 Blue = Weak WiFi signal (< -80 dBm) else: - light.turn_on: id: status_led red: 100% # 🔴 Red = Modbus error, WiFi OK green: 0% blue: 0%
Ik heb de log in Gemini gegooid maar daar kom ik niet veel verder mee maar jij misschien wel?pj schreef op zondag 14 september 2025 @ 11:02:
Nav post in 'gewone' topic hier maar verder:
Ik heb inmiddels de code van @fonske (MarstekVenus-M5stackRS485) in die van @superduper1969 (MarstekVenus-LilygoRS485) gezet, En daarmee krijg waardes in EVCC.
Helaas krijg ik inderdaad dropouts van Vermogen (AC Power) en Laden (Soc). Zoals @AUijtdehaag al voorspelde.
[...]
Het lijkt erop dat de het modbusbericht out of sync loopt met het verzenden via de modbus_bridge.
Ik heb te weinig kaas gegeten van ESP32 om te weten welke richting ik op moet zoeken. Pielen met de intervals maakt iig weinig uit.
Iemand?
[...]
Ik heb in de lilygo-rs485.yaml een aantal sensoren aangemerkt als "Slow Sensor"
Dit zijn sensoren waarbij de Marstek Fimware langer doet over het genereren van het antwoord dan de maximale tijd die ervoor staat in Modbus, daar is dus niet veel aan te doen.
Voor de Home Assistant/ESPHome integratie maakt dit niet uit maar misschien wel voor EVCC?
Ik zal een poging wagen.
MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
Probeer dit eens?
Afgeleid van: https://github.com/rosenrot00/esphome_modbus_bridge
Ik kan natuurlijk niets testen.
Natuurlijk wel je keys & OTA PW aanpassen.
| 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
 | esphome:
  name: lilygo2rs485bridge
  friendly_name: LILYGO2RS485Bridge
  min_version: 2024.11.0
  name_add_mac_suffix: false
esp32:
  board: esp32dev
  framework:
    type: arduino
# Enable logging
logger:
  # level: VERY_VERBOSE
  
# Enable Home Assistant API
api:
  encryption:
    key: "YourKeyHere"
ota:
  - platform: esphome
    password: "YourPasswordHere"
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Lilygo-Rs485 Fallback Hotspot"
    password: "GBDjgqkttbFLa93eFCaj"
external_components:
  - source:
      type: git
      url: https://github.com/rosenrot00/esphome_modbus_bridge
    components: [modbus_bridge]
# Set pins required for LilyGo T-CAN485 board
output:
  - platform: gpio
    id: ENABLE_PIN # Enable the chip
    pin:
      number: GPIO19
      inverted: true
  - platform: gpio
    id: SE_PIN # Enable autodirection
    pin:
      number: GPIO17
      inverted: true
  - platform: gpio
    id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip
    pin:
      number: GPIO16
      inverted: true
uart:
  id: uart_bus
    rx_pin: GPIO21
    tx_pin: GPIO22
    baud_rate: 115200
    data_bits: 8
    stop_bits: 1
    parity: NONE
    rx_buffer_size: 256         # min. 256 recommended; increase for very long RTU responses
modbus_bridge:
  id: mb_bridge
  uart_id: uart_bus
  tcp_port: 502               # TCP port
  tcp_poll_interval: 50       # ms between TCP polls
  tcp_client_timeout: 60000   # ms inactivity until TCP client is disconnected
  tcp_allowed_clients: 4      # clamped to minimum 1, use with care as it increases memory usage
  rtu_response_timeout: 3000  # ms, clamped internally to minimum of 10 ms)
switch:
  - platform: template
    name: "Modbus Bridge Debug"
    id: modbus_debug_switch
    restore_mode: RESTORE_DEFAULT_OFF  # debug disabled by default; persists across reboots
    turn_on_action:
      - lambda: |-
          id(mb_bridge).set_debug(true);
          id(modbus_debug_switch).publish_state(true);
    turn_off_action:
      - lambda: |-
          id(mb_bridge).set_debug(false);
          id(modbus_debug_switch).publish_state(false); | 
MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
Ik zou er de webserver wel in houden, via de debug switch zie je de communicatiesuperduper1969 schreef op zondag 14 september 2025 @ 12:36:
@pj
Probeer dit eens?
Afgeleid van: https://github.com/rosenrot00/esphome_modbus_bridge
Ik kan natuurlijk niets testen.
Natuurlijk wel je keys & OTA PW aanpassen.
code:
esphome: name: lilygo2rs485bridge friendly_name: LILYGO2RS485Bridge min_version: 2024.11.0 name_add_mac_suffix: false esp32: board: esp32dev framework: type: arduino # Enable logging logger: # level: VERY_VERBOSE # Enable Home Assistant API api: encryption: key: "YourKeyHere" ota: - platform: esphome password: "YourPasswordHere" wifi: ssid: !secret wifi_ssid password: !secret wifi_password # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: "Lilygo-Rs485 Fallback Hotspot" password: "GBDjgqkttbFLa93eFCaj" external_components: - source: type: git url: https://github.com/rosenrot00/esphome_modbus_bridge components: [modbus_bridge] # Set pins required for LilyGo T-CAN485 board output: - platform: gpio id: ENABLE_PIN # Enable the chip pin: number: GPIO19 inverted: true - platform: gpio id: SE_PIN # Enable autodirection pin: number: GPIO17 inverted: true - platform: gpio id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip pin: number: GPIO16 inverted: true uart: id: uart_bus rx_pin: GPIO21 tx_pin: GPIO22 baud_rate: 115200 data_bits: 8 stop_bits: 1 parity: NONE rx_buffer_size: 256 # min. 256 recommended; increase for very long RTU responses modbus_bridge: id: mb_bridge uart_id: uart_bus tcp_port: 502 # TCP port tcp_poll_interval: 50 # ms between TCP polls tcp_client_timeout: 60000 # ms inactivity until TCP client is disconnected tcp_allowed_clients: 4 # clamped to minimum 1, use with care as it increases memory usage rtu_response_timeout: 3000 # ms, clamped internally to minimum of 10 ms) switch: - platform: template name: "Modbus Bridge Debug" id: modbus_debug_switch restore_mode: RESTORE_DEFAULT_OFF # debug disabled by default; persists across reboots turn_on_action: - lambda: |- id(mb_bridge).set_debug(true); id(modbus_debug_switch).publish_state(true); turn_off_action: - lambda: |- id(mb_bridge).set_debug(false); id(modbus_debug_switch).publish_state(false);
https://github.com/fonske..._bridge_only.yaml#L77-L85
@jp Beter gewoon de lilygo als modbus bridge gebruiken en de elfin HA yaml gebruiken met modbus tcp/ip
Heb dagen lang geprobeerd de dropouts te verbeteren/verhepen maar dat is niet gelukt. Dus het is OF/OF en niet EN/EN
De melder heeft ook een workaround gecreerd.
Is er iemand in aanraking gekomen met deze specifieke situatie?
Zou dit in de standaard yaml moeten worden meegenomen?
https://github.com/Superd...enus-LilygoRS485/issues/5
MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
Ik denk dat jouw reactie daar prima is. Als het vaker zou gebeuren, zouden we het ook vaker lezen. We hebben slechts een handjevol meldingen gehad en Marstek gaf bij sowieso 1 iemand aan dat de batterij vervangen moest worden vanwege deze meetfouten. Dus lijkt mij niet nodig om dit standaard te verwerken tenzij het echt vaker voorkomt.superduper1969 schreef op dinsdag 16 september 2025 @ 12:22:
Ik heb via GIT hub een melding gekregen dat de MT Venus firmware rare energiewaardes kan rapporteren als je de accu tot een bepaald treshhold percentage laat ontladen.
De melder heeft ook een workaround gecreerd.
Is er iemand in aanraking gekomen met deze specifieke situatie?
Zou dit in de standaard yaml moeten worden meegenomen?
https://github.com/Superd...enus-LilygoRS485/issues/5
"{\"id\":0,\"method\":\"Bat.GetStatus\",\"params\":{\"id\":0}}"
"{\"id\":0,\"method\":\"Es.GetStatus\",\"params\":{\"id\":0}}"
"{\"id\":0,\"method\":\"Es.GetMode\",\"params\":{\"id\":0}}"
"{\"id\":0,\"method\":\"Em.GetStatus\",\"params\":{\"id\":0}}"
"{\"id\":0,\"method\":\"Wifi.GetStatus\",\"params\":{\"id\":0}}"
"{\"id\":0,\"method\":\"Ble.GetStatus\",\"params\":{\"id\":0}}"
nu nog kijken of ik de MQTT werkend krijg in home assistent. verder hou ik het forum goed in de gaten
Marstek V3
Als ik het goed begrijp moet je de config aanpassen in de integratie en kan je zo de twee batterijen sturen via HA.
Multiple Powermeters
You can configure multiple powermeters by adding additional sections with the same prefix (e.g. [SHELLY<unique_suffix>]). Each powermeter should specify which client IP addresses are allowed to access it using the NETMASK setting.
When a storage system requests power values, the script will check the client IP address against the NETMASK settings of each powermeter and use the first that matches.
32
[HOMEASSISTANT_1]
IP = 192.168.1.105
PORT = 8123
HTTPS = True
ACCESSTOKEN = YOUR_ACCESS_TOKEN
CURRENT_POWER_ENTITY = sensor.current_power
# No NETMASK specified - will match all clients (0.0.0.0/0)
2 x Marstek Venus 5,12kwh v153 - Home Assistant - Huawei Sun2000-3ktl-l1 🇧🇪
Je kunt zo meerdere energiemeter bronnen toevoegen, niet meerdere batterijen. Meerdere batterijen aansturen is via de B2500 integratie volgens mij niet mogelijk. De logica om de load te verdelen zit namelijk bij Marstek in de CT002/3. Aangezien het slechts een energiemeter emuleert (die geen data bevat over hoe de load tussen de batterijen verdeelt moet worden) zullen beide batterijen proberen het volle vermogen te vragen/leveren.LodeBo schreef op woensdag 17 september 2025 @ 17:50:
Heeft er iemand twee batterijen via de B2500 integratie in HA draaien en dus zonder CT ?
Als ik het goed begrijp moet je de config aanpassen in de integratie en kan je zo de twee batterijen sturen via HA.
Multiple Powermeters
You can configure multiple powermeters by adding additional sections with the same prefix (e.g. [SHELLY<unique_suffix>]). Each powermeter should specify which client IP addresses are allowed to access it using the NETMASK setting.
When a storage system requests power values, the script will check the client IP address against the NETMASK settings of each powermeter and use the first that matches.
32
[HOMEASSISTANT_1]
IP = 192.168.1.105
PORT = 8123
HTTPS = True
ACCESSTOKEN = YOUR_ACCESS_TOKEN
CURRENT_POWER_ENTITY = sensor.current_power
# No NETMASK specified - will match all clients (0.0.0.0/0)
Dus het moet (in mijn geval)met CT003.
Het zou toch beter zijn om per batterij te ontladen dacht ik voor een betere RTE ?
Hoe heb jij dit aangepakt?
2 x Marstek Venus 5,12kwh v153 - Home Assistant - Huawei Sun2000-3ktl-l1 🇧🇪
Als je wilt dat de batterijen netjes de load verdelen, ben je aangewezen op de CT003 inderdaad. Of zelf op een of andere manier de batterijen gaan aansturen en load verdelen.LodeBo schreef op woensdag 17 september 2025 @ 18:05:
Duidelijk, thx.
Dus het moet (in mijn geval)met CT003.
Het zou toch beter zijn om per batterij te ontladen dacht ik voor een betere RTE ?
Hoe heb jij dit aangepakt?
In theorie kan het beter zijn, maar je zal zelf moeten bepalen of het de moeite waard is om hier zelf tegenaan te gaan programmeren. Ik zou eerst eens kijken hoe het werkt met de CT003 in jouw situatie.
Ik heb slechts 1 batterij en draai ook geen NOM, dus dit zijn geen vraagstukken die mij bezig houden
Ik snap niet echt wat ik fout doe maar ik krijg dit niet aan de praat.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:[Afbeelding]
- 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?
Heb een oude ethernet kabel open geknipt en aangesloten op de Elfin zoals hierboven maar ik krijg enkel timeouts in EVCC. Elfin report ook 0 bytes received aan de serial kant.
Hoe bepalen jullie exact wat de juiste color coding is?
Zoals mijn foto zou de goede color coding moeten zijn.GlennVd schreef op woensdag 17 september 2025 @ 22:07:
[...]
Hoe bepalen jullie exact wat de juiste color coding is?
Heb je misschien een twisted cable of T-568A kabel gepakt?
Kan je door de stekker heen kijken en verifiëren dat de aders op de T-568B volgorde zitten?
Marstek Venus-E V2 v153 - Marstek Venus-E V3 v112
Ik zie nu dat de home assistant hacs integratie van @[RNMC] Viper ook voor een groot aantal registers goed werkt. Het is mij onbekend of dit door de update van de Marstek komt of door de update van de integratie maar ik ben er blij mee.
3.2 kWp west 4.8 kWp zuid + growat MOD 7000TL3-X | Marstek venus-e v3.0 5,12kw v139 | Nibe VVM320 + Nibe F2040
Goed om te horen! Aangezien we nog een beetje in het duister tasten hoe nu zit met de Modbus, kan je laten weten welke registers/entities werken? Kunnen we het naast elkaar leggen met de gegevens van eerder.Demkes schreef op donderdag 18 september 2025 @ 14:34:
Ik heb zojuist, na 3 keer erom vragen, de update v139 ontvangen voor mijn v3. Hierdoor is de UTP functionaliteit nu actief en deze lijkt goed te werken. Ook is de API open gezet.
Ik zie nu dat de home assistant hacs integratie van @[RNMC] Viper ook voor een groot aantal registers goed werkt. Het is mij onbekend of dit door de update van de Marstek komt of door de update van de integratie maar ik ben er blij mee.
Enkel de onderstaande entities werken niet:pascallj schreef op donderdag 18 september 2025 @ 14:41:
[...]
Goed om te horen! Aangezien we nog een beetje in het duister tasten hoe nu zit met de Modbus, kan je laten weten welke registers/entities werken? Kunnen we het naast elkaar leggen met de gegevens van eerder.
- sensor.marstek_venus_modbus_ac_offgrid_power
- sensor.marstek_venus_modbus_mac_address
- sensor.marstek_venus_modbus_sn_code
- sensor.marstek_venus_modbus_bms_version
- sensor.marstek_venus_modbus_communication_module_firmware
- sensor.marstek_venus_modbus_ems_version
- sensor.marstek_venus_modbus_software_version
De rest lijkt goed te werken.
3.2 kWp west 4.8 kWp zuid + growat MOD 7000TL3-X | Marstek venus-e v3.0 5,12kw v139 | Nibe VVM320 + Nibe F2040
Meteen maar met deze node red flow begonnen voor de aansturing met 2 (of 3) batterijen
https://github.com/gitcod...de-red?tab=readme-ov-file
Weet iemand van wie die is? Werkt wel mooi met de PID regelaar, in ieder geval nu voor NOM.
Volgens mij heeft hij ook het Atom s3 lite met rs485 bordje, ik hoefde amper wat te wijzigen in de entities
[ Voor 13% gewijzigd door AUijtdehaag op 18-09-2025 17:38 ]
Ik heb geen registers aangepast, bezit een v2 dus weet ook niet goed in hoeverre de v3 anders is qua registers.Demkes schreef op donderdag 18 september 2025 @ 14:34:
Ik heb zojuist, na 3 keer erom vragen, de update v139 ontvangen voor mijn v3. Hierdoor is de UTP functionaliteit nu actief en deze lijkt goed te werken. Ook is de API open gezet.
Ik zie nu dat de home assistant hacs integratie van @[RNMC] Viper ook voor een groot aantal registers goed werkt. Het is mij onbekend of dit door de update van de Marstek komt of door de update van de integratie maar ik ben er blij mee.
He who controls the past, commands the future. He who commands the future, conquers the past.
Interessant!Thiske schreef op dinsdag 16 september 2025 @ 15:09:
Ruzie aan maken met node-red in home assistant om de Marstek V3 accu uit te kunnen lezen, maar ik heb vanuit de marstek support 2 bestanden gekregen, uiteindelijk krijg ik de info uit de accu via node-red door gebruik te maken van de volgende payload string.
"{\"id\":0,\"method\":\"Bat.GetStatus\",\"params\":{\"id\":0}}"
"{\"id\":0,\"method\":\"Es.GetStatus\",\"params\":{\"id\":0}}"
"{\"id\":0,\"method\":\"Es.GetMode\",\"params\":{\"id\":0}}"
"{\"id\":0,\"method\":\"Em.GetStatus\",\"params\":{\"id\":0}}"
"{\"id\":0,\"method\":\"Wifi.GetStatus\",\"params\":{\"id\":0}}"
"{\"id\":0,\"method\":\"Ble.GetStatus\",\"params\":{\"id\":0}}"
nu nog kijken of ik de MQTT werkend krijg in home assistent. verder hou ik het forum goed in de gaten
Was hier ook al ff mee begonnen, maar ik ben vrijwel leek op Node-Red gebied.
Ik had iets gemaakt met een UDP-Listener node met output naar een JSon decoder en daarna naar debugger. En een UDP-Sender node die dan de json geformateerde commando's stuurt, maar veel verder ben ik nog niet gekomen.
MT Venus E V2 (v155.216) / CT003 (v117) / Kaifa MA105 / LilyGo-RS485 / HA in Proxmox op NUC / 2970WP Solar ZZO / DIY-ESP32-EVSE / Ampera-E 64kWh
Met v114 kreeg ik geen werkende entities in Home Assistant. Met v139 nu wel. Mogelijk is er aan de kant van Marstek dan iets gewijzigd mbt de registers.[RNMC] Viper schreef op donderdag 18 september 2025 @ 18:56:
[...]
Ik heb geen registers aangepast, bezit een v2 dus weet ook niet goed in hoeverre de v3 anders is qua registers.
3.2 kWp west 4.8 kWp zuid + growat MOD 7000TL3-X | Marstek venus-e v3.0 5,12kw v139 | Nibe VVM320 + Nibe F2040
Kan ik hen beiden aansluiten op enkel één EW11 ? Juist de A en de B van beide batterijen en 5v van één batterij ? (ChatGPT zegt am de 5v van de batterij niet te gebruiken)
Dit zegt ChatGPT erover:
1 RS485 bekabeling (daisy-chain)
RS485 is een bus → alle apparaten worden parallel aangesloten op A en B:
Elfin RS485-A ──────────────┐
├──> Battery 1 RS485-A
└──> Battery 2 RS485-A
Elfin RS485-B ──────────────┐
├──> Battery 1 RS485-B
└──> Battery 2 RS485-B
GND’s (zwart) ook doorkoppelen.
Elfin voeden met 5 V apart (niet uit de batterij zelf halen).
Einde van de lijn → indien storing: terminatieweerstand 120 Ω plaatsen tussen A en B.
Kijk hier eens...XChallenge schreef op donderdag 18 september 2025 @ 21:06:
Kan iemand me helpen ? ik heb 2 Marstek Venus E V2 batterijen aangeschaft en zou die via Homey willen aansturen.
Kan ik hen beiden aansluiten op enkel één EW11 ? Juist de A en de B van beide batterijen en 5v van één batterij ? (ChatGPT zegt am de 5v van de batterij niet te gebruiken)
Dit zegt ChatGPT erover:
[...]
Marstek PIB Domotica integratie en je Energierekening
.NL | BYD Atto3 | PulsarPlus EV +Balancer | WP7.7K Z | 2 MT Venus 5.12KWh V155 - CT003 V117 - BMS 216 - Modi: AI | 2 Mitsubitshi HEAC | HA DS224+
En dat is het nadeel van ChatGPT gebruiken: het weet de hele context niet.XChallenge schreef op donderdag 18 september 2025 @ 21:06:
Kan iemand me helpen ? ik heb 2 Marstek Venus E V2 batterijen aangeschaft en zou die via Homey willen aansturen.
Kan ik hen beiden aansluiten op enkel één EW11 ? Juist de A en de B van beide batterijen en 5v van één batterij ? (ChatGPT zegt am de 5v van de batterij niet te gebruiken)
Dit zegt ChatGPT erover:
[...]
RS485 is een inderdaad een bus en er kunnen dus meerdere apparaten tegelijk op, maar om elk apparaat toch afzonderlijk te moeten kunnen aanspreken, zal je het standaard adres moeten veranderen van '1' naar iets anders ('2' bijv.) anders zullen beide apparaten reageren op verzoeken aan adres '1' en dat gaat natuurlijk niet werken en voor storing zorgen aangezien er maar 1 apparaat tegelijk actief mag zijn op de bus. Dit kan je doen daar '2' te sturen naar holding register 41100. Het gaat voor mij even te ver om nu uit te leggen hoe je dat precies voor elkaar moet krijgen. Ik heb ook geen EW11 hier dus zou niet weten hoe die werkt qua configuratie.
Qua aansluiten kan je beide batterijen inderdaad parallel aansluiten (doorlussen) op de A en B. In principe kan je wel voeding pakken van 1 van de 2 batterij om de Elfin te voeden, maar externe voeding zou ook werken. Terminatieweerstand zou ik mij niet druk om maken als het om kleine afstanden gaat.
Hi, Ik denk dat je beter hier hulp kan zoeken: https://community.homey.a...-venus-slim-aan-nl/140156XChallenge schreef op donderdag 18 september 2025 @ 21:06:
Kan iemand me helpen ? ik heb 2 Marstek Venus E V2 batterijen aangeschaft en zou die via Homey willen aansturen.
Kan ik hen beiden aansluiten op enkel één EW11 ? Juist de A en de B van beide batterijen en 5v van één batterij ? (ChatGPT zegt am de 5v van de batterij niet te gebruiken)
Dit zegt ChatGPT erover:
[...]
Dat gaat niet met een Elfin EW 11 maar met 2 Lilygo Tcan 485. (staat bij de reply's)
Link ook toegevoegd aan de topicstart!
[ Voor 6% gewijzigd door superduper1969 op 19-09-2025 12:10 ]
MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
Ik ben benieuwd of je met zoiets een hogere efficiëntie haalt dan dat je de accus zelf laat NOM'men. Maar als ze een tijdje draaien laat je vast wel weten waar je op uitkomt en dan kunnen we het vergelijkenAUijtdehaag schreef op donderdag 18 september 2025 @ 17:36:
Vandaag de 2e marstek ontvangen, een V2, nadat ik al een aantal maanden de V1 had
Meteen maar met deze node red flow begonnen voor de aansturing met 2 (of 3) batterijen
https://github.com/gitcod...de-red?tab=readme-ov-file
Weet iemand van wie die is? Werkt wel mooi met de PID regelaar, in ieder geval nu voor NOM.
Volgens mij heeft hij ook het Atom s3 lite met rs485 bordje, ik hoefde amper wat te wijzigen in de entities
3780wP (18x 210wP EC Solar) | 2x Marstek Venus E (5.12kWh)
Via support? Ik zit nu op v114, er komt inderdaad weinig of niks uit de registers.Demkes schreef op donderdag 18 september 2025 @ 19:43:
[...]
Met v114 kreeg ik geen werkende entities in Home Assistant. Met v139 nu wel. Mogelijk is er aan de kant van Marstek dan iets gewijzigd mbt de registers.
Begrijp dat je een lillygo (geflasht) ertussen kan hangen en dat je ze dat in HA kan integreren.
Ik heb ook gelezen dat 1 Lilly go 2 apparaten kan aansturen, hoe werkt dit fysiek en softwarematig?
Je voed de esp vanuit 1 batterij. Hoewel het kan met 1 device, is het niet handig.
Als er 1 esp uit valt heb je aan beide batterijen niks van sturing (behalve die van marstek zelf)
Wil je toch 1 esp eraan hangen:
pascallj in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"
Ik gebruik deze nodered flow voor 2 batterijen, en bevalt eigenlijk wel, aansturing via PID regeling
[ Voor 33% gewijzigd door AUijtdehaag op 19-09-2025 19:38 ]
Ja via support. Moest er wel 3 keer om vragen. Na ongeveer 2 weken kreeg ik een reactie.GlennVd schreef op vrijdag 19 september 2025 @ 16:12:
[...]
Via support? Ik zit nu op v114, er komt inderdaad weinig of niks uit de registers.
3.2 kWp west 4.8 kWp zuid + growat MOD 7000TL3-X | Marstek venus-e v3.0 5,12kw v139 | Nibe VVM320 + Nibe F2040
Alternatief: https://electropaultje.nl/product/6-pins-jst-kabel-female/gigabit schreef op zaterdag 20 september 2025 @ 11:47:
Iemand nog een 6pin stekker ter overname liggen in de buurt van Den Bosch/Vegel?
MT Venus 5.12KWh V153 - HW P1 - PV 2660Wp
Nu wil ik de Marstek via Modbus aansluiten op slave 1.
Maar welke Modbus integratie kun je nu het best kiezen is mij onduidelijk.
Na veel lezen op het forum ben ik terecht gekomen bij de 2 onderstaande maar weet of dit echt de goede keus is. Wie kan mij helpen heeft iemand hier ervaring mee? Of misschien iets anders aanbevelen?
1. ViperRNMC/marstek_venus_modbus
of
2. Via MQTT middels https://github.com/tomquist/hame-relay + https://github.com/tomquist/hm2mqtt
Zie r.reus in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"
[ Voor 13% gewijzigd door gigabit op 20-09-2025 21:35 ]
LG-HM071MR-U44
Ik spreek voor mezelf maar heb ze allemaal al eens getest.
En mijn conclusie is houdt het buiten Home assistent en buiten cloud.
Dus: Esp waar de uitlezing/ aansturing op draait en nodered voor de uitlezing/aansturimg
Tijdens een update van HA draait het gewoon door en ook zonder internet.
[ Voor 23% gewijzigd door AUijtdehaag op 20-09-2025 21:50 ]
Misschien kan je met de ViperRNMC wel iets realiseren.
Op zich ben ik tevreden Modbus via Home assistant waarmee ik nu ook de LG Wamtepomp aanstuur/bedien.AUijtdehaag schreef op zaterdag 20 september 2025 @ 21:44:
@gigabit
Ik spreek voor mezelf maar heb ze allemaal al eens getest.
En mijn conclusie is houdt het buiten Home assistent en buiten cloud.
Dus: Esp waar de uitlezing/ aansturing op draait en nodered voor de uitlezing/aansturimg
Tijdens een update van HA draait het gewoon door en ook zonder internet.
Ja tijdens een update is deze even uit de lucht. Maar als je dat weet houd je daar rekening mee en is het geen probleem.
Maar stel ik zou een Esp willen dan graag met POE aansluiting, neem aan dat die er ook zijn?
Wat dient er dan op de Esp gezet te worden?
[ Voor 8% gewijzigd door gigabit op 20-09-2025 22:03 ]
LG-HM071MR-U44
Maar waar stuur je de batterij mee aan dan,
Ik geloof niet dat iemand alle slimmigheden zoals een PID regelaar en verminderen van het aantal modbus calls ooit in een ha yaml gestopt heeft.
Daarom zeg in expliciet: ik spreek voor mezelf
Esp+poe+rs485 zijn zeldzaam maar zijn er wel incl display.
[ Voor 11% gewijzigd door AUijtdehaag op 20-09-2025 22:12 ]
Ik heb nu alleen de Marstek app in gebruik. Maar ik wil de Marstek gaan aansturen. Bijvoorbeeld wanneer er op Alfen laadpaal aan auto is aangesloten dan mag de accu (volle bak) terug leveren ....AUijtdehaag schreef op zaterdag 20 september 2025 @ 22:10:
@gigabit
Maar waar stuur je de batterij mee aan dan,
Ik geloof niet dat iemand alle slimmigheden zoals een PID regelaar en verminderen van het aantal modbus calls ooit in een ha yaml gestopt heeft.
Daarom zeg in expliciet: ik spreek voor mezelf
LG-HM071MR-U44
Als je POE en modbus tcp gebruikt incl laadpaal kijk dan eens naar evcc.io
Ook als addon te installeren in HA
Voor mijn doel is het te beperkt
Er draait een topic over op teeakers
[ Voor 10% gewijzigd door AUijtdehaag op 20-09-2025 22:22 ]
Ik heb de alfen laadpaal reeds in HA geïntegreerd en dat werkt naar behoren dus geen andere software daarvoor nodig.AUijtdehaag schreef op zaterdag 20 september 2025 @ 22:19:
@gigabit
Als je POE en modbus tcp gebruikt incl laadpaal kijk dan eens naar evcc.io
Ook als addon te installeren in HA
Voor mijn doel is het te beperkt
Er draait een topic over op teeakers
LG-HM071MR-U44
Ik ben een n00b sorry, maar ik wil supergraag mijn 2 Venus e v3's via mn home assistant kunnen uitlezen en bedienen. Ik heb de beide batterijen aangesloten op een eigen fase en een aparte groep, en verbonden met een CT002 meter. De CT003 heb ik wel, maar in de doos gelaten. Ik heb ook een HomeWizard P1 meter en zonnepanelen met een HWE KWH3 meter, alles HW heb ik al in HA. De CT002 meter ook.
In de bijkeuken waar de de accu's staan heb ik 2x utp getrokken naar de meterkast waar m'n internet switch en HA staan. De wifi in de bijkeuken is opzich prima, maar ideale wereld sluit ik alles wel bekabeld aan.
Wat is nou de beste optie voor mij? Een lillygo denk ik ivm ESPhome mogelijkheden, en dan zou ik denken de T-POE-Pro variant, alleen voor de tcan485 wifi optie van de Lilly zie ik goede beschrijvingen, maar voor de ethernet versie, wat mijn ideale oplssing is, weer niet. En klopt het dat ik beide batterijen op 1 Lilly kan aansluiten? Ik kom vaak een eind met chatgpt, alleen sommige dingen heeft ie fout en ik vind het zo zonde om spullen te kopen uitgaande van gpt om er vervolgens achter te komen dat het niet klopt.
Er zijn zoveel opties en zoveel pagina's met uitleg dat ik niet weet wat op mij van toepassing is. Ook lijken de meeste beschrijvingen voor de Venus v2 te zijn, maar ik heb dus een v3. Hoop dat iemand de moeite wil nemen om mij op weg te helpen, alvast dank!
Nee, deze logica zit er niet in. Mijn integratie maakt het alleen mogelijk om alle bekende registers uit te lezen of te schrijven.AUijtdehaag schreef op zaterdag 20 september 2025 @ 21:59:
[...]
Regelt ViperRNMC bijvoorbeeld nul op de meter en wat gebeurt er tijdens een update van HA?
Nom doe ik zelf via de standaard aansturing in de batterij, dat werkt op dit moment voor mij voldoende. Ben vooral zelf benieuwd hoe evcc dit in de toekomst gaat integreren met dynamische tarieven.
He who controls the past, commands the future. He who commands the future, conquers the past.
Ik denk dat de handigste optie is om even te wachten totdat de V3 firmware en Ontwikkelingen af te wachten, ik vermoed dat binnen 1 maand alles wel rond is, en dan kun je alles zonder extra hardware doen met de Interne API.Algje schreef op zondag 21 september 2025 @ 10:54:
Hallo,
Ik ben een n00b sorry, maar ik wil supergraag mijn 2 Venus e v3's via mn home assistant kunnen uitlezen en bedienen. Ik heb de beide batterijen aangesloten op een eigen fase en een aparte groep, en verbonden met een CT002 meter. De CT003 heb ik wel, maar in de doos gelaten. Ik heb ook een HomeWizard P1 meter en zonnepanelen met een HWE KWH3 meter, alles HW heb ik al in HA. De CT002 meter ook.
In de bijkeuken waar de de accu's staan heb ik 2x utp getrokken naar de meterkast waar m'n internet switch en HA staan. De wifi in de bijkeuken is opzich prima, maar ideale wereld sluit ik alles wel bekabeld aan.
Wat is nou de beste optie voor mij? Een lillygo denk ik ivm ESPhome mogelijkheden, en dan zou ik denken de T-POE-Pro variant, alleen voor de tcan485 wifi optie van de Lilly zie ik goede beschrijvingen, maar voor de ethernet versie, wat mijn ideale oplssing is, weer niet. En klopt het dat ik beide batterijen op 1 Lilly kan aansluiten? Ik kom vaak een eind met chatgpt, alleen sommige dingen heeft ie fout en ik vind het zo zonde om spullen te kopen uitgaande van gpt om er vervolgens achter te komen dat het niet klopt.
Er zijn zoveel opties en zoveel pagina's met uitleg dat ik niet weet wat op mij van toepassing is. Ook lijken de meeste beschrijvingen voor de Venus v2 te zijn, maar ik heb dus een v3. Hoop dat iemand de moeite wil nemen om mij op weg te helpen, alvast dank!
Wil je nu al aan de slag dan moet je 2xT-POE-Pro kopen. Technisch is het mogelijk om er 2 op 1 te zetten maar dit is nogal een gedoe die je niet op je hals wil halen voor die paar euro extra.
Ik heb de 2e en 3e even aangemaakt: https://github.com/Superduper1969/MarstekVenus-LilygoRS485
:no_upscale():strip_icc():strip_exif()/f/image/9jlga64SSXzSrqZjN2uhdsTn.jpg?f=user_large) 
                    MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
Wat goud dit zeg, top dank!superduper1969 schreef op zondag 21 september 2025 @ 11:48:
[...]
Ik denk dat de handigste optie is om even te wachten totdat de V3 firmware en Ontwikkelingen af te wachten, ik vermoed dat binnen 1 maand alles wel rond is, en dan kun je alles zonder extra hardware doen met de Interne API.
Wil je nu al aan de slag dan moet je 2xT-POE-Pro kopen. Technisch is het mogelijk om er 2 op 1 te zetten maar dit is nogal een gedoe die je niet op je hals wil halen voor die paar euro extra.
Ik heb de 2e en 3e even aangemaakt: https://github.com/Superduper1969/MarstekVenus-LilygoRS485
[Afbeelding]
Waarom denk je dat dit binnen een maand zonder aanvullende hardware kan? Als dat zo is dan is dat natuurlijk de mooise oplossing. Hoe zou dat er dan uit gaan zien?
- Converter is een EE1A van elfin
- EE1A krijgt stroom (groen LED'je aan netwerkpoort)
- Kabel is T568-B
- Andere kabel reeds geprobeerd
:strip_exif()/f/image/bhlngalZYRworMAcQqYSgOoV.jpg?f=fotoalbum_large)
/f/image/6xigZox5t8OXfT9mXIeoM34Y.png?f=fotoalbum_large)
/f/image/M8zNneX7aKCO67osoULQEvxj.png?f=fotoalbum_large) 
                                                [ Voor 5% gewijzigd door Rik Mertens op 21-09-2025 17:10 ]
◼ Elfin-EE10, Elfin-EE11: 5~18VDCRik Mertens schreef op zondag 21 september 2025 @ 14:55:
Venus V3 waarbij ik de modus communicatie niet aan de praat lijk te krijgen. Wat lijk ik verkeerd te doen?
- Converter is een EE1A van elfin
- EE1A krijgt stroom (groen LED'je aan netwerkpoort)
- Kabel is T568-B
- Andere kabel reeds geprobeerd
[Afbeelding]
[Afbeelding]
[Afbeelding]
◼ Elfin-EE10A, Elfin-EE11A: 9~36VDC
A model = 9~36VDC?
Maar je komt wel op de web-pagina, dus toch voldoende spanning?
Maar er wordt wel wat verzonden maar geen antwoord, A&B omdraaien?
[ Voor 4% gewijzigd door superduper1969 op 21-09-2025 17:37 ]
MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
V3 heeft Open API. https://eu.hamedata.com/e.../MarstekDeviceOpenApi.pdfAlgje schreef op zondag 21 september 2025 @ 12:05:
[...]
Wat goud dit zeg, top dank!
Waarom denk je dat dit binnen een maand zonder aanvullende hardware kan? Als dat zo is dan is dat natuurlijk de mooise oplossing. Hoe zou dat er dan uit gaan zien?
Er zijn er een aantal knutselsmurfen op dit forum op de Open-API een integratie aan het maken.
MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
Ik lees inderdaad veel over (aankomende?) API, al kan ik zelf in de app nog nergens terugvinden waar ik die kan activeren.
Huidige firmwareversie is 122
probeer eens hierRik Mertens schreef op zondag 21 september 2025 @ 18:00:
Instructies voor voeding op het toestel zelf zijn 5-36VDC. Zou dus prima moeten zijn (en ook ok aangezien ik inderdaad kan configureren.)
Ik lees inderdaad veel over (aankomende?) API, al kan ik zelf in de app nog nergens terugvinden waar ik die kan activeren.
Huidige firmwareversie is 122
https://rweijnen.github.io/marstek-venus-monitor/
Open API is ook beschikbaar voor de v1 en v2.
.NL | BYD Atto3 | PulsarPlus EV +Balancer | WP7.7K Z | 2 MT Venus 5.12KWh V155 - CT003 V117 - BMS 216 - Modi: AI | 2 Mitsubitshi HEAC | HA DS224+
@superduper1969 A/B omwisselen (Oranje / Oranje-wit) heeft als gevolg dat ik een error krijg in HA bij de config (invalid flow). Ik zie dan ook geen verzonden pakketjes meer in de elfin interface. Lijkt me dus dat die bekabeling goed zit. Is ook identiek aan het voorbeeld in de eerste post voor de V3.
/f/image/CU4uSFVxHQiorTqiKGaipQC5.png?f=fotoalbum_large) 
                                                [ Voor 55% gewijzigd door Rik Mertens op 21-09-2025 19:44 ]
Welke methode ben je aan het volgen? Want die van mij (optie C) kan geen Invalid Flow geven zover ik weet?Rik Mertens schreef op zondag 21 september 2025 @ 19:32:
Daar lijk ik de API inderdaad te kunnen openzetten, al zie ik nog niet dadelijk wat me dat oplevert?
@superduper1969 A/B omwisselen (Oranje / Oranje-wit) heeft als gevolg dat ik een error krijg in HA bij de config (invalid flow). Ik zie dan ook geen verzonden pakketjes meer in de elfin interface. Lijkt me dus dat die bekabeling goed zit. Is ook identiek aan het voorbeeld in de eerste post voor de V3.
[Afbeelding]
Optie A: https://github.com/ViperRNMC/marstek_venus_modbus
Optie B: https://github.com/WargamingPlayer/HA-Marstek-Venus-E-Modbus
Optie C: Oude originele code https://github.com/Superduper1969/MarstekVenus-ElfinEW11
MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
He who controls the past, commands the future. He who commands the future, conquers the past.
De SoC haal ik for the time being met wat vertraging uit de cloud (https://github.com/DoctaShizzle/marstek_cloud). Werkt prima voor wat ik het nodig heb.
Voor de rest lijkt het me even de kat uit de boom kijken met de firmwareupdates en lokale API.
Is dit niet hetzelfde qua belasting van je electriciteitsnetwerk, of het nu laden of ontladen is?
Moet je eens zoeken hier, staat in hoofd topic ergens duidelijk uitgelegd met foto's.Vega82 schreef op maandag 22 september 2025 @ 10:35:
Ik ben een leek qua kennis electriciteit maar begrijp niet goed waarom het ontladen gelimiteerd is op 800W en het opladen standaard tot 2500W kan gaan.
Is dit niet hetzelfde qua belasting van je electriciteitsnetwerk, of het nu laden of ontladen is?
Kort door de bocht kan een (eventueel slecht werkend) apparaat meer stroom vragen dan wat de kabel is afgezekerd doordat de Marstek op hetzelfde circuit kan bijleveren zonder dat de zekering springt.
Neen, dat is niet hetzelfde, de stroom voor het laden gaat steeds door de zekering van de groep en zo wordt voorkomen dat stukken van de leiding overbelast geraken. Als je daarentegen ontlaadt kunnen bepaalde stukken van de leidiing overbelast geraken als er ook nog verbruikers op diezelfde groep zitten. Dit is al herhaaldelijk aan bod gekomen in verschillende Marstek-topics. De tekening uit deze post maken het meer aanschouwelijk waarom je 2500W ontladen best alleen doet als je batterij op een eigen afgezekerde groep zit:Vega82 schreef op maandag 22 september 2025 @ 10:35:
Ik ben een leek qua kennis electriciteit maar begrijp niet goed waarom het ontladen gelimiteerd is op 800W en het opladen standaard tot 2500W kan gaan.
Is dit niet hetzelfde qua belasting van je electriciteitsnetwerk, of het nu laden of ontladen is?
3x Marstek Venus E (1xV1 en 2xV2 op v153 bms 215), Marstek CT002 V120, 3x LilyGo T-CAN RS485, Home Assistant
Hi Superduper,superduper1969 schreef op zaterdag 11 januari 2025 @ 18:06:
[...]
7. Kopieer vervang de volledige inhoud voor de inhoud uit Github en plaats daarna het deel van de api en ota encryption key weer terug.
Github: https://github.com/Superduper1969/MarstekVenus-LilygoRS485
[...]
In het topic startbericht staat niets over het koppelen van meerdere batterijen (aan esphome), maar ik begrijp uit je reactie op mijn gerapporteerde issue op github dat je daarvoor al wel yaml files klaar hebt staan:
lilygo-rs485.yaml is voor batterij 1, lilygo-rs485-2.yaml voor batterij 2, enz.
Wat ik me ook meteen afvraag is het volgende: ga je dan dus uit van een LillyGo bordje per batterij? Met RS485 is het namelijk mogelijk om meerdere batterijen aan één bus/LillyGo bordje te hangen. Echter moet het dan wel mogelijk zijn om per batterij een slave adres in te stellen. Ik heb (nog) niet uitgezocht of dat mogelijk is. Ik kan me overigens ook goed voorstellen dat het voor de mensen die minder thuis zijn in RS485 het allermakkelijkst is om "gewoon" een LillyGo aan iedere batterij te plakken
 
                    Ja het is mogelijk (bij de V2 en eerder in ieder geval) maar zoals je zelf ook al zegt is het lastig om daar iets kant en klaars voor aan te bieden. Je zal eerst elke batterij afzonderlijk moeten verbinden en configureren en vervolgens dus een configuratie maken voor alle batterijen. Dit heeft niemand kant en klaar gedaan, maar het is mogelijk. Deze vraag komt hier geregeld terug. Die bestanden in de repo zorgen er slechts voor dat de naam anders is zodat er geen conflicten plaatsvinden binnen HA, maar is dus bedoeld met meerdere LilyGo's.BB_Elektro schreef op maandag 22 september 2025 @ 13:18:
[...]
Hi Superduper,
In het topic startbericht staat niets over het koppelen van meerdere batterijen (aan esphome), maar ik begrijp uit je reactie op mijn gerapporteerde issue op github dat je daarvoor al wel yaml files klaar hebt staan:
lilygo-rs485.yaml is voor batterij 1, lilygo-rs485-2.yaml voor batterij 2, enz.
Wat ik me ook meteen afvraag is het volgende: ga je dan dus uit van een LillyGo bordje per batterij? Met RS485 is het namelijk mogelijk om meerdere batterijen aan één bus/LillyGo bordje te hangen. Echter moet het dan wel mogelijk zijn om per batterij een slave adres in te stellen. Ik heb (nog) niet uitgezocht of dat mogelijk is. Ik kan me overigens ook goed voorstellen dat het voor de mensen die minder thuis zijn in RS485 het allermakkelijkst is om "gewoon" een LillyGo aan iedere batterij te plakken
Omdat je op een gedeelde groep maximaal 800W volgens de Nederlandse regelgeving mag terug leveren. Wanneer kende Marstek op een eigen groep hebt staan, dan mag ie op 2500 gezet worden. Conform regelgeving mag je op die groep ook niks anders aansluiten of kunnen aansluiten. Dus je mag ook geen twee wandcontactdozen hebben bij 2500W.Vega82 schreef op maandag 22 september 2025 @ 10:35:
Ik ben een leek qua kennis electriciteit maar begrijp niet goed waarom het ontladen gelimiteerd is op 800W en het opladen standaard tot 2500W kan gaan.
Is dit niet hetzelfde qua belasting van je electriciteitsnetwerk, of het nu laden of ontladen is?
De reden is eigenlijk wel slim. Stel je neemt 3 keer 2500W af. Dan klapt je zekering (automaat) er uit tussen de 3800 en 4000W (ongeveer).
Bij terugleveren kan er echter op 1 groep meer vermogen lopen welke verbruikt wordt binnen de groep en nooit over de zekering gaat.
Voorbeeld: 2 x Marstek, 1 keer zonnepanelen 3000W. Wasmachine en wasdroger beide 2200.
Marstek levert 2500W * 2, panelen 3000W dat is 8000W. Wasmachine en droger vragen samen 4400W. Op de bedrading staat dan theoretisch 8000W en op de zekering staat 8000-4400 =3600W. Ondertussen verhitten je draden in de muur, gaan uiteindelijk branden en je zekering, die doet niks. Huis brand af, maar zekering is er niet uit gegaan.
☀️ 8 x 430wp op zuid | ☀️ Huawei SUN2000-3KTL-L1 | 🔋 2 x Marstek Venus-E BMS: 155, EMS: 216 | 📱 Home Assistant | 🚗 Kia EV6-LR 2024 |🔌 Delta 8/8
Ik heb CT meter werkend in HA verder.
Beschik over een CT003 en 2 venus E v3 batterijen
[ Voor 26% gewijzigd door timvanloon op 22-09-2025 15:17 ]
2 x Marstek V3.0 v242 LAN - CT003 v118 - 14 st zonnepaneel Jinko 425 N-Type / 5950Wp / 6150 KWh / 3 x 25A / Shell Recharge laadpaal / Tesla model Y bj 2024
Tot op heden ben je beter af met modbus of mqtt. De API mogelijkheden zijn nog zeer beperkt. Misschien komt daar binnenkort nog verandering in. Hier programmeer ik alles via de modbus integratie. Werkt prima.timvanloon schreef op maandag 22 september 2025 @ 15:17:
ik heb gevraagd of de API aan gezet kon worden en dat is nu bevestigd dat dit gedaan is maar kun je hier al wat mee in HA verder?
Ik heb CT meter werkend in HA verder.
Beschik over een CT003 en 2 venus E v3 batterijen
BE MTVenus V2 V155 BMS 216 APP V1.6.50 HW-P1 M5stack Atom lite Modbus HA integration ZP 3,28kWp Goodwe 3kW
Meerdere batterijen (V1/V2):
Technisch is het mogelijk om het modbus adres aan te passen, dit is niet uitgeschreven omdat het een nogal omslachtig proces is waar bij het lastig is om een procedure of configuratie te maken voor alle varianten.
Dus er is één Lilygo, Elfin of ander appraat nodig per Batterij, het meeste is toch te bestellen onder €25.
V3:
Alles is geschreven voor de V1/V2, de V3 heeft andere registers dus daar kunnen andere dingen gebeuren.
Voor de V3 ga ik er vanuit dat er binnenkort een integratie komt door middel van de "Open-API" waar Marstek reclame mee maakt.
Dat is ook de 2e reden waarom er (nog) geen Modbus yaml specifiek voor de V3 wordt gemaakt.
De "Open-Api" zal besproken worden in een ander Topic (die er nu nog niet is) omdat dit Topic over Modbus gaat.
Ik raad iedereen met een V3 aan om af te wachten óf er tijd in te steken en zélf het wiel zelf uit te vinden en deze kennis op Tweakers te delen.
[ Voor 11% gewijzigd door superduper1969 op 22-09-2025 15:33 ]
MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
het is wel een discutabel dingetje hoor. Sprak toevallig installateur in mijn bekendenkring over mijn thuisaccu en die was al verbaasd dat 800W wel mag en in allerlei producten nu als "veilig" staat.Marco_64 schreef op maandag 22 september 2025 @ 11:03:
[...]
Neen, dat is niet hetzelfde, de stroom voor het laden gaat steeds door de zekering van de groep en zo wordt voorkomen dat stukken van de leiding overbelast geraken. Als je daarentegen ontlaadt kunnen bepaalde stukken van de leidiing overbelast geraken als er ook nog verbruikers op diezelfde groep zitten. Dit is al herhaaldelijk aan bod gekomen in verschillende Marstek-topics. De tekening uit deze post maken het meer aanschouwelijk waarom je 2500W ontladen best alleen doet als je batterij op een eigen afgezekerde groep zit:
Zijn argumentatie: Als je bestaande apparaten op 16A verbruiken, en die batterij staat 800W te blazen en je sluit dan een nieuwe appraat aan, dan kan er al 19,5A over die groep lopen zonder dat die zekering/stop omslaat en is volgens hem al een situatie die onveilig is, want daar is die bekabeling niet altijd op berekend. Bij 2500W kan dat oplopen naar bijna 27A. Dat is natuurlijk nog onveiliger, maar wil niet zeggen dat die 800W dan wel oke is...
Volgens hem zit het risico vooral bij oude huizen waar de bekabeling soms al wat warmer te worden als je er enkel een condensdroger op zet en is 16A eigenlijk al op het randje. Als je er dan 19,5A over kunt blazen voordat de stop omslaat lijkt mij dat ook niet zonder risico...
(ofwel: die van mij zit inmiddels op zijn eigen groep om dit soort risico's te voorkomen)
Andere installateur zoeken.Kammika schreef op maandag 22 september 2025 @ 16:17:
[...]
het is wel een discutabel dingetje hoor. Sprak toevallig installateur in mijn bekendenkring over mijn thuisaccu en die was al verbaasd dat 800W wel mag en in allerlei producten nu als "veilig" staat.
Zijn argumentatie: Als je bestaande apparaten op 16A verbruiken, en die batterij staat 800W te blazen en je sluit dan een nieuwe appraat aan, dan kan er al 19,5A over die groep lopen zonder dat die zekering/stop omslaat en is volgens hem al een situatie die onveilig is, want daar is die bekabeling niet altijd op berekend. Bij 2500W kan dat oplopen naar bijna 27A. Dat is natuurlijk nog onveiliger, maar wil niet zeggen dat die 800W dan wel oke is...
Volgens hem zit het risico vooral bij oude huizen waar de bekabeling soms al wat warmer te worden als je er enkel een condensdroger op zet en is 16A eigenlijk al op het randje. Als je er dan 19,5A over kunt blazen voordat de stop omslaat lijkt mij dat ook niet zonder risico...
(ofwel: die van mij zit inmiddels op zijn eigen groep om dit soort risico's te voorkomen)
Stel op je groep heb je 10 apparaten welke 16A gebruiken (we pakken het even hoog). Je Marstek levert 11A (2500W). Dan is de berekening heel erg eenvoudig.
Ten eerste zal al het vermogen van je accu naar alle verbruikers in de groep gaan. Dat is dus 11A (2500W). Daarnaast zal er natuurlijk 1300W missen, dit komt over je zekering. 5,652 A gaat er over je zekering heen. Niks aan de hand dus.
Echter nu de volgende situatie. Je hebt een Marstek die levert 2500W (11A). Je hebt je groep in gebruik met apparaten welke gezamenlijk 6300W trekken. Dan heb je wel een probleem. Dan kan op bepaalde punten (afhankelijk waar de MT is aangesloten) er 11+16=27A lopen. En dat is voor 2.5mm2 een beetje te veel.
Waarom is 800W wel een veilige aanname?
800W is 5,5A, 16A + 5,5A is onder de 22A. Dit kan je veilig op 2,5mm2 hebben.
Veel installateurs zullen zeggen NEN1010 dat mag niet. Maar wat niet mag is niet altijd wat niet kan. Er zijn landen om ons heen waar 16A gewoon over 1,5mm2 gedaan wordt. Dus 21,5A over 2,5 is geen issue. Sterker nog bij voltage verhoging bij gelijk vermogen zal de stroom dalen. Dus op het moment dat het voltage in de groep naar 250 gaat (wat zo maar kan) is de MT opeens maar 5A bij 800W en de overige opeens maar 14,72A waardoorheen dan opeens onder de 20A zit.
Dus daarom zullen ze 800W als veilig zien.
En daarom nooit een MT op 2500W afgifte zetten wanneer er iets anders op de zelfde groep zit.
☀️ 8 x 430wp op zuid | ☀️ Huawei SUN2000-3KTL-L1 | 🔋 2 x Marstek Venus-E BMS: 155, EMS: 216 | 📱 Home Assistant | 🚗 Kia EV6-LR 2024 |🔌 Delta 8/8
Nou ja dan zeg je ongeveer hetzelfde als degene die ik sprak (die overigens installateur van beroep is, maar niet mijn installateur). Want ook hij gaf aan dat het met een moderne woning wach wel los zou lopen met die 19a (800w is geen 5,5A. Dat de in je antwoord klopt niet) omdat die kabels vaak dik genoeg zijn dat ze ook wat meer aan kunnen, maar dat hij oudere woningen kent waar de bekabeling minder dik is en hij 16a al op het randje vindt…WargamingPlayer schreef op maandag 22 september 2025 @ 17:15:
[...]
Andere installateur zoeken.
Stel op je groep heb je 10 apparaten welke 16A gebruiken (we pakken het even hoog). Je Marstek levert 11A (2500W). Dan is de berekening heel erg eenvoudig.
Ten eerste zal al het vermogen van je accu naar alle verbruikers in de groep gaan. Dat is dus 11A (2500W). Daarnaast zal er natuurlijk 1300W missen, dit komt over je zekering. 5,652 A gaat er over je zekering heen. Niks aan de hand dus.
Echter nu de volgende situatie. Je hebt een Marstek die levert 2500W (11A). Je hebt je groep in gebruik met apparaten welke gezamenlijk 6300W trekken. Dan heb je wel een probleem. Dan kan op bepaalde punten (afhankelijk waar de MT is aangesloten) er 11+16=27A lopen. En dat is voor 2.5mm2 een beetje te veel.
Waarom is 800W wel een veilige aanname?
800W is 5,5A, 16A + 5,5A is onder de 22A. Dit kan je veilig op 2,5mm2 hebben.
Veel installateurs zullen zeggen NEN1010 dat mag niet. Maar wat niet mag is niet altijd wat niet kan. Er zijn landen om ons heen waar 16A gewoon over 1,5mm2 gedaan wordt. Dus 21,5A over 2,5 is geen issue. Sterker nog bij voltage verhoging bij gelijk vermogen zal de stroom dalen. Dus op het moment dat het voltage in de groep naar 250 gaat (wat zo maar kan) is de MT opeens maar 5A bij 800W en de overige opeens maar 14,72A waardoorheen dan opeens onder de 20A zit.
Dus daarom zullen ze 800W als veilig zien.
En daarom nooit een MT op 2500W afgifte zetten wanneer er iets anders op de zelfde groep zit.
Als ik je posts goed begrijp kun je met v139 je venus v3 dus ook via modbus aansturen? Of werkt enkel het uitlezen?kuhlivisj schreef op maandag 22 september 2025 @ 08:43:
Waarschijnlijk ligt het aan de firmware van de Marstek. Hier werkte het op v122 ook niet. Na een update naar v139 werkte de modus ineens.
Nav eerdere topics heb ik vandaag alles omgezet van Lilygo setup naar modbus-bridge modus. Vervolgens heb ik jouw prachtige HACS integratie gebruikt om alles in home assistent weer goed werkend te krijgen.[RNMC] Viper schreef op zondag 21 september 2025 @ 11:32:
[...]
Nee, deze logica zit er niet in. Mijn integratie maakt het alleen mogelijk om alle bekende registers uit te lezen of te schrijven.
Nom doe ik zelf via de standaard aansturing in de batterij, dat werkt op dit moment voor mij voldoende. Ben vooral zelf benieuwd hoe evcc dit in de toekomst gaat integreren met dynamische tarieven.
Het doel was om vervolgens EVCC aan de praat te krijgen zonder drops van power en charge. Helaas heb ik. het nog steeds. Ook als ik gebruik maak van de modbusproxy in EVCC.
Heb jij misschien nog tips? Ik ben de draad inmiddels kwijt.
Niet alle registers van de v2 werken op de v3. Ik heb hem wel een keer via modbus op laden kunnen zetten en ook het laadvermogen in kunnen stellen.savale schreef op maandag 22 september 2025 @ 18:28:
[...]
Als ik je posts goed begrijp kun je met v139 je venus v3 dus ook via modbus aansturen? Of werkt enkel het uitlezen?
je zou nog kunnen spelen met:
| 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 | # Configure UART
uart:
  - id: mod_bus
    rx_pin: GPIO21
    tx_pin: GPIO22
    baud_rate: 115200
    data_bits: 8
    stop_bits: 1
    parity: NONE
    rx_buffer_size: 768         # min. 256 recommended; increase for very long RTU responses
modbus_bridge:
  id: mb_bridge
  uart_id: mod_bus
  tcp_port: 502               # TCP port
  tcp_poll_interval: 100       # ms between TCP polls
  tcp_client_timeout: 120000   # ms inactivity until TCP client is disconnected
  tcp_allowed_clients: 2      # clamped to minimum 1, use with care as it increases memory usage
  rtu_response_timeout: 60000  # ms, clamped internally to minimum of 10 ms) | 
Maar ik vrees dat het niet helemaal te voorkomen is. (of nog met andere esphome versies proberen)
Yep, zelfs nog minder.Kammika schreef op maandag 22 september 2025 @ 18:20:
[...]
Nou ja dan zeg je ongeveer hetzelfde als degene die ik sprak (die overigens installateur van beroep is, maar niet mijn installateur). Want ook hij gaf aan dat het met een moderne woning wach wel los zou lopen met die 19a (800w is geen 5,5A. Dat de in je antwoord klopt niet) omdat die kabels vaak dik genoeg zijn dat ze ook wat meer aan kunnen, maar dat hij oudere woningen kent waar de bekabeling minder dik is en hij 16a al op het randje vindt…
☀️ 8 x 430wp op zuid | ☀️ Huawei SUN2000-3KTL-L1 | 🔋 2 x Marstek Venus-E BMS: 155, EMS: 216 | 📱 Home Assistant | 🚗 Kia EV6-LR 2024 |🔌 Delta 8/8
Als ik dit zo lees denk ik dat het eerder aan de verbinding lig, dan de manier waarop de modbus wordt aangestuurd. Moeilijk te vergelijken, maar hier een ew11 die ik zowel Home Assistant als evcc uitlees met een proxy ertussen, geen drops.pj schreef op maandag 22 september 2025 @ 20:18:
[...]
Nav eerdere topics heb ik vandaag alles omgezet van Lilygo setup naar modbus-bridge modus. Vervolgens heb ik jouw prachtige HACS integratie gebruikt om alles in home assistent weer goed werkend te krijgen.
Het doel was om vervolgens EVCC aan de praat te krijgen zonder drops van power en charge. Helaas heb ik. het nog steeds. Ook als ik gebruik maak van de modbusproxy in EVCC.
Heb jij misschien nog tips? Ik ben de draad inmiddels kwijt.
[ Voor 7% gewijzigd door [RNMC] Viper op 22-09-2025 23:07 ]
He who controls the past, commands the future. He who commands the future, conquers the past.
Als de lijst van register voor v3 redelijk bekend is, kan ik redelijk eenvoudig deze aan mijn integratie toevoegen. Als iemand dit dan kan testen?superduper1969 schreef op maandag 22 september 2025 @ 15:24:
Startpost aangepast voor meerdere batterijen en de V3!
Meerdere batterijen (V1/V2):
Technisch is het mogelijk om het modbus adres aan te passen, dit is niet uitgeschreven omdat het een nogal omslachtig proces is waar bij het lastig is om een procedure of configuratie te maken voor alle varianten.
Dus er is één Lilygo, Elfin of ander appraat nodig per Batterij, het meeste is toch te bestellen onder €25.
V3:
Alles is geschreven voor de V1/V2, de V3 heeft andere registers dus daar kunnen andere dingen gebeuren.
Voor de V3 ga ik er vanuit dat er binnenkort een integratie komt door middel van de "Open-API" waar Marstek reclame mee maakt.
Dat is ook de 2e reden waarom er (nog) geen Modbus yaml specifiek voor de V3 wordt gemaakt.
De "Open-Api" zal besproken worden in een ander Topic (die er nu nog niet is) omdat dit Topic over Modbus gaat.
Ik raad iedereen met een V3 aan om af te wachten óf er tijd in te steken en zélf het wiel zelf uit te vinden en deze kennis op Tweakers te delen.
He who controls the past, commands the future. He who commands the future, conquers the past.
Ik heb recent nog een aanpassing gedaan van arduino naar esp-idf:pj schreef op maandag 22 september 2025 @ 20:18:
[...]
Nav eerdere topics heb ik vandaag alles omgezet van Lilygo setup naar modbus-bridge modus. Vervolgens heb ik jouw prachtige HACS integratie gebruikt om alles in home assistent weer goed werkend te krijgen.
Het doel was om vervolgens EVCC aan de praat te krijgen zonder drops van power en charge. Helaas heb ik. het nog steeds. Ook als ik gebruik maak van de modbusproxy in EVCC.
Heb jij misschien nog tips? Ik ben de draad inmiddels kwijt.
| 1
2
3
4
 | esp32:
  board: esp32dev
  framework:
    type: esp-idf | 
Dat zou een snelheidsverbetering opleveren volgens: https://esphome.io/guides/esp32_arduino_to_idf/
MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
Heb je nog andere aanpassigen moeten doen behalve het framework veranderen?superduper1969 schreef op dinsdag 23 september 2025 @ 10:32:
[...]
Ik heb recent nog een aanpassing gedaan van arduino naar esp-idf:
code:
esp32: board: esp32dev framework: type: esp-idf
Dat zou een snelheidsverbetering opleveren volgens: https://esphome.io/guides/esp32_arduino_to_idf/
3x Marstek Venus E (1xV1 en 2xV2 op v153 bms 215), Marstek CT002 V120, 3x LilyGo T-CAN RS485, Home Assistant
Nee, daarna opnieuw gecompileerd en het werkte.Marco_64 schreef op dinsdag 23 september 2025 @ 11:05:
[...]
Heb je nog andere aanpassigen moeten doen behalve het framework veranderen?
Ik merkte zelf geen snelheidsverschil maar dat in ook lastig in de standaard situatie.
MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
Hoi,superduper1969 schreef op zondag 21 september 2025 @ 11:48:
[...]
Ik denk dat de handigste optie is om even te wachten totdat de V3 firmware en Ontwikkelingen af te wachten, ik vermoed dat binnen 1 maand alles wel rond is, en dan kun je alles zonder extra hardware doen met de Interne API.
Wil je nu al aan de slag dan moet je 2xT-POE-Pro kopen. Technisch is het mogelijk om er 2 op 1 te zetten maar dit is nogal een gedoe die je niet op je hals wil halen voor die paar euro extra.
Ik heb de 2e en 3e even aangemaakt: https://github.com/Superduper1969/MarstekVenus-LilygoRS485
[Afbeelding]
Bedankt iedereen om deze fantastische topic te schrijven.
Zelf bezitter van twee V2's en ga hier zeker mee aan de slag!
Een 40 jaar geleden afgestudeerd in elektronica en vooral actief geweest in de vermogen en automatisatiewereld, aangevuld met 20 jaar onderwijs.
Gezien mijn loopbaan en mijn nogal belegen leeftijd heb ik het hele netwerkgebeuren eigenlijk aan mijn neus zien voorbij gaan alsook het verhaal minicontrollers en programmeertalen als Pi maar als ik ze met behulp van jullie hints even bestudeer dan houdt het verhaal wel steek maar ik zie me het morgen daarom niet zelf schrijven.
Met behulp van jullie handleiding en heel wat uurtjes studie zie ik mij er wel doorheen te trekken om ook mijn systeem van een EMS te voorzien, dat is mijn kernobjectief dus eigenlijk wel gerust in het al dan niet doen branden van mijn lampen via een of andere 'smarte" oplossing, ik ben zelf nog smart genoeg om mijn schakelaar te bedienen als ik vind dat het donker is.
Wel een vraag over de opzet van het bussysteem (vergeef me mocht het een domme vraag zijn)
Waarom sturen jullie het RS485 signaal niet onveranderd door via wifi naar jullie Home Assistant server en gaan jullie het DAAR niet decoderen?
Heeft dat eerder te maken met de gegevensoverdracht (ik zie er op het eerste gezicht geen graten in om dat verstuurd te krijgen) dan wel met de beperking in HA gebonden te zijn aan het platform zelf en het moeilijk kunnen switchen tussen HAO en een onderliggend krachtig rekenapparaat ?
Bij mij draait HA op een goedkope maar goed (over) gedimensioneerde pseudo industriële mini i3, toch een iets robuuster ding dan pakweg de eigen HA toestellen of een Raspberry Pi (en zelfs goedkoper te vinden bij bepaalde Chinese vrienden) of is het( naar mijn gevoel toch het te goed afgesloten eigen HAO) dat roet in het eten komt gooien.
In mijn geval rekenkracht in overschot op HA-server of zie ik (weer) iets over het hoofd?
[ Voor 0% gewijzigd door MarcVS op 23-09-2025 18:22 . Reden: zinsbouw ]
Niks mis mee toch bij mij draait HA op een i7 voorzien van free ESX. En dat in een lenovo Tiny M900.MarcVS schreef op dinsdag 23 september 2025 @ 18:18:
[...]
Hoi,
Bedankt iedereen om deze fantastische topic te schrijven.
Zelf bezitter van twee V2's en ga hier zeker mee aan de slag!
Een 40 jaar geleden afgestudeerd in elektronica en vooral actief geweest in de vermogen en automatisatiewereld, aangevuld met 20 jaar onderwijs.
Gezien mijn loopbaan en mijn nogal belegen leeftijd heb ik het hele netwerkgebeuren eigenlijk aan mijn neus zien voorbij gaan alsook het verhaal minicontrollers en programmeertalen als Pi maar als ik ze met behulp van jullie hints even bestudeer dan houdt het verhaal wel steek maar ik zie me het morgen daarom niet zelf schrijven.
Met behulp van jullie handleiding en heel wat uurtjes studie zie ik mij er wel doorheen te trekken om ook mijn systeem van een EMS te voorzien, dat is mijn kernobjectief dus eigenlijk wel gerust in het al dan niet doen branden van mijn lampen via een of andere 'smarte" oplossing, ik ben zelf nog smart genoeg om mijn schakelaar te bedienen als ik vind dat het donker is.
Wel een vraag over de opzet van het bussysteem (vergeef me mocht het een domme vraag zijn)
Waarom sturen jullie het RS485 signaal niet onveranderd door via wifi naar jullie Home Assistant server en gaan jullie het DAAR niet decoderen?
Heeft dat eerder te maken met de gegevensoverdracht (ik zie er op het eerste gezicht geen graten in om dat verstuurd te krijgen) dan wel met de beperking in HA gebonden te zijn aan het platform zelf en het moeilijk kunnen switchen tussen HAO en een onderliggend krachtig rekenapparaat ?
Bij mij draait HA op een goedkope maar goed (over) gedimensioneerde i3, toch een iets robuuster ding dan pakweg de eigen HA toestellen of een Raspberry Pi (en zelfs goedkoper te vinden bij bepaalde Chinese vrienden) of is het( naar mijn gevoel toch het te goed afgesloten eigen HAO) dat roet in het eten komt gooien.
In mijn geval rekenkracht in overschot op HA-server of zie ik (weer) iets over het hoofd?
☀️ 8 x 430wp op zuid | ☀️ Huawei SUN2000-3KTL-L1 | 🔋 2 x Marstek Venus-E BMS: 155, EMS: 216 | 📱 Home Assistant | 🚗 Kia EV6-LR 2024 |🔌 Delta 8/8
Idd, alleen jammer dat we het niet standaard ten volle kunnen benutten door even een sprongetje te maken naar onze rekencapaciteit, gemiste kans van HA maar ik begrijp wel dat het zo niet "universeel" blijft.WargamingPlayer schreef op dinsdag 23 september 2025 @ 18:22:
[...]
Niks mis mee toch bij mij draait HA op een i7 voorzien van free ESX. En dat in een lenovo Tiny M900.
Veel te veel goedkoop geheugen en losstaande rekentools tegenwoordig zei de oude man uit het Kbyte tijdperk
Goede vraag om te stellen!MarcVS schreef op dinsdag 23 september 2025 @ 18:18:
[...]
Hoi,
Bedankt iedereen om deze fantastische topic te schrijven.
Zelf bezitter van twee V2's en ga hier zeker mee aan de slag!
Een 40 jaar geleden afgestudeerd in elektronica en vooral actief geweest in de vermogen en automatisatiewereld, aangevuld met 20 jaar onderwijs.
Gezien mijn loopbaan en mijn nogal belegen leeftijd heb ik het hele netwerkgebeuren eigenlijk aan mijn neus zien voorbij gaan alsook het verhaal minicontrollers en programmeertalen als Pi maar als ik ze met behulp van jullie hints even bestudeer dan houdt het verhaal wel steek maar ik zie me het morgen daarom niet zelf schrijven.
Met behulp van jullie handleiding en heel wat uurtjes studie zie ik mij er wel doorheen te trekken om ook mijn systeem van een EMS te voorzien, dat is mijn kernobjectief dus eigenlijk wel gerust in het al dan niet doen branden van mijn lampen via een of andere 'smarte" oplossing, ik ben zelf nog smart genoeg om mijn schakelaar te bedienen als ik vind dat het donker is.
Wel een vraag over de opzet van het bussysteem (vergeef me mocht het een domme vraag zijn)
Waarom sturen jullie het RS485 signaal niet onveranderd door via wifi naar jullie Home Assistant server en gaan jullie het DAAR niet decoderen?
Heeft dat eerder te maken met de gegevensoverdracht (ik zie er op het eerste gezicht geen graten in om dat verstuurd te krijgen) dan wel met de beperking in HA gebonden te zijn aan het platform zelf en het moeilijk kunnen switchen tussen HAO en een onderliggend krachtig rekenapparaat ?
Bij mij draait HA op een goedkope maar goed (over) gedimensioneerde pseudo industriële mini i3, toch een iets robuuster ding dan pakweg de eigen HA toestellen of een Raspberry Pi (en zelfs goedkoper te vinden bij bepaalde Chinese vrienden) of is het( naar mijn gevoel toch het te goed afgesloten eigen HAO) dat roet in het eten komt gooien.
In mijn geval rekenkracht in overschot op HA-server of zie ik (weer) iets over het hoofd?
Ik zelf heb meer vertrouwen in ESPHome dan in een Modbus bridge. Je kunt veel nauwkeuriger sturen aangezien de aanvragen op het apparaat worden gedaan en het apparaat dus de timings e.d. kan bepalen. Ik lees zonder problemen elke 5 seconde 350 registers op de Modbus bus uit via ESPHome. Vervolgens wordt dit in batches verstuurd naar HA. Ik heb het niet getest, maar denk dat 350 losse netwerk pakketten naar een bridge sturen, stukken minder efficiënt is. Daarbij weet het ESPHome apparaat wat er uitgevraagd gaat worden en kan nabije registers samenvoegen (dit kan een slimme Modbus integratie echter ook voor je doen). Ook is de communicatie tussen ESPHome en HA via de API goed geoptimaliseerd (zeggen ze).
Een paar andere kleine zaken: 1 ESPHome apparaat met 1 configuratie kan je op meerdere apparaten gebruiken als je dat zou willen zonder de configuratie te dupliceren. Ook heb je, zelfs als HA down is, nog een werkende weergave van de gegevens.
Een nadeel is wel, dat als je wat wilt wijzigen, je een nieuwe configuratie moet maken en uploaden. Dit kan allemaal draadloos en is dus geen groot probleem, maar even een nieuw register testen maakt het wel lastig. Daarom heb ik tijdens het testen mijn laptop inderdaad ingezet als Modbus bridge naast de batterij zodat het schrijven van de configuratie makkelijker ging.
Het verschil is klein en als je eenmaal aan iets begonnen bent en het goed werkt, zou ik niet wisselen. Maar ik denk dat er bij grote hoeveelheden data wel een voordeel is om het via ESPHome te doen.
He who controls the past, commands the future. He who commands the future, conquers the past.
heb deze in de packages map gezet maar nu krijg ik deze melding, weet iemand wat ner loos kan zijn.
Configuratiewaarschuwingen
Setup of package 'marstek_venus_battery_control' failed: integration 'utility_meter' has duplicate key 'name'
Aangepast op Github, de namen waren niet uniek, melding krijg je pas bij 2 of 3 batterijen.Weldie schreef op dinsdag 23 september 2025 @ 20:26:
vraagje over de marstek_venus_battery_control.yaml met de elfin EW11
heb deze in de packages map gezet maar nu krijg ik deze melding, weet iemand wat ner loos kan zijn.
Configuratiewaarschuwingen
Setup of package 'marstek_venus_battery_control' failed: integration 'utility_meter' has duplicate key 'name'
marstek_venus_battery2_control.yaml
Oud: daily_discharge:
Nieuw: daily_discharge2:
marstek_venus_battery3_control.yaml
Oud: daily_discharge:
Nieuw: daily_discharge3
Zelfde voor Daily Charge.
[ Voor 7% gewijzigd door superduper1969 op 23-09-2025 21:41 ]
MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
Heb het nog eens opnieuw op een Atom S3 lite gezet, nadat ik ontdekte dat deze standaard op 160 MHz draait ipv de opgegeven 240 MHzpj schreef op maandag 22 september 2025 @ 20:18:
[...]
Nav eerdere topics heb ik vandaag alles omgezet van Lilygo setup naar modbus-bridge modus. Vervolgens heb ik jouw prachtige HACS integratie gebruikt om alles in home assistent weer goed werkend te krijgen.
Het doel was om vervolgens EVCC aan de praat te krijgen zonder drops van power en charge. Helaas heb ik. het nog steeds. Ook als ik gebruik maak van de modbusproxy in EVCC.
Heb jij misschien nog tips? Ik ben de draad inmiddels kwijt.
De lilygo kan volgens de gegevens ook op 240 MHz draaien
Dit draait nu stabiel zonder dropouts en iedere10 sec een update (voorheen rammelden de waardes door het log scherm net of er een vertraging of opstopping in zat)
https://github.com/fonske..._bridge_only.yaml#L18-L20
Met name:
esp-idf en cpu frequentie op 240 MHz zijn denk ik de grote verbeteringen.
Zet het eens om naar lilygo? (=esp32 en geen ESP32S3 by the way)
Ik gebruik de laatste nieuwe versie van esphome, laatste evcc addon.
Huidige freq zie je hiermee
| 1
2
3
4
5
6
7
8
9
10
11
12
13
14
 | debug: update_interval: 60s ## Textsensors diagnostics text_sensor: # ## DEBUG - platform: debug # reset_reason: # name: "Reset Reason" # entity_category: diagnostic device: name: "Device Info" entity_category: diagnostic ## END DEBUG | 
| :strip_exif()/f/image/8E6eHBBJQJzXMaFyQnZ095J1.jpg?f=fotoalbum_tile) | 
https://github.com/fonske...3_lite_rs485.yaml#L15-L16
[ Voor 28% gewijzigd door AUijtdehaag op 24-09-2025 12:58 ]
Ik zie dat je de verkeerde gebruikt hebt. Die jij gebruikt hebt worden niet meer onderhouden en daar zit inderdaad dat issue in:Weldie schreef op dinsdag 23 september 2025 @ 20:26:
vraagje over de marstek_venus_battery_control.yaml met de elfin EW11
heb deze in de packages map gezet maar nu krijg ik deze melding, weet iemand wat ner loos kan zijn.
Configuratiewaarschuwingen
Setup of package 'marstek_venus_battery_control' failed: integration 'utility_meter' has duplicate key 'name'
Je kan het beste deze gebruiken:
https://github.com/WargamingPlayer/HA-Marstek-Venus-E-Modbus
Dit omdat die van @superduper1969 registers mist en al even niet meer is onderhouden.
[ Voor 6% gewijzigd door WargamingPlayer op 24-09-2025 17:05 ]
☀️ 8 x 430wp op zuid | ☀️ Huawei SUN2000-3KTL-L1 | 🔋 2 x Marstek Venus-E BMS: 155, EMS: 216 | 📱 Home Assistant | 🚗 Kia EV6-LR 2024 |🔌 Delta 8/8
Als je de Elfin EW11 gebruikt zou ik de @[RNMC] Viper HACS integratie gebruiken. Ik gebruik deze ook met 3 x Marstek E v2 en deze werkt als een tierelier. En als er updates zijn krijg je netjes een update melding in HA.WargamingPlayer schreef op woensdag 24 september 2025 @ 17:04:
[...]
Ik zie dat je de verkeerde gebruikt hebt. Die jij gebruikt hebt worden niet meer onderhouden en daar zit inderdaad dat issue in:
Je kan het beste deze gebruiken:
https://github.com/WargamingPlayer/HA-Marstek-Venus-E-Modbus
Dit omdat die van @superduper1969 registers mist en al even niet meer is onderhouden.
EX30 - SMER - Ultra sinds 16-03-2024 / Wallbox Pulsar Max / HomeAssistant / Unifi / 3 x Marstek Venus E v2
Helemaal mee eens. Ik zou de yaml gebaseerde integraties ook niet gebruiken.tdolder schreef op woensdag 24 september 2025 @ 17:30:
[...]
Als je de Elfin EW11 gebruikt zou ik de @[RNMC] Viper HACS integratie gebruiken. Ik gebruik deze ook met 3 x Marstek E v2 en deze werkt als een tierelier. En als er updates zijn krijg je netjes een update melding in HA.
Ik gebruik hem zelf nog wel, naast die van @[RNMC] Viper om hem te onderhouden. Maar verder vind ik een HACS integratie veel fijner.
☀️ 8 x 430wp op zuid | ☀️ Huawei SUN2000-3KTL-L1 | 🔋 2 x Marstek Venus-E BMS: 155, EMS: 216 | 📱 Home Assistant | 🚗 Kia EV6-LR 2024 |🔌 Delta 8/8
/f/image/8iXuAjs84pPI24Ad4gN7BAfx.png?f=fotoalbum_large)
Hun "support" schiet wel alle kanten uit moet ik zeggen. Modbus op de V3 is niet mogelijk (maar ze voorzien wel 'n dedicated poort...)
Anyhow, nu heb ik intussen de API beschikbaar in de app, maar tegelijk lijkt het ook dat de homewizard P1 nu veel minder vaak refresht en het vermogen trager aanpast (elke 30 sec).
Elke keer 'n avontuur dus als er remote iets gewijzigd wordt (en ook niet OK dat dat zomaar kan...)
:no_upscale():strip_icc():strip_exif()/f/image/tBB52CrRZsZsqcLpEFVR64hc.jpg?f=user_large)
| 1
2
3
4
5
6
7
8
9
 | esp32:
  board: esp32dev
  cpu_frequency: 240MHz
  flash_size: 4MB
  framework:
    type: esp-idf
debug:
  update_interval: 10s | 
En bij de Text sensors onderaan:
| 1
2
3
4
5
6
7
8
9
 | ## DEBUG
  - platform: debug
    reset_reason:
      name: "Reset Reason"
      entity_category: diagnostic
    device:
      name: "Device Info"
      entity_category: diagnostic
  ## END DEBUG | 
[ Voor 38% gewijzigd door superduper1969 op 24-09-2025 22:01 ]
MTVenus V153 + BMSV215 + CT003 V117 Lilygo Modbus HA integration+ Anker E1600 + 16ZP Enphase + 2ZP Anker + Quatt
:fill(white):strip_exif()/i/2007621700.jpeg?f=thumbmini)
:strip_icc():strip_exif()/u/192109/zonnebloem.jpg?f=community) 
            :strip_exif()/f/image/o4hNma7Ml8BxzyNADOWcqPPZ.jpg?f=fotoalbum_large)
:strip_icc():strip_exif()/u/31772/crop601c5b0229c42_cropped.jpeg?f=community) 
            :strip_icc():strip_exif()/u/2087624/crop65f94e6abd3ee_cropped.jpg?f=community) 
            :strip_exif()/f/image/l6XFZJ6Lbk0CQ7YRElL1zdhm.jpg?f=fotoalbum_large)
/u/59144/aMSN_96.png?f=community) 
            /u/2258536/crop6820923cee807_cropped.png?f=community) 
            :strip_exif()/u/13821/savale.gif?f=community) 
            :strip_icc():strip_exif()/u/233976/crop66603b3e697bb_cropped.jpg?f=community)