Generic and configurable modbus meter device support

[cupertinomiranda]

More affordable meter devices usually are not capable to be identified through inspection of it modbus registers, due to lack of specific registers that identify the device, and for that reason are impossible to be supported.
Any solution implies that the user would somehow hand specify the device.

This pull request suggests a solution to this problem by introducing a more configurable meter device, in which the end user/installer can provide the missing information, such as the registers for the paths, etc.

Personally I would love to support this device through the GUI, however and so far I lack the proper knowledge to make such implementation.
The solution for configuration was in the form of a json file, also included in the last commit.

Looking forward for your comments and suggestions on how to properly add such functionality to the project.

[mpvader]

Hi @cupertinomiranda , that is a very nice contribution!

But I have to disappoint you: I've decided to not now include this. We're launching our own energy meter, and together with the other supported energy meters that is already plenty of effort to keep testing and supporting officially.

Perhaps you can make an installable package for this? That way we could also get an idea of the demand cq. interest in this.

Ie something with venus-data.tgz that installs itself on the data partition, and using rcS.local, or the other one, at boot tries to patch the files on the rootfs.

[cupertinomiranda]

Hi @mpvader, thanks for the honesty.
For reference, this device does not really interfere with anything and it would be a superuser feature that might be left in the shade, since the user would still need to define the device in a configuration file.
The reason for contributing this code was really to avoid having to constantly patch dbus-modbus-client every release you do.

I realized recently that there are already way too many projects in /opt/victronenergy that communicate through serial modbus protocol, however each individual brand is implementing their own solution, such as the CG meter support.
This approach sort of makes it hard to use the modbus protocol in a multi branded rs485 network.
Maybe one of the best improvements for stability would be to actually start moving the support for all of the modbus devices to a single service/tool.
Maybe the solution could be to create a project that would centralize all the serial modbus communication and provide the interface to access modbus data. Something like, other tools would register to get modbus information and this single service would communicate with the modbus devices and report back to the individual tools.

Anyway, can you point me out to documentation or an example of such installable package.
I will investigate if it is worth to contribute it in such way.

[mpvader]

Hi @cupertinomiranda ,

For modbus connections, the plan is to have it all in this repo. Meaning also deprecate the cgwacs one.

We don’t have a good example of such installation package, I think. What we do have are the various hooks and scripts around venus-data-*.tgz. See the root access documents for pointers.

How are your bash/shell skills?

The approach I have in mind is:

• have a venus-data-jsonmodbusenergymeter.tgz
• in there have a set of patch files that installs your changes.
• and an install script

What needs to happen on boot and having an sdcard/usb stick with that file on there is:

1. copy all files to somewhere on data partition
2. install rcS.local that calls your install script

install script is (thus) executed on every boot, and it:

1. Calls our resize2fs script
2. Patches the rootfs according the patch files (something that loops through a folder with patch files would be nice?)
3. It does above patching as atomic as possible. Ie it should not be possible to end up with a half patched system. So, either it does a dry run first (but that tests only if patch applies, doesn’t check if diskspace is sufficient..). See problems here for why that is important: https://community.victronenergy.com/questions/240314/venus-os-v32014-available-for-testing.html

good to have there would be a notification to the user in case patching fails.

To have some sort of auto updater, like the Setuphelper from @kwindrem has, is nice and user friendly - it can help to automatically overcome the problems that arise when we changes files in such way that the patch no longer applies. But on the other hand I’d think that suxh thing really is a step two.

[mpvader]

Reason to use rcS.local is to patch the files before the service is started up

[cupertinomiranda]

Hi @mpvader,

For modbus connections, the plan is to have it all in this repo. Meaning also deprecate the cgwacs one.

If I may suggest, why not having a service that abstracts the tty into tcp. And then any serial modbus connections could be done and scanned as if they were tcp modbus.
This approach would unify all modbus implementations.
It can be achieved as well with socat, however in order to search on different baudrates a hand made solution in C would be preferable.
Found this on the web on how to setup socat for this: http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt

We don’t have a good example of such installation package, I think. What we do have are the various hooks and scripts around venus-data-*.tgz. See the root access documents for pointers.

If I understand well, what you recommend would be to patch the code in dbus-modbus-client at boot time? Right?

Personally, I would rather wait or spend some time to unify the modbus tty, perhaps leaving some more room to expand-ability.
When will you release the new meter? Any plans to when you will rework the infrastructure?

How are your bash/shell skills?

They are good. ;-)

[mpvader]

Hi again!

why not having a service that abstracts the tty into tcp.

dbus-modbus-client already works with both tty and tcp connections; what advantage do you see?

We’re quite happy with how this service works. Some more additions are coming and someday perhaps moving to asyncio or similar. But: it works, and we have limited capacity, so not sure when that would be done.

what you recommend would be to patch the code in dbus-modbus-client at boot time? Right?

exactly

when new meter

It is available from stock per today.

Any plans to when you will rework the infrastructure?

what infrastructure?

bash/shell skills

good!

[cupertinomiranda]

dbus-modbus-client already works with both tty and tcp connections; what advantage do you see?

Being able to do my own implementation of a tty based meter device without having to hack dbus-modbus-client.
Please notice that the access to tty should be sort of centralized if you wish to have multi-branded solutions. In my case I have a CG for grid and something else for PV, and if I want to have both on the same tty port, I need to add both in dbus-modbus-client code and disable dbus-cgwacs.

There is currently a race in the access to the tty devices by the multiple implementations, for example between dbus-modbus-client and dbus-cgwacs.

what you recommend would be to patch the code in dbus-modbus-client at boot time? Right?
exactly

I cannot really consider this a proper solution. I would not like my system to depend on this. :-(