ID 0 not populating anymore

[onemorename]

As i ran into the issue with 2025.1 i moved over to your repo - thanks for taking care of this project now!

Unfortunately after reinstalling the victron integration the rescan doesn't recognize ID 0 anymore so all the entities related to my solar charger etc. are gone now. Any idea what's going on here / how to fix this?

[remcom]

@onemorename Hmm that is strange. Its working for me but i didnt do a rescan. I'm in the process of setting up en debug instance of HA so i can try and debug a little bit more easy.

In de meantime do you see any errors in the logs related to this integration?

[onemorename]

No, unfortunately not - just re-done the install again here to start from scratch:

[remcom]

Oke. I will have a look at it! But give me some time this week so i can make my debug environment so i dont need to debug on my production HA :P

[onemorename]

From what i see on the discussion around 0.2 and 0.3 there were some fixes in the original 0.3 to ensure devices are properly populating under ID 0. The fix meant to run a rescan after the initial setup / restart which is what i have done here. However the number of entities doesn't change here anymore and stays the same - even after the rescan. Thanks, let me know if i can be helpful in any way on this process

[onemorename]

When manually installing Version 0.3 ID 0 doesn't populate as well, it does when installing 0.2 and i can roll forward to the more current releases then. I had to uncomment line 14 in the coordinator.py to make this working in HA 2025.1

[remcom]

Thanks for the input. I think i have some ideas where the issue is coming from. Probably one of the codestyle fixes is causing this issue. I will have a look tonight

[onemorename]

This is how it looks like when setting up 0.2.0.

[onemorename]

So...with 0.2.0 the solar charger entities populate in ID100 as expected after a reboot. Had to uncomment line 14 in the coordinator.py to get it configured at all. When updating to 0.3.0 (original release) and uncommenting line 14 again, reboot these entities change to 'unavailable' and don't come back anymore. Same if i update from 0.2.0 to your 0.3.2. I was on 0.3.0 with HA 2014.12 without any issues - that i can say. Hope that gives some additional backgrounds now - leaving this to you now :-)

[remcom]

I did some testing and i could reproduce this issue after switching to the this repo. if you do a rescan it will correctly start working again.

Does this help for you to? If not can you give me a few entities that are not working anymore?

[mauricevanderlee]

I updated to latest version, restarted and rescanned. Still my energy meter has ID 0 and only digital inputs are available (wich by the way double with digital input with ID 1). Stiil the energy meters are not working, like entity sensor.victron_grid_l1_energy_forward_total

[remcom]

I think it has to do with a change made in last april/may and only popups now when you do a rescan.

@mauricevanderlee can you check share with me the device list you see in the victron integration?

[mauricevanderlee]

In the mean time I did a remove and install of the integration. Now I have two digital inputs and no energy meter.. hereby some screenshots

[remcom]

I think the issue is that the ID0 should not be available and now is just a copy of the first lowest available ID. In your case @mauricevanderlee the grid data should be available in ID100 and the digital input only in ID1 as your seeing in your VRM screenshots

This update was introduced in the v0.3.0 release on the old repo with the following text:

Users that have a device with modbus id 0 connected should perform a rescan after installing this update.
This will seperate the modbus device with id 0 into it's seperate dedicated device.
Unfortunately historical data for the entities, when the device was placed under unit id 100, will not be transfered.
All other entities and devices should remain unaffected.

I think this 'issue' is now occurring because people are switching repo where this update was include while the olde repo never set this update as "latest" so the update was never pushed.

I actually having the same thing i only never used information from the ID0 so i not noticed it.

I updated the migration guide so people are aware of this breaking change

[onemorename]

Well, in my case also the rescan doesn‘t bring back the devices and they all stay ‚unavailable‘. That‘s why i‘m running 0.2.0 right now with uncommented line 14 in coordinator.py as this is right now the only way to get the solar charger data

[remcom]

Your pvinverter data should be available in id 41 and 42 in your case (when i see your screenshots). Can you have a look in your remote console -> settings -> services -> modbus tcp -> available devices. There you can find the id's where the devices are available under.

Also see me post 2 above from here for some more information about this

[onemorename]

I have two virtual integrations running on the victron GX for AC coupled inverters - these are running on ID 41 and 42. These are both showing up successfully.
I have also a DC coupled SmartSolar RS 450/200 which communicates to the GX using Ve.CAN and ending up in ID100 here.
What's also ending up in ID100 is Aggretgatebatteries which aggregates two SerialBattery instances which are running on ID2 and ID3

Hope this screenshot helps

[remcom]

I would prefer a screenshot from the place i mentioned earlier above: In your VRM click in the sidebar on remote console -> settings -> services -> modbus tcp -> available devices. There is a list with all the id's from every device. You should see something similar like Maurice did earlier

(I dont know how big your batteries are but looks like a nice setup that you have!)

[onemorename]

It's two Seplos Battery Packs with 15kwh each :-), Roof is 12 kwp (SmartSolar Charger DC coupled), Garage is 8kwp (integrated with Shelly 3EM) and wall panels 600wp (integrated with Shelly 1PM) - 81% autocracy in January so far while heating the house with a heatpump so pretty cool :-)

Here's the screenshot you asked for - hope it helps!

[remcom]

Nice setup! I don’t have enough space for that much solar!

As seen in your screenshot, the SmartSolar device is actually available under ID 100, not 0. According to Victron’s documentation, ID 0 and ID 100 are equivalent. However, a recent change in the old repository separated devices further, which in your case made them accessible only under ID 100. For more details, check this explanation: GitHub Issue #7 - Comment.

One possible solution would be to revert some of these changes so that ID 0 behaves as it did before. However, this would result in a lot of entities with the same data because they are available in both devices (ID 0 and ID 100).

It’s also uncertain whether ID 0 can be reliably used in the future. Most Modbus clients don’t support ID 0, and while pymodbus currently does, if support is dropped later, ID 0 might become unavailable. That said, this is just speculation for now.

So i'm not sure what the best resolution should be for this issue.

[asmcc]

Hmm, I have similar "effects" with my setup, too. But my intergration in HA ist very new and I used it until now only for test purposes. Therefore it was not problematic for me to delete double entities or to make rescan again and again. But yes, I have generally similar effects with this ID 0. The difference in my case is, that it is not critical for me, since I use energy manager from SMA, which have Modbus TCP. In this case Victron is connected to the energy manager over Modbus TCP, but I use a parallel connection from HA directly to the energy manager (custom modbus yaml) and have all the required energies, voltages, currents and powers directly. The "mirroring" from Victron is in my case not really needed for me.

Very interesting here is the last warning under Victron with this IP address and ffff before, like IPV6...

Edit: I renamed all the devices including entities names. Initially they were named as "grid", "pvinverter", etc.

[remcom]

@asmcc There is indeed still an issue that there is still a bogus id 0 in HA that needs te be fixed. because if we leave it like this is id 0 can be filtered out. if we want to also make the entities available again back in id 0 we should do something different.

The ::ffff: thing is indeed a ipv6 kind of way to show ipv4 address. This is a linux thing to prepare for the time when ipv4 isnt a thing anymore or something to do with the used ip stack if i'm correct

[asmcc]

192.168.120.91 is the IP of my HomeAssistant. And in this case I do not understand this error. Usually HA ask Victron via Modbus. HA is in this case a server and VICTRON a client. Therefore I do not understand, why VICTRON want to connect to HA and not HA to VICTRON. But generally from time point it should be a restart of HA. I assume during polling between HA and VICTRON the connection was lost and VICTRON made this log...

[remcom]

What u see is actually the errors from the rescan. It tries every register to find out which device is connected. If the register isnt there you see this error. But the error is from HA rescanning Victron. Not Victron to HA

[fyrstyk]

Thanks for forking this!

I had the old repo working and had no issues until I lost my BMS in hass, so I came to your repo.

I still have the same issue.

There is an additional solar charger at id 0, and I don't have the BMS info any more. The BMS is a Victron Lynx NG and connected via CAN.

Here are some screenshots:

[remcom]

@fyrstyk If the BMS already dropped before you switch to this repo i think you have maybe a different issue. Just to check. You BMS is still working and showing up in VRM?

Normally VE.can device populate in id 100. Can you find any bms related info there. Before you had the issues. Under which id was the BMS info available (if you remember)

The id 0 you having is related to the issue here but can be ignored for now.

[asmcc]

@remcom Also in my case some entities were not be active after upgrade and rescan. I deleted these, since I do not need it. And I think, that also in my case BMS values are NOT ALL work properly. But in my case that is only my assumption, since I do not have really a "productive" system here. And in my case that is assuming this so named "Pylontech-Compatible-CAN-Protocoll" on a zero documented DEYE battery from China. Therefore in my case that all are only speculations and assumptions. The problem to show it dcirectly on VICTRON is, that you can not see all these values directly under venus.os or under VRM.
My plan for this not documented battery is actually, that I will try to read this battery over CAN or speak to venus.os directly over Modbus TCP to these IDs 0, 100 or others and show all the ansvers. Moreover this DEYE Battery has additionally BAT-to-BAT CAN and BAT-to-BAT serial. Both are also not ducumented, but should be "pylontech-like". I plan these experiments with additional equipment (CAN adapter / Modbus TCP / etc.) and not from HA nor from Venus.OS. If I see in these experiments something interesting for this "ID 0" issue, I will report about it here.

[dazza120]

@remcom Thank you i tried this yesterday but it seemed to knock out all my enteries that i have on the power card tried again today and it seems to be working, I am one of thoes 0 id people are you saying that it is better we start using 100 id now intsead for our entites? For me 0 id has 104 entities/sensor so automations got to be changed too i guess? The annoying Home Assistant update is gone and im on the latest version (Thumbs UP)

[fyrstyk]

@remcom

The BMS is not missing from VRM / Cerbo only in hass. I have a fully working ESS system and have no issues. I only lost the BMS in the integration.

I did some further investigation last night and have managed to find a workaround by changing the VRM id on the Cerbo menu.

All devices present and working as they should be.

The BMS was ID 0, which is the default for CAN, changed to 1, removed and re-setup the integration and boom.

Be aware that I had to power cycle my Mulitiplus after the ID update otherwise the Multi was throwing BMS lost alarms as it had not updated to look at ID 1.

[onemorename]

Victron says you should leave this to ID0 in a ESS System i think, which is why i didn't change it here. Personally i don't care where the entities show up, as long as they show up and stay where they are - so i can use the values for statistics and automation :-)

So, if ID100 is the solution for getting & keeping all of it i'm all for that. Version 0.2.0 works that way - the only downside i have with this is i don't understand the side effects of having line #14 uncommented in the coordinator.py

[dazza120]

@onemorename you say that victon say to keep it at 0 id but then you say if all automations are to be kept running in the future you will change it to 100 id? i'm not sure i follow that as are we not supposted to be adhearing to the registry? if they say ESS is 0 id surely changing it in the future is going to have effects on and ESS especially when victron update the registry for Heat pumps, Non EV Chargers?

I'm not sure what that line does but tested all of my automations and they work, they do seem a tad slow though not sure if ive made that up in my head but sure it was a little faster changing to force charge/discharge and grid set point

[fyrstyk]

Victron says you should leave this to ID0 in a ESS System i think, which is why i didn't change it here.

Where did you get that info from?

I was talking to Victron yesterday evening about this and there was no mention that the ID must be 0.

My ESS is still running as expected and no alarms. Currently charging batteries and directly consuming from solar with no grid power being consumed.

All good on VRM as well.

[dazza120]

@fyrstyk not sure if you want to blank out your VRM ID in the pic bud, was it on the forum that you where talking to them?

[fyrstyk]

@dazza120 blanked, forgot about it :D

No, directly. Luckily for me I'm one of the larger OEM dealers in the UK.

[dazza120]

No worries, @fyrstyk Ok i did wonder as ive seen no chatter at all on there and i know a few people have intergrated home assistant with victron so not sure how no one has raised this, i was holding off to see if the original code maker was going to update the code but does not look like that is going to happen? But thanks goes to @remcom for this but still will like clariety on the ID situation so i can either start to go through where i have used the ID0 entities and switch them with the ID100, so that if @remcom changes the code without ID 0 i'm not left high and dry

[remcom]

The one thing i know of the i0 / 100 is that Victron says this If the device instance is 0 you can use both 0 and 100 as unit ID. Keep in mind that many modbus TCP clients do not support unit ID 0. Thats why i expect that the devices that where available should be shifted to id 100. Or to there Dedicated device if they where available under id 0.

So if the Documentation from Victron is correct u would expect that in for example @fyrstyk case when the bms was back at id 0 it should show ip in id 100.

I'm not sure why the previous maintainer made this change and didn't release it. Maybe because of this effect. I'm not saying yet to remove id 0. In my opinion we have 2 options. Remove id 0 if victron information is correct and it should all be available in id 100. Or we dont care about any duplicate entities in HA and revert that change partially and also keep id0 working as before.

[remcom]

When thinking about it a little maybe its just good to the option that id 0 also start to work as before. then for new people the advice is dont use id 0 but use the other device. And for people already using for id 0 it still works as before. I need to look into the code if this can be done or not. I didnt have a look yet at the working of the rescan process.

What do you guys think?

[dazza120]

@remcom i dont care about the duplications as i'm running specific cards where i have picked the enteries and added them anything in overview i'm not worried about just need them working in the cards which they do so i guess you added back the ID0 as the first time i switched everything on my cards went victron wise, the issue for me is you seem to be very active in maintaining this and its kind of up to you how this code looks does having both cause you any issues? As this would be alot easier for people to switch over to your forlk

[remcom]

@dazza120 I'm not sure if it giving any issues or not in the future. I need to get more familiarized with the code.

For people switching fork it gives less "issues". but there is already a change a lot of people switched. There more downloads then people reporting issue with this. So maybe there already switched and just continuing. For my own HA this changed never impacted me because i never used id 0 (more luck then anything else). A bigger thing for some people can be that historical data for your energy dashboard is not working anymore.

[dazza120]

@remcom Shall play it by ear please let us know in a change log/Rlease notes if you do drop ID 0 thnaks for your hard work in getting this to move to the latest version of HA

[fyrstyk]

I've done a bit more fiddling this afternoon.

Original issue:
My BMS and MPPT are both connected on canbus. Originally BMS was VRM id 0 and MPPT was VRM id 1. I made no changes to the device ID's on the Cerbo.

In the integration I lost the BMS as the MPPT was showing up as ID 0 and 1 in the integration even though it was id 1 on VRM device list. The BMS would not show up in the integration and it's VRM id was 0.

First attempt at fix:
After I initially changed the BMS ID to 1 I noticed that I lost data from the BMS on integration ID 0 after a few hours. A rescan fixed this, however I was not happy with the integration BMS being ID 0 if the Victron docs say 0 and 100 are effectively the same. Maybe I lost the BMS as it was clashing with id 100 (aka 0).

Second attempt (seems to have sorted the issue):
I have just reassigned the IDs, BMS to ID 2, and MPPT to ID 3. It is not possible to have two canbus devices with the same ID as only one will show up in the integration, even though all devices are visible on the GX and VRM.

This is the end result, and all working. Don't forget to restart the Multiplus after changing the IDs.

[remcom]

@fyrstyk Thanks for your extra information. Very valuable! Victron's modbus excel shows indeed that ve.CAN devices are added as id 0: VE.Can device instance 0 and all registers listed as com.victronenergy.system

Give me some time to dig in to this device scanning process. And again, Thanks for all the input you provided

[bartsmetdv]

When changing the device id's to something else then 0 or 100, they show up after a rescan. Unfortunately they get new entity names and the old ones become stale. There is also no way to clean up the old devices in Home assistant.
So I'm now trying to merge the statistics and history in the new entities...

[mauricevanderlee]

Thanks @fyrstyk & @remcom !
After update to v0.3.4, changing my VRM device instance of the grid meter to 5 and a rescan in HA it shows up again!

[AminShAT]

Does not work for me on v0.3.9. Just installed om HA 2025.1.2.

all devices found except the MPPT which is in ID 0. ID 100 Not used in my setup.

[remcom]

I just made a beta release with some fixes around device scanning. You can download it with hacs if you open this integration and then in the menu in the upper right corner and click redownload. then select the latest beta version (0.3.5-beta.1 ). after that reboot your HA and do a rescan.

Keep in mind this is a test. Please do a backup before. No harm should be done to existing entities and there data but better save then sorry with your data

It should work a little better finding VE.can devices with ID 100 and 0. keep in mind that id 0 will not populate anymore and they will show up on ID 100. IF everyone can share they experiences with it

[AminShAT]

Unfortunately did not solve the issue. The integration claims settings at ID 100. In VRM, there is nothing at 100. ID 0 still not found. I even deleted the configuration and did a completely new scan.

[remcom]

@AminShAT can you share the data you see in vrm: remote console -> settings -> services -> modbus tcp -> available devices

[AminShAT]

Sure.

[remcom]

@AminShAT Can you verify your on the 0.3.5-beta.1 release? after installing that version, restarting your HA and then do a rescan your MPPT data should be in the ID 100. If you see your screen shots the solarcharger is available at ID 100

[AminShAT]

Just a did a restart and rescan.

Version is the right one.

Still only 10 devices and settings in ID 100.

[remcom]

@AminShAT Did you check the entities in settings on id 100? i know id 100 is called settings. but also you solarcharger data should be in there now. In your case multiple devices are on ido 100 (settings / hub4 (ess) /solarcharger). The device is called settings because its just the first thing it found on id 100

[AminShAT]

Yep, you're right, now they are there. I checked with the old version, back then they were not, now they are.

Thank you. Also for continuing the work in general!

[remcom]

@AminShAT Nice! No problem at all!

[fyrstyk]

One other thing to check after changing ID's alongside a Multiplus / Quattro restart is the battery monitor in DVCC settings menu and the System Setup menu.

If the battery monitor was set to auto select you should be fine, but I had manually set them and after the device ID change these were both unavailable. Not good for ESS or DVCC.

[onemorename]

Seems this also finally resolved things for me now, thanks! Will still test tomorrow but it looks everything is there under id100 now! And: it should be the way as the devices are on 100 on victron as well. Glad the fix is in a current release now!