Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detection of MPPT trackers switches between settings and solarcharger upon reboot #191

Closed
AminShAT opened this issue Mar 18, 2024 · 43 comments
Labels
shipped A change or bugfix that has been released startup unavailability Devices becoming unavailable due to discrepancies between scanning and startup registration logic

Comments

@AminShAT
Copy link

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.

IMG_0516
IMG_0515

@AminShAT
Copy link
Author

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
Copy link
Author

Any news on this @sfstar?

@sfstar
Copy link
Owner

sfstar commented Mar 29, 2024

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
Copy link
Author

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
Copy link
Author

AminShAT commented Apr 6, 2024

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
Copy link
Author

AminShAT commented Apr 6, 2024

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
Copy link
Owner

sfstar commented Apr 12, 2024

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

@AminShAT
Copy link
Author

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

image

@sfstar
Copy link
Owner

sfstar commented Apr 19, 2024

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:

victron ess config example

@AminShAT
Copy link
Author

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

@sfstar
Copy link
Owner

sfstar commented Apr 20, 2024

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
Copy link
Author

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
Copy link
Owner

sfstar commented Apr 21, 2024

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 sfstar added the startup unavailability Devices becoming unavailable due to discrepancies between scanning and startup registration logic label Apr 21, 2024
@sfstar
Copy link
Owner

sfstar commented Apr 21, 2024

devices screen Which would be this page ^

@sfstar
Copy link
Owner

sfstar commented Apr 22, 2024

@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.

@sfstar sfstar added specsheet mismatch A issue describing the mismatch between the gx modbus spec sheet and actual reported values shipping in next release The fix for this issue will be included in the next released version and removed specsheet mismatch A issue describing the mismatch between the gx modbus spec sheet and actual reported values labels Apr 27, 2024
@AminShAT
Copy link
Author

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

@sfstar
Copy link
Owner

sfstar commented Apr 28, 2024

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:
screenshot hacs

@AminShAT
Copy link
Author

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

image

@sfstar
Copy link
Owner

sfstar commented Apr 28, 2024

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
Copy link
Author

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

@AminShAT
Copy link
Author

This is how settings look,like after reboot

image

@sfstar
Copy link
Owner

sfstar commented Apr 29, 2024

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

@AminShAT
Copy link
Author

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

image

@sfstar
Copy link
Owner

sfstar commented Apr 29, 2024

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

@AminShAT
Copy link
Author

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.

image

@sfstar
Copy link
Owner

sfstar commented Apr 29, 2024

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
Copy link
Author

AminShAT commented May 4, 2024

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

@sfstar
Copy link
Owner

sfstar commented May 4, 2024

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

@AminShAT
Copy link
Author

AminShAT commented May 5, 2024

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

@sfstar
Copy link
Owner

sfstar commented May 7, 2024

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
Copy link

subby28 commented May 13, 2024

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
Copy link
Owner

sfstar commented May 14, 2024

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
Copy link

subby28 commented May 14, 2024

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
Copy link
Owner

sfstar commented May 15, 2024

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
Copy link

subby28 commented May 15, 2024

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
Copy link
Owner

sfstar commented May 15, 2024

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
Copy link

subby28 commented May 15, 2024

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
Copy link
Owner

sfstar commented May 18, 2024

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
Copy link
Owner

sfstar commented May 18, 2024

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
Copy link

subby28 commented May 18, 2024

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
Copy link
Owner

sfstar commented May 19, 2024

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 sfstar added shipped A change or bugfix that has been released and removed shipping in next release The fix for this issue will be included in the next released version labels May 19, 2024
@sfstar
Copy link
Owner

sfstar commented May 19, 2024

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

@sfstar sfstar closed this as completed May 19, 2024
@subby28
Copy link

subby28 commented May 19, 2024

0.3.0 installed and all good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
shipped A change or bugfix that has been released startup unavailability Devices becoming unavailable due to discrepancies between scanning and startup registration logic
Projects
None yet
Development

No branches or pull requests

3 participants