Hi @plonkster
Unit ID: 280 / MPPT VE.Can 250/85 is not in the list and is needed by HA (for the integration)…
Will this be added to the Excel sheet at some stage?
Thanks
Ugh… I really really hate what has happened to this.
SSH into the device. Start dbus-spy, then go to com.victronenergy.settings. Scroll down to the /Settings/Devices part of the tree, then look for the serial number of the device, followed by /ClassAndVrmInstance For example:
Hit enter, and now carefully retype the data, but change the end to 200 or some other available number (each solarcharger must have a unique number). Hit enter, and reboot the device.
It should now come up with DeviceInstance=200. For modbus the rule is that the unitid=DeviceInstance if it is below 247, so that also fixes the modbus issue.
It will however cause a new MPPT to show up on VRM, and the data will be interrupted (old data will be lost if you delete the old one). The change in DeviceInstance is detected as an MPPT that was replaced.
Ai - that is a real pity! I am not keen to lose my history at all…
Why does the GX allocate ID: 280 if modbus only allows for 247 id’s?
No way this can be sorted another way…
The only other way is to edit /opt/victronenergy/dbus-modbustcp/unitid2di.csv and add a mapping for 280.
This is a stupid bug that is the result of multiple other things happening.
The first is that the DeviceInstance used to be allocated according to the port that it was plugged in on, and for whatever reason, some of them are allocated really high up. Above 247.
The second reason is that the DeviceInstance is assumed to be the unitid as well. And for those device above 247, it was easy, because we knew exactly what they are, because we knew exactly what ports are available on each platform, so a simple mapping was sufficient.
Then came another improvement: The device instance is dynamically allocated the first time the device is detected, and stored under it’s serial number. That means you can plug the device into a different USB socket (or VE.Direct slot, or whatever), and it retains it’s position. Which is a good thing. But now you get situations where a Device Instance is allocated for which there is no Modbus mapping. And so far the only solution is to manually move the deviceinstance… or factory reset the GX and start over.
Lately however, more and more questions about this arrive… so I think it is becoming time to do something about it.
2 Likes
Thanks for the detailed explanation!! I’ll need to decide what I do 
@plonkster After a lot of thought… Can I disconnect the MPPT then delete the device (use the option on the Cerbo) an then reconnect… do you think it will use the same ID or hopefully one below 200?
It won’t allocate a new ID. The option on the Cerbo merely removes it from the Device List, it does not remove the allocation that is now remembered and held in localsettings.
You can SSH into the device, stop localsettings, edit (carefully!) settings.xml and remove the entry under Settings/Devices, then reboot. That will force it to reallocate things, but that’s no better than the previous suggestion to edit it with dbus-spy.
I experienced the same problem when I added a third MPPT to my system. I tried all above and scoured the forums and I couldn’t get it to work.
As a last resort, I reimaged the micro SD card with a backup I had made and that resolved the issue immediately after wasting MANY hours trying to fix the issue.
Worth a try if you haven’t already?
There was a bug with some MPPTs a while ago, did not pick them up. I had to add the MPPT to the Venus for it to be picked up.
Was fixed in later releases.
IF that is the same issue, do as @Thaelian said, update to the lastest release.
Nervous as this isn’t exactly (like in far from) in my skill set
Just to clarify, I didnt have to update VenusOS to the latest version, I used an image backup of the exact same version written to the same SD card. Merely having all three MPPT’s in the system at boot up brought Venus online with all the correct device ID’s.
Update: I editied the settings file and then installed the latest candidate release as well. This seems to have triggered the change and I now see the MPPT that was missing. Modbus ID has changed, to what I set it to, as well.
Thanks for all the help!
1 Like
Looks like the fix for the above…?
https://community.victronenergy.com/questions/210133/venus-os-v3102-available-for-testing.html
Changes v3.10~8 → v3.10~9
- Complete ModbusTCP mapping list for unit ids above 255. From now on it will not longer be required to get into difficulties when having a VE.Direct-connected or other type of device that has a VRM Instance above 255.
Yup. Went on a bit of a cleanup spree, and after doing a deep dive in the data (to check if there will be conflicts with real devices in the 200-247 range), added mappings for everything.
A future version of the GUI will also include a way to edit the DeviceInstance, which will also allow you to choose something below 247, hence making it accessible via modbus as well.
In the end, there is always going to be a mapping issue here. DeviceInstance is a 16-bit positive number. Modbus address is a byte (and in RTU style, 248 and above is reserved, and 0 is broadcast, taking up even more of the precious space). There is literally 256 possible conflicts for every address, so the long term solution is really just to move the ones you want into range.
Many Thanks Plonkster! That was a frustrating issue