2.2.1 to 2.2.2: grid meter now shown as two devices with different model but only one has entities

[spali]

Describe the bug
On 2.2.1 I had two devices:
I1 (inverter)
M1 (attached meter with model SE-RGMTR-1D-240C-A).
Attached meter showed as model "SE-RGMTR-1D-240C-A".
Since 2.2.2.
I have:
I1 (inverter)
M1 (SE-MTR-3Y-400V-A) <- no entities
M1 (SE-RGMTR-1D-240C-A) <- has all the expected entities

Expected behavior
not sure if this is really a bug or expected, but at least physically only one meter is attached.

Screenshots

Home Assistant (please complete the following information):

• Home Assistant Core Version: 2022.9.5
• solaredge-modbus-multi Version: 2.2.2

[WillCodeForCats]

I will try and see if I can duplicate it in my modbus simulator.

[WillCodeForCats]

I checked that the change in v2.2.2 to fix duplicate serial number detection (PR #98) is working correctly in my modbus simulator.

What you are probably seeing is the changing meter identification reported in issue #61 and fixed in PR #83 across reloads. When the integration is reloaded Home Assistant will see the changed model name as a different "device" and creates a new device in the device registry, but it has no sensors since the PR #83 makes sure data stays with the correct m1_* entities and don't change names by adding a _2 at the end of the names.

The fix in PR #83 can't do anything about the reported device info changing, but I can look into the possibility of removing devices with no sensors from the device registry.

[spali]

What's strange ... the 400V device has a firmware version 77 which is correct regarding the SetApp and the new device with entities has 0 as firmware version.
And due I have a 3 phase meter, I assume the 400V one is the correct one I have. Can't find a model on the physical device itself.
So maybe it's exactly the opposite of #61.
Assuming the above is correct, the 240 device should not exist in my case and the entities should be related to the 400V model.

Do you know where in the SetApp I can find the model that is detected by the inverted... I couldn't find it on the physical device itself.

[WillCodeForCats]

Actually it looks like this is happening because I missed changing the device ID for the registry along with the unique ID change that was made in #83. All the entities are fine but when the problem happens, it's silent in the background until the integration reloads, then it makes a new device with no entities because the entities followed to the "correct" one.

[WillCodeForCats]

Addressed in PR #103

[WillCodeForCats]

In SetApp it might just be on the main status monitoring page.

[WillCodeForCats]

The inverter treats meters as position assigned, so in setapp meter 1 will always be meter 1 in modbus, no matter what the device itself changes to. The fix for #61 was to ignore the meter model and serial number for the Home Assistant entity unique ID and just use the "position" of M1, M2, or M3 and the inverter's model as the unique id. The meter device information is nice to have but apparently not accurate for some inverters. I had tried to use the model and serial number because that's what the home assistant dev docs best practice says to use, but it didn't work for everyone.

With my meter I don't have the problem reported in #61 where the meter info changes, but the label printed on my meter does not match what the inverter reports over modbus.

[spali]

In SetApp it might just be on the main status monitoring page.

It only shows a meter at rs485 with the id, but no details about it.

[WillCodeForCats]

PR #103 should prevent the devices with no sensors from being created, and I'm looking into how those can be deleted from the user interface. Removing and re-adding the integration will clear them but I'd prefer a more user friendly way.

[spali]

Removing and re-adding the integration will clear them but I'd prefer a more user friendly way.

Will keep by duplicate for next upgrade, so we can test it in a live environment.
Due the sensor entities stays the same its only cosmetic except the device metadata, wich I don't care.

[spali]

@WillCodeForCats
Now after the upgrade 2.2.3 I have 4 devices in total 😄
another "SE-RGMTR-1D-240C-A" empty was added.

So I have now:
I1 (inverter) still looks good.
M1: SE-MTR-3Y-400V-A (still there with a firmware version and no without entities) (same as after 2.2.2 upgrade)
M1: SE-RGMTR-1D-240C-A (empty and no firmware) (new after 2.2.3 upgrade)
M1: SE-RGMTR-1D-240C-A (has all the entities without firmware version) (same as after upgrade 2.2.2).

It seems that it detects on every upgrade a new SE-RGMTR-1D-240C-A.

[WillCodeForCats]

I don't know how that's possible after changing the device entity identifier to a static value in PR #103.

[WillCodeForCats]

I would recommend deleting the devices as they appear, or open a ticket with SolarEdge support about the missing firmware version and unstable identifier reporting data.

[spali]

during these three upgrades I made...
The identifier change 3 times and left the old one in the device registry.
My assumption:
Maybe just not the best handling during upgrades of existing id's.
But probably it doesn't happen again when the identifier logic stays the same now 😄

Just in case, below the entries and my theory about it.

I know adb0c3ae1385be899d9647c9f6e078cd was the first one I had initially on 2.2.1.
I know 08acd4f55e91a5eec50ab45125fb85d5 has now all entities.

I guess the order in which they appear in the file, is the order they where seen.
So on 2.2.1 it was adb0c3ae1385be899d9647c9f6e078cd for sure with the 400V model.
In 2.2.2 it introduced (guessed) eddc72984ee23afeda99d18c3c831bee.
In 2.2.3 it introduced (guessed) 08acd4f55e91a5eec50ab45125fb85d5.
You can see that every time the identifier changed.

core.config_entries:

      {
        "entry_id": "cea206f8e4d8fd0ebb4998f93448597c",
        "version": 1,
        "domain": "solaredge_modbus_multi",
        "title": "SolarEdge",
        "data": {
          "name": "SolarEdge",
          "host": "10.2.0.72",
          "port": 1502,
          "number_of_inverters": 1,
          "device_id": 1
        },
        "options": {
          "scan_interval": 1,
          "single_device_entity": true,
          "keep_modbus_open": true,
          "detect_meters": true,
          "detect_batteries": false
        },
        "pref_disable_new_entities": false,
        "pref_disable_polling": false,
        "source": "user",
        "unique_id": "10.2.0.72",
        "disabled_by": null
      },

core.device_registry:

      {
        "config_entries": [
          "cea206f8e4d8fd0ebb4998f93448597c"
        ],
        "connections": [],
        "identifiers": [
          [
            "solaredge_modbus_multi",
            "SE17K-RW0T0BNN4_7E0F7B1C"
          ]
        ],
        "manufacturer": "SolarEdge",
        "model": "SE17K-RW0T0BNN4",
        "name": "Solaredge I1",
        "sw_version": "0004.0015.0119",
        "hw_version": "",
        "entry_type": null,
        "id": "8fa92183297abe1c75a6789d76077af8",
        "via_device_id": null,
        "area_id": null,
        "name_by_user": null,
        "disabled_by": null,
        "configuration_url": null
      },
      {
        "config_entries": [
          "cea206f8e4d8fd0ebb4998f93448597c"
        ],
        "connections": [],
        "identifiers": [
          [
            "solaredge_modbus_multi",
            "SE-MTR-3Y-400V-A_606732213"
          ]
        ],
        "manufacturer": "SolarEdge",
        "model": "SE-MTR-3Y-400V-A",
        "name": "Solaredge M1",
        "sw_version": "77",
        "hw_version": "Export+Import",
        "entry_type": null,
        "id": "adb0c3ae1385be899d9647c9f6e078cd",
        "via_device_id": null,
        "area_id": null,
        "name_by_user": null,
        "disabled_by": null,
        "configuration_url": null
      },
      {
        "config_entries": [
          "cea206f8e4d8fd0ebb4998f93448597c"
        ],
        "connections": [],
        "identifiers": [
          [
            "solaredge_modbus_multi",
            "SE-RGMTR-1D-240C-A_0"
          ]
        ],
        "manufacturer": "SolarEdge",
        "model": "SE-RGMTR-1D-240C-A",
        "name": "Solaredge M1",
        "sw_version": "0",
        "hw_version": "Export+Import",
        "entry_type": null,
        "id": "eddc72984ee23afeda99d18c3c831bee",
        "via_device_id": null,
        "area_id": null,
        "name_by_user": null,
        "disabled_by": null,
        "configuration_url": null
      },
      {
        "config_entries": [
          "cea206f8e4d8fd0ebb4998f93448597c"
        ],
        "connections": [],
        "identifiers": [
          [
            "solaredge_modbus_multi",
            "SE17K-RW0T0BNN4_7E0F7B1C_M1"
          ]
        ],
        "manufacturer": "SolarEdge",
        "model": "SE-RGMTR-1D-240C-A",
        "name": "Solaredge M1",
        "sw_version": "0",
        "hw_version": "Export+Import",
        "entry_type": null,
        "id": "08acd4f55e91a5eec50ab45125fb85d5",
        "via_device_id": null,
        "area_id": null,
        "name_by_user": null,
        "disabled_by": null,
        "configuration_url": null
      }

[WillCodeForCats]

The only one possible after PR #103 is the last one. The other two meter device entries are not possible after PR #103.

[spali]

That's what I thought.
The other ones are from 2.2.1 and 2.2.2.
So I clean them up somehow from the device registry.

[WillCodeForCats]

Click the "delete" button in the UI.

[WillCodeForCats]

I can't automatically look for and delete them during startup because I can't think of a way to tell the difference between a device that has been replaced intentionally, a device that has failed, or a temporary failure that can be fixed with the device brought back online.

I added support for removing devices in the Home Assistant UI which is the best way I could think to handle it.