Device Address 0/100 about hass-victron

[subby28]

Hello @subby28,

Could you perhaps test the 'main' version of the integration? This should contain the fix in the integration code to assign non system/settings registers to unit 0. If someone with an unit 0 system test the change, I will be able to create a new release that resolves this issue for all users without the need for manual changes to the integration

Just tested it and it's fixed the issue!

[OlePZ9]

Actually my Solarcharger MPPT 450/100 got Address "0" on Cerbo GX. So after a retart the Solarcharger had been recognized under "Generator" with a new entity name xxx_0 instead of xxx_100. I changed one setting in the file "const.py" under custom_components/victron in line 1336. I added "0" as valis unit id. After a reboot my entities were there again, this was important for me to keep my statistics history

[pos-ei-don]

Had the same yesterday. But i also had Devices which really got a new id in the vrm. Strange. Sorry to ask, I am new to HA.
Is a manual fixation as you mentioned possible with automatic created entities? When I try to do, everything is greyed out. So all my Utility and Templates stopped working and I lost historical data...

[OlePZ9]

It really wrote new (wrong ) addresses from this integration into VRM? That is very dangerous and would be a severe argument against the write option. What devices (numbers) were / are affected?

[pos-ei-don]

No. Vmr or venusos itself change the ids after a reboot. I have no idea why. But i had this before using this dintegradion from time to time.
I had to manual ly Update everything as All entities, all Templates and all Plots where suddently wrong.

[Next9999]

Same for me, the device address skip from 0 / 100... leaving the GPS (0) with no data

[tastyllama]

Re scanning the integration seems to bring the device 0 back online for me. Every reboot device 0 goes Unknown, then I go to Integrations/devices and reconfigure and rescan the victron integration. Then it works.

[OlePZ9]

Now, after working flawlewss since months, the upgrade to the recent version brought back this issue.
My Solarcharger (MPPT 450/100) now got back Address 0 instead of 100 before. This is unreliable. As from Victron side "100" is the correct one, that should be editable during configuration, so that scanning does not bring up the wrong value

[OlePZ9]

even "better" the solarchager 450/100 now is being called "generator" with device ID 0

[OlePZ9]

as stated in my last two comments

[gnissahr]

I have similar issues, but with a Lynx Shunt. It alternates between ID 0 and 100. The change happens with a HA restart for example. The Cerbo was not rebooted in the mean time.

[andlo]

Me to - after restart Homeassistant GPS isnt loaded - and a rescan will fix that until next restart of homeassistant :(

But when it works it works great :)

I connect to at VenusOS runnng in my RV throu a ZeroTier VPN connection. So in teory the problem could be that the modbus cant connect when initialized due to the tnetwork connection isnt up at the same time.

[Snooz82]

I have similar issues.

butni think it is due to a bug on the Victron side that ID 100 is double used for non „system“ devices.

https://www.victronenergy.com/live/ccgx:modbustcp_faq

As you can see 0 and 100 are same and point to the same device.

but in my case the Solar Charger is the one that occasionally is unknown until rediscovering devices manually.

See the 100 is assigned to the solar charger and to com.victronenergy.system and also com.systemenergy.hub4

I have to figure out how to regenerate or change the Modbus TCP IDs for the Solar Charger.

[Snooz82]

Even though it imho is not the fault of this integration, a workaround on this side seems possible.

please let this issue open until anyone has found out how to change the ids to a unique one.

[Snooz82]

I think i managed to fix it.

I could change settings of the "problematic" devide, in my case the SolarCharger, so that it gets a new Modbus TCP Device ID.

When connected via SSH to the Venus device, open the settings.xml in /data/conf.

Like:
nano /data/conf/settings.xml

you have to change the id of the device, that you have identified as the malicious one altering between 0 and 100.
In my case it was stored like this:
<ClassAndVrmInstance type="s" default="solarcharger:0" silent="False">solarcharger:0</ClassAndVrmInstance>

So i changed the default attribute and the text to solarcharger:290 which i guessed was not used.
After reboot it looked like this and the Modbus TCP ID is now changed to 237 which is also showing up as such in Home Assistant.

  ...
  <Devices>
   ...
    <vecan_socketcan_can0_CXXXXXXXXXXXXXX>
      <ClassAndVrmInstance type="s" default="solarcharger:1" silent="False">solarcharger:290</ClassAndVrmInstance>
    </vecan_socketcan_can0_CXXXXXXXXXXXXXX>
    ...
  </Devices>

of course this is now a new device, but that is ok for me.

[askpatrickw]

Cerbo GX 3.11
Home Assistant 2023.10.5
Supervisor 2023.10.1
Operating System 11.1
Frontend 20231005.0 - latest
HASS Victron v0.1.5

I can confirm with all the latest everything as now this is still occurring.

[OlePZ9]

[subby28]

Just came to thank you for the fix. I've had this issue for many years and haven't been able to work it out. Adding 0 to valid unit IDs has now sorted it and no more reconfiguring every time HA restarts!! Thankyou.

[sfstar]

Hello @subby28,

Could you perhaps test the 'main' version of the integration? This should contain the fix in the integration code to assign non system/settings registers to unit 0. If someone with an unit 0 system test the change, I will be able to create a new release that resolves this issue for all users without the need for manual changes to the integration

[OlePZ9]

How can I test the main version of the integration. I am using the official release

[sfstar]

You can use the instructions provided in this comment (from another issue):
#182 (comment)
Thanks in advance for taking the time to test the changes

[the78mole]

When I apply the fix and I compare the the devices, it seems to mix in ESS/Cerbox GX stuff into the ID 0 charger:
Charger 1 (correct):

Charger 0 (incorrect mixin)

[sfstar]

Hello @the78mole,

Could you perhaps install the latest main commit and collect debug logging / attach this to this ticket so I can troubleshoot the issue you are having?

[the78mole]

Uh, will be hard this week. Maybe tomorrow, if it does not get too late.
I also first need to check, how to apply the main branch to the custom component...

[sfstar]

If you can make it work it will be greatly appreciated.
You can follow the instructions in this comment: #182 (comment)

[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