I was wondering when using Modbus ID 242 and register 12 I get 1/10th the Power value that my device actually consumes/feeds back. Looking at the register list I see the values are scaled down to provide X * 0.1 on Modbus query.
What will I officially break if I change the scale from 0.1 to 1? Changing to 1 gives me the actual value that I require so on the surface that seems to work fine.
com.victronenergy.vebus(242) | Input power 1 | 12 | int16 | 0.1 | -327680 to 327670 | /Ac/ActiveIn/L1/P | no | VA or Watts
Well, it is going to revert back to 0.1 every time you do a firmware upgrade. But nothing else will break…
There are two reasons why it is scaled by 10. First, because 32kW is a tad low for the actual capabilities of larger systems, and second, because it doesn’t measure down to watt-level accuracy anyway.
Why not just multiply it back by 10 on the consumer end?
Thanks. I also checked VRM etc and they are all fine. I thought as much regarding the accuracy but my OCD doesn’t allow for seemingly inaccurate presentation when multiplying by 10. I however might go the default x10 route in the future, I’ll think about it if it becomes a nuisance to change it every time on upgrade.
Yes, we’re not logging to VRM through modbus-tcp. It goes directly from dbus (and often the things logged are not the same, the stuff logged to VRM is mostly a subset of what is available on modbus-tcp, with the odd exception).
A better solution would be to duplicate that line and add your own definition at the bottom of the file, on some unused register, I would suggest above 35000 but below 40000. Then you are not modifying an existing definition, merely adding an alternate one. We already have examples of that, you will find in the spreadsheet that some of the energy counters started out as 16-bit values, and later grew 32-bit alternatives to handle the bigger numbers. An old register can never be dropped, and hence a new expanded version is always added instead of replacing the old one. I suggest doing the same.
That is a great suggestion. I did see that someone else is already doing some stuff for HA that will not be implemented in the GX so that is also a better solution to survive upgrades if you do a small script on reboot.