Added modbus agent

[DaveBoettger]

Modbus agent should work with most Modbus devices simply by supplying the correct configuration file.
Specifically, this has been tested on the following devices on site: -VLT cooling loop pump controllers
-ELNet power monitors
-DSE 8610mkII generator controllers
Sample configuration files for each device are included.

Description

Motivation and Context

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[BrianJKoopman]

Thanks for the PR @DaveBoettger! A few comments and questions below. Biggest thing I'd say is the docs page. Some unit tests would be great, and I'm happy to help get that started, details in the comments.

[BrianJKoopman]

I don't think we want to package these into the published package on PyPI. For lack of a better place to put them at the moment, can we move them to /examples/configs/modbus/ at the root of the repository?

[DaveBoettger]

Ok, I'm also happy to just eliminate this as I think there will be plenty of real examples in actively used configurations.

[BrianJKoopman]

Thanks for being so thorough with the docstrings! In order to easily view them can you create a docs page for this agent? It should live in docs/agents/modbus_agent.rst. There are many examples in that directory, and also documentation here for creating these pages.

To include the agent in the side bar, the new docs .rst page must be added to the docs/index.rst file, alphabetically, in the "Agent Reference" section.

[BrianJKoopman]

This is great to see! However I noticed that the documented fields here seem to differ from the register names in Generator_Engine_Data.yaml, i.e. 'Engine_oil_pressure' vs 'Oil_pressure'. Is this just a case of one of these two locations being out of date?

This documentation is primarily for the OCS control program writer who needs to reference these keys and might not have access to a running instance of the agent to reverse engineer which keys are available. So these sorts of differences matter here, but I realize it's tedious to keep multiple locations up to date.

There's also a sort of unique issue here in that this agent could be monitoring a different device with different registers, and thus different "fields". I'd like to capture that info here too.

My suggestion would be to include a general structure for the session.data, and describe how it's populated, while pointing to the example configuration files for the details of specific field names and possible value types, etc. Still include things that are always true in the general structure, like the timestamp. Sound good?

[BrianJKoopman]

Two questions here:

1. How does self.error_val get set? It seems right now to always be None. This would run into issues on line 247 with the float() cast, but maybe I'm missing something.
2. Would it make sense to distinguish between values below 'min_val' and values above 'max_val'?

[DaveBoettger]

I agree that the float() cast would be bad with None so I've added a check before the cast to see that it isn't equal to self.error_val. The intent here was just to have something that would work like NaN without adding some other dependency. For now I'd like to leave it as is unless there's a reason not to.

[BrianJKoopman]

This would go above and beyond, but it would be useful to see some examples in the form of some unit tests for the code up to line 156, all the bit register code that doesn't involve actually communicating with a device. There are some docs for how to run the tests here.

The tests would live under socs/tests/agents/. There aren't a lot of examples in there, but you could check out the supersync tests.

Happy to talk more about this too.