Modbus TCP server support

[mheyse]

Hi, I'm very new to the EMS-ESP project (just integrating it into my setup), so please forgive me if I missed something obvious.

This is my idea/feature request: Implement a Modbus server that exposes the EMS bus, in analogy to the existing MQTT and REST interfaces.

This would make interfacing with KNX components more robust because there are out-of-the-box KNX/Modbus gateways (e.g. the Weinzierl "KNX Modbus TCP Gateway 716"). I do have a server that also functions as a MQTT <-> KNX gateway that does the job, but for "crtitical infrastructure" like heating/cooling I prefer not having to rely on a PC/Raspberry/X1 etc.

Thanks for your thoughts!

Best
Michael

[proddy]

We've been thinking for a while about how to do the Modbus TCP (similar to https://husdata.se/docs/h60-manual/modbus-tcp-integrations) and have some of the code already done. It's just difficult to test without something like a Loxone. @bbqkees knows more...

[mheyse]

Please elaborate on the consequences of (2). In the CSV there is for example for both MM100 and MM200 an entity with shortname pumpstatus - both are booleans but have different fullnames, and one is writeable and one is not. So these should be different entities even though they have the same shortname. So I assume that different devices even of the same type have entirely different entity namespaces, so they are completely independent?

I think the cleanest solution (that also represents reality) is to implement multiple Modbus servers - one for each device. eModbus easily supports this without overhead, and the product id could be equal to the Modbus serverId. And then there is a register/entity mapping that's individual for each device. This has the consequence that for example the pumpstatus entity might have different modbus addresses depending on the actual device.

For the different circuits I'd reserve blocks of registers, so for example 8 blocks for hc1...hc8. So each device would first have one register block with common values, followed by one register block for each circuit. I'd reserve some registers in each block for future extensions.

I'd also implement a Modbus server for ems-esp itself returning general information, so essentially the same information that is in the "info" mqtt topic, plus a list of all existing devices and also the installed circuits per device. Can I use ID 1 for this virtual device? This does not seem to be a product id used on the EMS bus.

[mheyse]

I just realized that the different pumpstatus entities are for different tags ("hc*" vs "wwc*") - so entity namespaces should probably be by device type and tag and don't need to be by device. This would imply that e.g. all devices of type "mixer" do have the same set of modbus registers, but some might not be used (for example, the MM100 would not use the "hc*" registers, only the "wwc*" and "dhw" registers).

[edit]: Some entity properties are different for different devices of the same type - most notably the numeric operator is device dependent. But the basic data type is always the same so the number of Modbus registers used is consistent. So the question is:
a) Do we still transmit the unscaled value and leave the interpretation (applying the numeric operator depending on the actual device) to the client? This might be OK because the client addresses the modbus server by the product ID so it knows exactly what to expect in principle.
b) apply the numeric operator in ems-esp and transmit the result, either as a IEEE 754 float or with a "worst case" numeric operator and possibly using more registers for the value
c) transmit the numeric operator in a separate register (this would practically double the number of registers used)

I think (a) is the option causing the least trouble.

[mheyse]

Hi, I just summited draft PR #1618 with a proof-of-concept implementation. I'd appreciate your comments to see if this is heading in the right direction. Thanks!

[proddy]

thanks, I'll take a peek at the PR. As for the lib_deps the reason for having locally stored libs as mainly because we're always tweaking some of them. The ones that are fixed (like ArduinoJson and your emodbus lib) and makes sense to have platformio manage them so absolutely fine if you want to add a lib_deps now.

[mheyse]

Regarding writing data through modbus. I guess the way to go is

• implement a WRITE_HOLD_REGISTER callback
• derive the entity shortname from the modbus register and construct a command path from this shortname (same as the mqtt topic)
• create an input Json Object with the value, hc etc.
• call Command::process

But then a lot of device specific stuff happens in the callback that's eventually executed. So this method does not at all work well with "raw" values (values that do not have the numeric_operator applied). So this method would really need the "final" values with all scale factors already applied.

So we're back at the problem of the data format.

Of course read and write operations need to be symmetric, so if you read unscaled values you also need to write unscaled values. In this case the WRITE_HOLD_REGISTER callback could just apply the scale factor, resulting in a float value, and using that in the JsonObject for Command::process. But I'm a bit worried that we might lose precision with this approach. But if I understand the code correctly, mqtt does the same thing, right? Applying the factor and transmitting the value as a float. So this should be fine I guess?