The Modbus Schema Toolkit

Summary

This set of Kotlin/Java libraries and tools to read data from Modbus devices like Electricity Meters, Solar Inverters and Heat pumps.

This toolkit mainly consist of the following components:

A generic definition language for creating a modbus mapping (a Modbus Schema).
- i.e. translate binary values to meaningful values
A Kotlin/Java 11 (JVM only) library that uses this mapping definition to optimize the retrieval of the underlying data and provide the desired meaningful values.
A collection ready to run schemas (all the devices I have…):
- Eastron SDM 630 Electricity Meter
- Thermia Genesis Heatpump
- SunSpec compliant devices.

Intended as an open mapping standard

The way the mapping is defined is an open format and can be reimplemented into any programming language by anyone.

This is not a modbus implementation!

This toolkit relies on existing libraries to do the actually Modbus data transfer. Connectors to multiple modbus implementations have been included.

Runs on a Raspberry PI 3 !

I have this running in a very simple Kotlin Script on a Raspberry PI 3 (yes, that old). It fetches the data, converts it into useful values and puts these into a time series database every second.

Main differences

The main features that the existing Modbus libraries (I have found) not have:

A generic way of mapping registers to values which allows for the kind of expressions you see in SunSpec.
- Most libraries only return the binary values, some allow basic single value mapping (like Apache Plc4x).
Full support for SunSpec using the official SunSpec definitions.
An optimizer that
- automatically calculates the minimal number of modbus requests for the collection of Fields (= meaningful value)
- automatically optimizes around read errors
- automatically skips the Fields that have been retrieved and do not need to be retrieved again (immutable/read error)
A maven plugin to convert a Modbus Schema into code.
- The intent is for it to be possible into any language, Kotlin and Java have been included.

Known limitations/Problems/Bugs

Things I will NOT change/fix:

It is READ ONLY. So NO writing.
- I will not change that because I consider that too much of a risk.

Things I intend to build/fix:

Support for Coils and Discrete Inputs (Only Registers right now).
I want to have an API gateway that speaks GraphQL and can connect to any Modbus device you have the schema for.