Modbus types - coils and signed int

English Forum
1

Hi all, thank you in advance for your support.

I am working my way through implementing a new type of device as an api and have the following questions to the ModbusType (openems/io.openems.edge.common/src/io/openems/edge/common/modbusslave/ModbusType.java).

I will be reading values of both types “coil” and “int16” from the modbus, but I struggle with the correct mapping into the available ModbusType.

For now I map the coil into “UINT16” - but would prefer a BOOL type.

I could map the signed integer values into “float”

My question is really: Why are neither signed integer or bool implemented in the ModbusType.java?

Regards
Jens

2

Hi jens,

as far as my Understanding is that the Modbus Reads are not inherited from the ModbusType as openEMS uses the common only for returning Modbus Addresses using the common.

If you read Addresses from a Device one uses this:

io.openems.edge.bridge.modbus.api.element class…

Greetings

3

Hi Sn0w3y

Thank you for the fast reply.

Maybe I jumped a bit to fast into things - and possible somewhat above my current skill level. The background:

I am aiming at implementing some new devices (heat pumps, boilers, intelligent valves etc.) into the mixture that does not fit well into the existing list of “nature” elements. So, from what I was able to figure out, I could just add some new “nature” types as bnd api projects and then include these in an implementation. Is this far off or possibly the longest detour? Advise are highly appreciated.

I can see in some of the other implementations (i randomly picked the BMW battery) how modbus values are converted on the implementation into the types I am asking - but still wondering why int and bool are not in the ModbusType. And derived from this; the sensible approach forward.

Regards

4

Maybe better if you start here to get an Understanding:

https://openems.github.io/openems.io/openems/latest/edge/implement.html

Greetings !

5

Yes, I did this. It was a great intro - but I draw the conclusion that i would need a replacement to this

import io.openems.edge.meter.api.MeterType;

like

import io.openems.edge.myHeatPump.api

My physical hardware does not share much functionality with any of the “nature” components on the list: https://openems.github.io/openems.io/openems/latest/edge/nature.html

6

Well even then you do not need the common for Modbus Tasks.

You need to use the modbus Bridge for the Elements:

io.openems.edge.bridge.modbus.api.element

Maybe also have a look in here:

/io.openems.edge.meter.bcontrol.em300

7

Good advice, thank you.

I will do an implementation of my devices on the modbus bridge and skipping the “nature” api.

1 Like
8

The ModbusType.java file your found is only used in the ModbusSlave context, i.e. when an external system is accessing data from OpenEMS via Modbus.

What you are looking for is called SignedWordElement in OpenEMS.

I am randomly choosing the FENECON Pro 9-12 ESS implementation for following examples:

  • This maps seven coils of the register 113 to individual Boolean- or State-Channel. (The difference is, that StateChannels have also a level assigned to them. If e.g. STATE_1 is true below, a global INFO state is set).
m(new BitsWordElement(113, this) //
		.bit(0, FeneconProEss.ChannelId.STATE_0) //
		.bit(1, FeneconProEss.ChannelId.STATE_1) //
		.bit(2, FeneconProEss.ChannelId.STATE_2) //
		.bit(3, FeneconProEss.ChannelId.STATE_3) //
		.bit(4, FeneconProEss.ChannelId.STATE_4) //
		.bit(5, FeneconProEss.ChannelId.STATE_5) //
		.bit(6, FeneconProEss.ChannelId.STATE_6)), //
  • This maps the register 124 to the ACTIVE_POWER_L1 Channel:
m(AsymmetricEss.ChannelId.ACTIVE_POWER_L1, new SignedWordElement(124)), //

OpenEMS Natures really only become useful, when you standardize or abstrahize different devices and you want to use e.g. one Controller with different devices. If you are just starting and there is no good match existing, you can just leave it out for now.

If you plan to read and visualize the consumed power of the heat pumps, boilers, etc. you could consider implementing ElectrictyMeter. This gives you immediate compatibility with OpenEMS UI.

Regards & welcome to the OpenEMS Community,
Stefan

1 Like
9

Hi Stefan

Thank you for the welcome and contributing to my understanding of the project.

This is the future usecase I am working towards:

For the time being, I will use the Modbus Bridge approach recommended by @Sn0w3y while growing my understanding for the project.

Best regards
Jens

1 Like