Detection of MPPT trackers switches between settings and solarcharger upon reboot

[AminShAT]

Hi,

sometimes I need to reconfigure my MPPT trackers after reboot, because they are not found at the right device anymore. It looks a bit like, the device that is detected first gets the trackers assigned.

[AminShAT]

Hi @sfstar. Were you able to look at that already?

I am reluctant to install the new HA core update, because I do not want to have change all config again after a reboot.

BTW: what just comes to my mind: might this also depend on the time of day, you do the reboot, e.g. if the MPPT is on during sunshine hours or off during the night?

Best

Amin

[AminShAT]

Any news on this @sfstar?

[sfstar]

Hello AminShAT and thank you for opening this issue,

This is an older present issue going back to #47. It requires more investigation before an solution can be implemented. Could you perhaps verify your theorie regarding the available when the device is not producing energy?

[AminShAT]

Hi,

Will do so, you mentioned version 0.2 available already, right? In HA I still get pointed to the 0.1.7 release. Anything I need to do?

[AminShAT]

Hello,

Can not confirm my theory. Currently all parameters remain with the settings device regardless, if I restart during night or day times.

Best

Amin

[AminShAT]

Update:

I found out, that the rescan and startup sequence behave differently:

rescan assigns the parameters to the MPPT-loader. restart assigns the parameters to Settings.

I did a rescan this morning for the 4th inverter and got the parameters misassigned to the MPPT. After the update and reboot this evening, everything was fine. So I did a rescan again and saw the same issue as this morning. A reboot fixed it again for me. So the phenomenon should be reproducible.

Best

Amin

[sfstar]

Thank you for this insightfull finding. Could you perhaps share your integrations stored config from the .storage directory?

[AminShAT]

Happy to help, but can you tell me, which file you need exactly?

[sfstar]

Thank you @AminShAT,

My apologies for my late reply. The config should be located in the core.config_entries file and should look something like this:

[AminShAT]

The content is actually quite large. Do you need certain parts?

[sfstar]

Only the json part for the victron integration. You can recognize it with the "domain": "victron" part and select the data between the entry_id line above the domain part until the disabled_by line. It will help me by providing me with a config that allows for the reproduction of your startup behaviour in my local test environment.

[AminShAT]

Thank you for your help. If you need any additional info about my Victron system, let me know.

Here you go:

{ { "entry_id": "5fcd9f30cdad58e7e3c52ef455d8452e", "version": 1, "minor_version": 1, "domain": "victron", "title": "", "data": { "registers": { "30": [ "gavazi_grid_registers" ], "34": [ "pvinverter_registers" ], "35": [ "pvinverter_registers" ], "36": [ "pvinverter_registers" ], "40": [ "evcharger_productid_registers", "evcharger_registers" ], "100": [ "solarcharger_registers", "solarcharger_tracker_voltage_registers", "solarcharger_tracker_registers", "settings_registers", "settings_ess_registers", "system_registers", "system_battery_registers", "system_dc_registers", "system_charger_registers", "system_power_registers", "system_bus_registers" ], "225": [ "battery_registers", "battery_detail_registers" ], "227": [ "vebus_registers" ] } }, "options": { "ac_voltage": "230", "number_of_phases": "3", "ac_current": 65, "dc_voltage": "48", "dc_current": 100, "use_sliders": true, "host": "192.168.179.23", "port": 502, "interval": 1, "advanced": true }, "pref_disable_new_entities": false, "pref_disable_polling": false, "source": "user", "unique_id": null, "disabled_by": null },

[sfstar]

Thank you for the config. I believe I've found the source of the difference in behaviour between the rescan and restart logic. Would you be able to screenshot the devices screen after a rescan and after a reboot in order to confirm? (Where the unit IDs are visible)

[sfstar]

Which would be this page ^

[sfstar]

@AminShAT could you perhaps test the main version of the integration? I believe the changes there (that haven't been tested yet) should address the rescan / restart behavioural differences when it comes to the unit id 100/0 The scanning behaviour has now been made to conform to the restart behaviour, since the ve.can device with id 0 is not settings/system related.

[AminShAT]

Hello, sorry for the delay, just tested. Unfortunately same behavior as before.

[sfstar]

No problem, I'm not really sure why it seems to solve the behaviour for the same issue that was reported in #47. This might be an superfluous question, but are you sure HA was restarted with the main version installed? You can check this by looking at the hacs victron repository page and checking whether this commit id is present in the left top of the page:

[AminShAT]

I have a different built number. It solved the issue with not recognizing the required Modbus ids though.

[sfstar]

Sorry my own instance was running an older version. 😅 8adae6c is the correct version. Just to double check: Upon scanning the solar charger registers for ID 0 should be assigned to the solar charger device and this should remain upon restarting. (The entities made under unit ID 100 should no longer be available). Is this the case on your end?

[AminShAT]

First behavior is correct, but upon restart they get again assigned to 100 (settings)

[AminShAT]

This is how settings look,like after reboot

[sfstar]

Hmm, could you share the entity id of one of the entities that get assigned to settings upon a restart?

[AminShAT]

It's all parameters of the MPPT (solarcharger). This device has ID 0.

[sfstar]

Thanks, could you also share the entity id of the entities "solarcharger alarm" and "PV Ost Kurz"? Should be something like sensor.victron_....

[AminShAT]

Herr you go.

With the alarms you see nicely the other entities at ID 0 (MPPT) that are not populated, but only the ones at ID 100 (settings)

PV Ost Kurz/lang and PV West kurz/lang are the 4 strings attached to the MPPT.

[sfstar]

I pushed some debug logging to main. Could you redownload the integration (main version) and perform the test again with debug logging enabled? Please add the debug log file to this ticket

[AminShAT]

The new main version does not connect at all, all values unavailable. Had to go back to 2.0.

[sfstar]

Sorry, not all changes were included as they were supposed to be. Please try again with the latest commit

[AminShAT]

No change. I installed version b18b063 (main). All connections gone. Back to v2.0 they are there again.

[sfstar]

I'm so sorry, I patched the commit on main (and tested it myself in my production environment this time). Could you the latest version on main again?

[subby28]

Mine was working (as in, not requiring reconfigure after restart). However its now stopped again. I've just re downloaded "main" and it still requires a reconfigure after each restart.

[sfstar]

Thank you for testing @subby28. Could you provide the debug logging for the integration when running the latest main version? So that I might further troubleshoot the issue.

[subby28]

of course no problem.

See attached. One log following a restart, and another following a rescan, and full log - restart and rescan.

Thanks for your support with this issue, and also for your time and effort with the integration. It is greatly appreciated. after rescan.txt after restart.txt home-assistant_victron_2024-05-14T20-04-57.847Z.log

[sfstar]

Thank you for testing the changes. Based on the debug output I've made some changes (which are now present on master). Could you perhaps install the latest main commit and test again?

[subby28]

Just tried the latest main, and it didn't work. Lost most entities, and wouldn't find them even following a rescan. Had to revert to 0.2

[sfstar]

Weird I'm running the latest main commit on my production instance without issues. Did you manage to capture the debug logging from when main was installed? If so could you provide the logging?

Did the entities dissapear completely or was it mostly the unit id 0 entities?

[subby28]

I just tried the main again. Strangely it got most of the entities upon the first restart (other than the solarcharger @ 0), but when I did a rescan, it lost them all. It was device ID 226, 227, 100 and 0 that didnt work.

Log here: https://drive.google.com/file/d/1aSXtoFWjPe2Bhgz1NuDprpu6A8I8Hxbq/view?usp=sharing

[sfstar]

It seems that the updates get send to the correct device id 0 for the solarcharger:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 258, in _handle_refresh_interval
    await self._async_refresh(log_failures=True, scheduled=True)
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 414, in _async_refresh
    self.async_update_listeners()
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 168, in async_update_listeners
    update_callback()
  File "/config/custom_components/victron/sensor.py", line 156, in _handle_coordinator_update
    if self.available:
       ^^^^^^^^^^^^^^
  File "/config/custom_components/victron/sensor.py", line 176, in available
    return self.coordinator.processed_data()["availability"][full_key]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
KeyError: '0.solarcharger_battery_voltage'

But that the entity isn't being registered with the new entity id. Similair thing happened when a enum status code couldn't be decoded, resulting in more than the offending entity not being available. Need to look deeper into why the correct entity id isn't being created

[sfstar]

I've just tested and pushed a new commit to main. Could you test the new commit and report / attach the new debug logging? The new commit changes the scanning behaviour which should ensure the charger gets seperated correctly. Unfortunately the change is only noticable after a rescan and should thereafter be reboot persistent. Please let me know what you find

[subby28]

I've just tested and pushed a new commit to main. Could you test the new commit and report / attach the new debug logging? The new commit changes the scanning behaviour which should ensure the charger gets seperated correctly. Unfortunately the change is only noticable after a rescan and should thereafter be reboot persistent. Please let me know what you find

I've just tested it and it appears to be working correctly! As you said, It took a rescan following the first restart but each subsequent restart is now completely fine and doesn't require a rescan.

I think you've cracked it !

[sfstar]

Thanks for your quick testing and replies. I'm gonna cleanup the code a little bit. After which I will release this (and other) changes as an official release.

[sfstar]

The issue has been shipped in the latest release (v0.3.0) closing issue as resolved. Feel free to re-open if the issue persists with the v0.3.0 release

[subby28]

0.3.0 installed and all good.