Sensor Changes for Marstek Venus E Gen 3.0

[mgutt]

This PR adds new sensors for the Venus E v3 that have been validated on real hardware (firmware V148).

New Sensors

Version

• ems_sub_version (30201) — EMS sub-version (energy logic / charge-discharge algorithms)
• vns_version (30203) — VNS version (WiFi/BT module); confirmed in app as "VNS:117"

BMS Temperatures

• bms_temperature_1 (34011)
• bms_temperature_2 (34012)

Battery Pack Temperatures

• battery_1_temperature (34013)
• battery_2_temperature (34014)
• battery_3_temperature (34015)
• battery_4_temperature (34016)

Network

• wifi_ssid (41500) — WiFi SSID (16-char string)

Enhanced Sensors

• bluetooth_status (30301) — Added state mappings: Disconnected / Connected after reboot / Connected / Active / Locked

[ViperRNMC]

Also include your firmware, because sometimes something changes with the change of firmware

[mgutt]

The sensors are finished:

Now I'm finalizing the new diagnose values...

[mgutt]

New features:

• Auto Cleanup of replaced / removed sensors
• Generic DERIVED_SENSOR_DEFINITIONS to return "virtual" sensors based on multiple other sensors

And the diagnostics values now contain several new registers, too (Tested with firmware V147 and V148):

Changes regarding "VNS" and the new virtual "Firmware-Version" sensor are based on the last firmware update:

[mgutt]

I made many tests (changing modes, charging, through modbus or android app, etc.), but was finally not able to find the meaning of these registers:

Register	Sensor	Value
37000	bms_online	1
34004	bms_code	3
30106	bms_status	4
35111	setpoint_a	330
35112	setpoint_b	500
30212	unknown_30212	5
32101	unknown_32101	39321
35110	unknown_35110	576
45603	unknown_45603	9985
45604	unknown_45604	20599
45605	unknown_45605	74
47400	unknown_47400	43707

[mgutt]

Stats:

• This PR adds 58 sensors:
  • 25 new unique sensors
  • 25 duplicates (alternative register)
  • 4 renames (ac to inverter)
  • 4 derived sensors (firmware version, ac_power, ac_current and ac_offgrid_current)

[mgutt]

It seems something is broken after merging the code bases. Will check that...

[mgutt]

@ViperRNMC
Should I uncomment all *_alt sensors as they are only duplicates of already existing sensors or should we add them as disabled by default?

[ViperRNMC]

I would not bring the _alt myself, but I would document it somewhere in case it is needed in the future. I don't have a v3 myself, so I would like someone to check this change.

[mgutt]

Ok, all *_alt Sensors are kept as comments but translations have been removed.

[mgutt]

I would like someone to check this change.

Do you merge it into a beta branch? I added a release in my fork, but this could be confusing for the user as he would have the integration twice:

And as both target the same directory, they delete / overwrite each other.

[mgutt]

It seems I uncommented too much as I don't have a "normal" battery voltage anymore:

And this isn't normal, too, as its naming does not contain inverter, offgrid, etc.:

Will re-check those...

[mgutt]

It seems I uncommented too much as I don't have a "normal" battery voltage anymore:
And this isn't normal, too, as its naming does not contain inverter, offgrid, etc.:

Ok, both issues fixed and removed some obsolete translations, too.

[ViperRNMC]

@Schrolli91 @sphings79 What device do you have? Can you review this PR?

[Schrolli91]

I do have an E Gen3, but ...

In my opinion this PR mixes up a lot of total independent and different changes, which makes it hard to review. This should be split up.

If I look at the changes, the PR summary seems incomplete too.

[mgutt]

I will split it in multiple PRs

[Schrolli91]

Some first points.
But in general this PR is way to big to make a clean review.

Splitting it up in functional, depending pieces makes more sense in my opinion.

[Schrolli91]

It also will be better to split up the sensor additions to functional parts (PRs) because there al lot of additions and maybe some of them have to be discussed a little bit more.

[sphings79]

@Schrolli91 @sphings79 What device do you have? Can you review this PR?

None at the moment.
I'm awaiting my Venus D the next days.
And I have a friend with a Venus A.

[mgutt]

This PR is still way to big in my opinion, and mixes things together (Fixing Bugs, Adding Things, Changing others ...).

Done
#221
#222
#223
#224

In that case that should be named cell_pack_* or cell_1_to_4_ to clarify this. Because we also have the cell voltage sensors which maps directly to each single cell.

Done

[sphings79]

This PR is still way to big in my opinion, and mixes things together (Fixing Bugs, Adding Things, Changing others ...).

Done

#221

#222

#223

#224

In that case that should be named cell_pack_* or cell_1_to_4_ to clarify this. Because we also have the cell voltage sensors which maps directly to each single cell.

Done

Should be renamed to pack_#cell# as Venus D will have 4 temp sensors in each pack

[mgutt]

Should be renamed to pack_#cell# as Venus D will have 4 temp sensors in each pack

I changed it to:

battery_1_temperature

Because existing pack sensors use this naming scheme, too:

      "battery_1_cell_1_voltage": {
        "name": "Battery Pack 1 Cell 1 Voltage"
      },

      "battery_soc_1": {
        "name": "Battery Pack 1 SoC"
      },

[mgutt]

I think, most people are only "users". I'm not sure if it is a good idea to bring some sort of "dev debug features" in the integration.

Maybe it's an option to add a complete new "battery"-type as e_v3_test.yaml or something which can contain all these additional unknown or testing entities. But that's maybe a questen for @ViperRNMC

I think, most people are only "users". I'm not sure if it is a good idea to bring some sort of "dev debug features" in the integration.

Maybe it's an option to add a complete new "battery"-type as e_v3_test.yaml or something which can contain all these additional unknown or testing entities. But that's maybe a questen for @ViperRNMC

This needs an answer. It cost me weeks to analyze the whole range of all registers and it would be sad not to record alternative and unknown sensors and their known values somewhere.

[mgutt]

firmware_version is now part of this PR:
#223

Both of them are ready for review.

[mgutt]

I think, most people are only "users". I'm not sure if it is a good idea to bring some sort of "dev debug features" in the integration.
Maybe it's an option to add a complete new "battery"-type as e_v3_test.yaml or something which can contain all these additional unknown or testing entities. But that's maybe a questen for @ViperRNMC

I think, most people are only "users". I'm not sure if it is a good idea to bring some sort of "dev debug features" in the integration.
Maybe it's an option to add a complete new "battery"-type as e_v3_test.yaml or something which can contain all these additional unknown or testing entities. But that's maybe a questen for @ViperRNMC

This needs an answer. It cost me weeks to analyze the whole range of all registers and it would be sad not to record alternative and unknown sensors and their known values somewhere.

I created a README for the research results:
#225

[sphings79]

I think, most people are only "users". I'm not sure if it is a good idea to bring some sort of "dev debug features" in the integration.

Maybe it's an option to add a complete new "battery"-type as e_v3_test.yaml or something which can contain all these additional unknown or testing entities. But that's maybe a questen for @ViperRNMC

I think, most people are only "users". I'm not sure if it is a good idea to bring some sort of "dev debug features" in the integration.

Maybe it's an option to add a complete new "battery"-type as e_v3_test.yaml or something which can contain all these additional unknown or testing entities. But that's maybe a questen for @ViperRNMC

This needs an answer. It cost me weeks to analyze the whole range of all registers and it would be sad not to record alternative and unknown sensors and their known values somewhere.

I created a README for the research results:

#225

Perhaps it will be possible to have a dev.yaml wich can be activated through reconfiguration with a slider, which clearly declares, that it is only for developer. Other way would be to install the integration twice. One main branch and analyst branch and use a Modbus proxy for the connection.