Modbus openHAB2 binding available for alpha testing

@alexopenhab

I’m a Carlo Gavazzi retailer so it was my first choice :slight_smile:

I don’t think any error occurs. This is because at modbus protocol level there are no concepts such as int64 or even float32. There are just 16 bit registers (input and holding), 1 bit coils, and 1 bit discrete inputs.

Naturally you would get an configuration error if you try to use unknown valuetypes such “foobar” or “int64”.

So the binding can poll the data just fine. Constructing the number just needs some work as mentioned above. Arithmetic is following similar logic @alexopenhab explains above.

Best
Sami

1 Like

Hi. I use a couple of power-meters all connected by modbus rtu (RS485). They are all conected to a modbus rtu to modbus-tcp converter (not wifi but LAN). This works like a charm :slight_smile:
But i have not converted the modbus.cfg yet (I started with OH 1.6). Do you have already a thing-file with all the registers and would share this?

@aco, that would be specific to everyone’s devices. I doubt that there is anyone created a file holding ALL registers just for ‘fun’ :slight_smile:
As from my personal experience - if you define things file holding all registers and define a poll for that - there is a chance you’re end up in high memory/cpu usage of your server.
…unless you find anyone who has the same device.

Regards

Ofcours you right. I use the same devices as you :grin:

Hi Andreas, can you disclose wiring details for your power meters? I have issue with that, maybe you will be able to help me? Or anyone involved in the topic. :slight_smile:

I’m keen to test binding but so far my devices are disconnected… :confused:

Hi Lukasz. The wiring is standard rs485:2wire_rs485_fig1
Where the Modbus RTU to TCP-Converter ist the master. The config of the converter ist the following:


(Please also add a resistor at the end of the bus (between A and B about 120ohm)

If there is more then one device on the bus make shure that your converter is supporting stacking for the rs485 bus.
In my case I have got a special-firmware from the manufactuer

Hope this help.

I’m using a Pine64 with a USB RS485 adapter cp210x. I’m using OpenJDK 1.8 on a OpenSUSE.
I’ve added openhab user in dialout group, configured serial port with permissions and extra Java directive (EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0") as I did on a PC where everything runs correctly.

But modbus poll on Pine64 reports an error:

2018-01-20 17:16:36.727 [ERROR] [et.wimpi.modbus.net.SerialConnection] - Could not get port identifier, maybe insufficient permissions. gnu.io.NoSuchPortException: null
2018-01-20 17:16:36.728 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - connect try 1/1 error: Could not get port identifier, maybe insufficient permissions. null. Connection SerialConnection@32d4d03b[portName=/dev/ttyUSB0,port=]. Endpoint ModbusSerialSlaveEndpoint@5dc73368[portName=/dev/ttyUSB0]
2018-01-20 17:16:36.730 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - re-connect reached max tries 1, throwing last error: Could not get port identifier, maybe insufficient permissions. null. Connection SerialConnection@32d4d03b[portName=/dev/ttyUSB0,port=]. Endpoint ModbusSerialSlaveEndpoint@5dc73368[portName=/dev/ttyUSB0]
2018-01-20 17:16:36.731 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - Error connecting connection SerialConnection@32d4d03b[portName=/dev/ttyUSB0,port=] for endpoint ModbusSerialSlaveEndpoint@5dc73368[portName=/dev/ttyUSB0]: Could not get port identifier, maybe insufficient permissions. null
2018-01-20 17:16:36.733 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Could not connect to endpoint ModbusSerialSlaveEndpoint@5dc73368[portName=/dev/ttyUSB0] – aborting request ModbusPollerThingHandlerImpl.ModbusPollerReadRequest@6aaf1014[slaveId=3,functionCode=READ_MULTIPLE_REGISTERS,start=0,length=20,maxTries=3] [operation ID 01273a42-3a58-4b0e-824e-e67fa2f5c2b5]

The error happens both with 2.2.0 and 2.3.0 OH versions.

Any idea?

Thanks, Davide

Have you also added openhab user to tty group? Do you have any other software to test the port? One way test if it’s permission issue is to run openhab as root.

Yes, by using mbpoll, I can read registers.

pine64@pine64:~> mbpoll -a 3 -b 19200 -t 4 -r 122 /dev/ttyUSB0
mbpoll 1.2-6 - FieldTalk™ Modbus® Master Simulator
Copyright © 2015 epsilonRT, All rights reserved.
This software is governed by the CeCILL license http://www.cecill.info

Protocol configuration: Modbus RTU
Slave configuration…: address = [3]
start reference = 122, count = 1
Communication…: /dev/ttyUSB0, 19200-8E1
t/o 1.00 s, poll rate 1000 ms
Data type…: 16-bit register, output (holding) register table

– Polling slave 3… Ctrl-C to stop)
[122]: 196
– Polling slave 3… Ctrl-C to stop)
[122]: 196
^C— /dev/ttyUSB0 poll statistics —
2 frames transmitted, 2 received, 0 errors, 0.0% frame loss

Coult it be a JVM problem?

Davide

I get the same error also running OH as root.

Davide

Are you running 32bit or 64bit java? Some google answers told that serial connections don’t work at all with 64bit. Another one said that there known problems with openhab and openJDK. Might be worth changing to zulu java. As a sidenote I’m running openhab on debian 8 with zulu java 32bit and serial connections works just fine.

1 Like

Have you checked the setup guide?

Specifically, the “serial port configuration” section in the docs, which links to Port configuration notes of serial binding.

Seems that dialout group is of relevance.

But since you get issues even as root user, I doubt those instructions help. Perhaps worth trying out steps from @gitMiguel?

Having some issues migrating to openHAB 2 binding. Part of my modbus 1x config is:

tcp.basement.connection=10.88.64.46:502:0:600000:0:0:50
tcp.basement.length=55
tcp.basement.type=coil

tcp.basement_ponet.connection=10.88.64.46:502:0:600000:0:0:50
tcp.basement_ponet.start=2072
tcp.basement_ponet.length=8
tcp.basement_ponet.type=coil

Is this the same config for modbus 2x?

Bridge modbus:tcp:basement [ host="10.88.64.46", port=502, id=3 ] {
  Bridge poller coils [ start=0, length=55, refresh=1000, type="coil" ] {
    Thing data pin01 [ readStart="0", readValueType="bit", writeStart="0", writeValueType="bit", writeType="coil" ]
    Thing data pin02 [ readStart="1", readValueType="bit", writeStart="1", writeValueType="bit", writeType="coil" ]
    Thing data pin03 [ readStart="2", readValueType="bit", writeStart="2", writeValueType="bit", writeType="coil" ]
    Thing data pin04 [ readStart="3", readValueType="bit", writeStart="3", writeValueType="bit", writeType="coil" ]
    Thing data pin05 [ readStart="4", readValueType="bit", writeStart="4", writeValueType="bit", writeType="coil" ]
    Thing data pin06 [ readStart="5", readValueType="bit", writeStart="5", writeValueType="bit", writeType="coil" ]
    Thing data pin07 [ readStart="6", readValueType="bit", writeStart="6", writeValueType="bit", writeType="coil" ]
    Thing data pin08 [ readStart="7", readValueType="bit", writeStart="7", writeValueType="bit", writeType="coil" ]
    Thing data pin09 [ readStart="8", readValueType="bit", writeStart="8", writeValueType="bit", writeType="coil" ]
    Thing data pin10 [ readStart="9", readValueType="bit", writeStart="9", writeValueType="bit", writeType="coil" ]
    Thing data pin11 [ readStart="10", readValueType="bit", writeStart="10", writeValueType="bit", writeType="coil" ]
    Thing data pin12 [ readStart="11", readValueType="bit", writeStart="11", writeValueType="bit", writeType="coil" ]
    Thing data pin13 [ readStart="12", readValueType="bit", writeStart="13", writeValueType="bit", writeType="coil" ]
    Thing data pin14 [ readStart="13", readValueType="bit", writeStart="14", writeValueType="bit", writeType="coil" ]
    Thing data pin15 [ readStart="14", readValueType="bit", writeStart="14", writeValueType="bit", writeType="coil" ]
    Thing data pin16 [ readStart="15", readValueType="bit", writeStart="15", writeValueType="bit", writeType="coil" ]
    Thing data pin17 [ readStart="16", readValueType="bit", writeStart="16", writeValueType="bit", writeType="coil" ]
    Thing data pin18 [ readStart="17", readValueType="bit", writeStart="17", writeValueType="bit", writeType="coil" ]
    Thing data pin19 [ readStart="18", readValueType="bit", writeStart="18", writeValueType="bit", writeType="coil" ]
    Thing data pin20 [ readStart="19", readValueType="bit", writeStart="19", writeValueType="bit", writeType="coil" ]
    Thing data pin21 [ readStart="20", readValueType="bit", writeStart="20", writeValueType="bit", writeType="coil" ]
    Thing data pin22 [ readStart="21", readValueType="bit", writeStart="21", writeValueType="bit", writeType="coil" ]
    Thing data pin23 [ readStart="22", readValueType="bit", writeStart="22", writeValueType="bit", writeType="coil" ]
    Thing data pin24 [ readStart="23", readValueType="bit", writeStart="23", writeValueType="bit", writeType="coil" ]
    Thing data pin25 [ readStart="24", readValueType="bit", writeStart="24", writeValueType="bit", writeType="coil" ]
  }
  Bridge poller ponet [ start=2072, length=8, refresh=1000, type="coil" ] {
    Thing data pin01 [ readStart="2072", readValueType="bit", writeStart="2072", writeValueType="bit", writeType="coil" ]
    Thing data pin02 [ readStart="2073", readValueType="bit", writeStart="2073", writeValueType="bit", writeType="coil" ]
    Thing data pin03 [ readStart="2074", readValueType="bit", writeStart="2074", writeValueType="bit", writeType="coil" ]
    Thing data pin04 [ readStart="2075", readValueType="bit", writeStart="2075", writeValueType="bit", writeType="coil" ]
    Thing data pin05 [ readStart="2076", readValueType="bit", writeStart="2076", writeValueType="bit", writeType="coil" ]
    Thing data pin06 [ readStart="2077", readValueType="bit", writeStart="2077", writeValueType="bit", writeType="coil" ]
    Thing data pin07 [ readStart="2078", readValueType="bit", writeStart="2078", writeValueType="bit", writeType="coil" ]
    Thing data pin08 [ readStart="2079", readValueType="bit", writeStart="2079", writeValueType="bit", writeType="coil" ]
  }
}
1 Like

@ssalonen you made an excellent work relivering simple binding configuration for low level thing such modbus.

I made my attempt with binding today and I’ve spotted some behaviours which are unclear to me and maybe you will be able to clarify if its intended. I connect using modbus tcp - link itself is fine and I see proper answers coming back in wireshark.

My device have bunch of registrars which I explorer one by one to make sure that I parse values correctly. Some of registrars are repeated - as it is three phase power meeter. Values are encoded as float and they are read properly.

Below is my basic configuration

    Bridge poller L1voltage [start=8200, length=2, refresh=1000, maxTries=1, type="holding" ] {
        Thing data voltage [ readStart="8200", readValueType="float32" ]
    }
    Bridge poller L2voltage [start=8204, length=2, refresh=1000, type="holding" ] {
        Thing data voltage [ readStart="8204", readValueType="float32" ]
    }
    Bridge poller L3voltage [start=8208, length=2, refresh=1000, type="holding" ] {
        Thing data voltage [ readStart="8208", readValueType="float32" ]
    }

Values are not updated. On trace logging level I’ve got following messages:

Could not transform item state '235.1999969482422' (of type DecimalType) to a State (tried the following types: [class org.eclipse.smarthome.core.library.types.DateTimeType, class org.eclipse.smarthome.core.types.UnDefType])! Input state as string '235.1999969482422', transformed string '235.1999969482422', transformation 'default'
Thing modbus:data:pro380:L1voltage:voltage 'Modbus data', channel modbus:data:pro380:L1voltage:voltage:datetime will not be updated since transformation was unsuccesful
transformed response is '235.1999969482422'

I also attempted to group by reads together, but registers are not continuous thus below configuration doesn’t work:

     Bridge poller voltage [start=8200, length=10, refresh=1000, type="holding" ] {
         Thing data L1 [ readStart="8200", readValueType="float32" ]
         Thing data L2 [ readStart="8204", readValueType="float32" ]
         Thing data L3 [ readStart="8208", readValueType="float32" ]
     }

Cheers,
Lukasz

1 Like

I am working on moving from 1.x binding, and I see something similar.

24-Jan-2018 20:53:39.581 [DEBUG] [org.openhab.binding.modbus.internal.Transformation] - transformed response is '0'
24-Jan-2018 20:53:39.581 [DEBUG] [org.openhab.binding.modbus.internal.Transformation] - Transformed item state '0' (of type DecimalType) to a state 0 (of type StringType). Input state as string '0', transformed string '0', transformation 'default'
24-Jan-2018 20:53:39.582 [DEBUG] [org.openhab.binding.modbus.internal.Transformation] - transformed response is '0'
24-Jan-2018 20:53:39.582 [DEBUG] [org.openhab.binding.modbus.internal.Transformation] - Transformed item state '0' (of type DecimalType) to a state 0 (of type PercentType). Input state as string '0', transformed string '0', transformation 'default'
24-Jan-2018 20:53:39.582 [DEBUG] [org.openhab.binding.modbus.internal.Transformation] - transformed response is '0'
24-Jan-2018 20:53:39.582 [DEBUG] [org.openhab.binding.modbus.internal.Transformation] - Transformed item state '0' (of type DecimalType) to a state 0 (of type DecimalType). Input state as string '0', transformed string '0', transformation 'default'
24-Jan-2018 20:53:39.582 [DEBUG] [org.openhab.binding.modbus.internal.Transformation] - transformed response is '0'
24-Jan-2018 20:53:39.583 [DEBUG] [org.openhab.binding.modbus.internal.Transformation] - Could not transform item state '0' (of type DecimalType) to a State (tried the following types: [class org.eclipse.smarthome.core.library.types.DateTimeType, class org.eclipse.smarthome.core.types.UnDefType])! Input state as string '0', transformed string '0', transformation 'default'
24-Jan-2018 20:53:39.583 [DEBUG] [nhab.binding.modbus.handler.ModbusDataThingHandler] - Thing modbus:data:second:ponet:05 'Modbus data', channel modbus:data:second:ponet:05:datetime will not be updated since transformation was unsuccesful
1 Like

This is something that is normal, and thus I have been using DEBUG logging. Number zero does not get converted to date/time (channel called datetime).

Nothing to worry about if you are not using that specific thing channel.

For now all channels are updated (or at least tried), no matter whether there is Item linked to them or not.

As mentioned above, the log statement is about channel datetime:

channel modbus:data:pro380:L1voltage:voltage:datetime will not be updated since transformation was unsuccesful
transformed response is ‘235.1999969482422’

There will also log messages for successfull reads, with TRACE level at least (code here). The channels of the data thing reveal last successful read and error as well.

What is the status of the things, is it OK?

I don’t understands the statement:

Values are encoded as float and they are read properly.
Values are not updated.

Are you saying that initial values are acquired correctly but changes are not?

@sipvoip

For the most part it looks similar to me. You are missing advanced connection settings (...connection=10.88.64.46:502:0:600000:0:0:50) from the openHAB2 configuration. Splitting it into parts:

  • 0: interTransactionDelayMillis. Corresponds to timeBetweenTransactionsMillis in the new binding (tcp thing).
  • 600000: reconnectAfterMillis. Corresponds to reconnectAfterMillis in the new binding (tcp thing).
  • 0: interConnectDelayMillis. Corresponds to timeBetweenReconnectMillis in the new binding (tcp thing).
  • 0: connectMaxTries. Corresponds to connectMaxTries in the new binding. Should be >= 1 (tcp thing).
  • 50: connectTimeout. Corresponds to connectTimeoutMillis in the new binding (tcp thing).

Furthermore, 1.x binding allows great deal of configuration at item level as well – so that might matter for some configurations.

What kind of issues are you having?

Hi, I went over my configuration again and I misstyped mappnig from item to channel - that’s why updates were not propagated to item states.

Second issue I’ve got with reading multiple coils turned out to be catalog card bug - registers described in document do not match these returned by device. After adjustments everything seems ok. Card specifies registers 8200, 8204, 8208 (2008, 200C, 2010 in hex) while device returns values in registers 8200, 8202, 8204.
When I was trying to read values as specified in documentation registers didn’t match.

Everything looks good so far.
Once again, thanks for excellent work!

Cheers,
Lukasz

1 Like