Modbus openHAB2 binding available for alpha testing

That was my obvious choice, but gave me Err instead of 0 or 1
And here is the log:

Exception while formatting value 'OFF' of item ModbusTest2 with format '%.0f'

Seems like openHAB2 handles labels differently than openHAB1, you can use [] to make it work (updated the above example).

That works, thank you.
One more question - I see some errors in the log and believe that could be cured by adjusting timers. Any recommendations? With syntax example please :wink:

[ERROR] [wimpi.modbus.io.ModbusTCPTransaction] - execute try 1/3 error: I/O exception - failed to read.. Request: net.wimpi.modbus.msg.ReadCoilsRequest@3b66a3b9 (unit id 2 & transaction 5830). Address: /192.168.5.239:502

Not sure, the underlying socket returns EOF – perhaps the physical slave is not able to respond as fast or something similar. You can try to lower the poll rate.

All right @FredericMa, investigated the logs a bit.

The “null endpoint” seems to be the most critical – I now applied a fix for that. Fix should be now out from the usual location.

Could you please try with that version and see if that fixes the issues for you.


There were also some read errors, some comments below

Transmit Echo not received

[ERROR] [impi.modbus.io.ModbusSerialTransport] - Transmit Echo not received

I think this means that the modbus library tries to read the “echo” message, since you have specified echo parameter in serial connection as true. From the logs you can see that echo is not there at all – perhaps you want to disable the echo?

exact log messages:

017-08-23 10:08:52.145 [TRACE] [rt.modbus.internal.ModbusManagerImpl] - borrowing connection (got Optional[SerialConnection@1ad9f9e[portName=/dev/ttyUSB0,port=/dev/ttyUSB0]]) for endpoint ModbusSerialSlaveEndpoint@112b8a1[portName=/dev/ttyUSB0] took 701 ms
2017-08-23 10:08:52.147 [TRACE] [rt.modbus.internal.ModbusManagerImpl] - Executing task PollTaskImpl@1d12d97[request=ModbusPollerThingHandlerImpl.ModbusPollerReadRequest@b0f51c[slaveId=11,functionCode=READ_MULTIPLE_REGISTERS,start=4060,length=1],endpoint=ModbusSerialSlaveEndpoint@112b8a1[portName=/dev/ttyUSB0],callback=org.openhab.binding.modbus.handler.ModbusPollerThingHandlerImpl$ReadCallbackDelegator@96fdca40] (oneOff=false)! Connection received in 704 ms
2017-08-23 10:08:52.263 [DEBUG] [t.wimpi.modbus.io.ModbusRTUTransport] - Sent: 0b 03 0f dc 00 01 46 4e 
2017-08-23 10:08:53.782 [DEBUG] [impi.modbus.io.ModbusSerialTransport] - Echo: 0b 83 04 60 f1 
2017-08-23 10:08:53.784 [ERROR] [impi.modbus.io.ModbusSerialTransport] - Transmit Echo not received
2017-08-23 10:08:53.789 [ERROR] [pi.modbus.io.ModbusSerialTransaction] - execute try 1/3 error: I/O failed to write. Request: net.wimpi.modbus.msg.ReadMultipleRegistersRequest@12ae47b (unit id 11 & transaction 1). Serial parameters: SerialParameters@190c70b[portName=/dev/ttyUSB0,baudRate=9600,flowControlIn=xon/xoff in,flowControlOut=xon/xoff out,databits=8,stopbits=1,parity=even,encoding=rtu,echo=true,receiveTimeoutMillis=1500]
2017-08-23 10:08:53.842 [DEBUG] [t.wimpi.modbus.io.ModbusRTUTransport] - Sent: 0b 03 0f dc 00 01 46 4e 
2017-08-23 10:08:55.382 [DEBUG] [impi.modbus.io.ModbusSerialTransport] - Echo: 0b 83 04 60 f1 
2017-08-23 10:08:55.384 [ERROR] [impi.modbus.io.ModbusSerialTransport] - Transmit Echo not received
...
snipping other retries
...
2017-08-23 10:08:56.987 [ERROR] [pi.modbus.io.ModbusSerialTransaction] - execute reached max tries 3, throwing last error: I/O failed to write. Request: net.wimpi.modbus.msg.ReadMultipleRegistersRequest@12ae47b (unit id 11 & transaction 3). Serial parameters: SerialParameters@190c70b[portName=/dev/ttyUSB0,baudRate=9600,flowControlIn=xon/xoff in,flowControlOut=xon/xoff out,databits=8,stopbits=1,parity=even,encoding=rtu,echo=true,receiveTimeoutMillis=1500]

CRC Error in received frame

CRC error thust discarding the messages, might be related to “echo” issue above as well.


2017-08-23 10:08:57.170 [TRACE] [rt.modbus.internal.ModbusManagerImpl] - Executing task PollTaskImpl@c46f14[request=ModbusPollerThingHandlerImpl.ModbusPollerReadRequest@1828679[slaveId=11,functionCode=READ_MULTIPLE_REGISTERS,start=4036,length=9],endpoint=ModbusSerialSlaveEndpoint@112b8a1[portName=/dev/ttyUSB0],callback=org.openhab.binding.modbus.handler.ModbusPollerThingHandlerImpl$ReadCallbackDelegator@b573dd14] (oneOff=false)! Connection received in 5451 ms
2017-08-23 10:08:57.192 [DEBUG] [t.wimpi.modbus.io.ModbusRTUTransport] - Sent: 0b 03 0f c4 00 09 c7 8f 
2017-08-23 10:08:57.213 [DEBUG] [impi.modbus.io.ModbusSerialTransport] - Echo: 0b 03 12 00 01 00 00 00
2017-08-23 10:08:57.217 [TRACE] [t.wimpi.modbus.io.ModbusRTUTransport] - Managed to read at least one byte
2017-08-23 10:08:57.235 [DEBUG] [t.wimpi.modbus.io.ModbusRTUTransport] - Response: 00 00 
2017-08-23 10:08:57.238 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - Last request: 0b 03 0f c4 00 09 c7 8f
2017-08-23 10:08:57.239 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - failed to read: CRC Error in received frame: 0 bytes: 
2017-08-23 10:08:57.242 [ERROR] [pi.modbus.io.ModbusSerialTransaction] - execute try 1/3 error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadMultipleRegistersRequest@1623f3f (unit id 11 & transaction 4). Serial parameters: SerialParameters@190c70b[portName=/dev/ttyUSB0,baudRate=9600,flowControlIn=xon/xoff in,flowControlOut=xon/xoff out,databits=8,stopbits=1,parity=even,encoding=rtu,echo=true,receiveTimeoutMillis=1500]
2017-08-23 10:08:57.280 [DEBUG] [t.wimpi.modbus.io.ModbusRTUTransport] - Clear input: 00 00 00 00 00 00 01 00 01 00 00 65 b8
2017-08-23 10:08:57.302 [DEBUG] [t.wimpi.modbus.io.ModbusRTUTransport] - Sent: 0b 03 0f c4 00 09 c7 8f 
2017-08-23 10:08:57.309 [DEBUG] [impi.modbus.io.ModbusSerialTransport] - Echo: 0b 03 12 00 01 00 00 00
2017-08-23 10:08:57.312 [TRACE] [t.wimpi.modbus.io.ModbusRTUTransport] - Managed to read at least one byte
2017-08-23 10:08:57.313 [DEBUG] [t.wimpi.modbus.io.ModbusRTUTransport] - Response: 00 00 
2017-08-23 10:08:57.315 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - Last request: 0b 03 0f c4 00 09 c7 8f
2017-08-23 10:08:57.317 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - failed to read: CRC Error in received frame: 0 bytes: 
...
snipping other retries
...
2017-08-23 10:08:57.402 [ERROR] [pi.modbus.io.ModbusSerialTransaction] - execute reached max tries 3, throwing last error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadMultipleRegistersRequest@1623f3f (unit id 11 & transaction 6). Serial parameters: SerialParameters@190c70b[portName=/dev/ttyUSB0,baudRate=9600,flowControlIn=xon/xoff in,flowControlOut=xon/xoff out,databits=8,stopbits=1,parity=even,encoding=rtu,echo=true,receiveTimeoutMillis=1500]
2017-08-23 10:08:57.404 [ERROR] [rt.modbus.internal.ModbusManagerImpl] - Error when executing read request

Thanks @rossko57, @AndrewZ and @mbs38 on comments regarding the configuration complexity.

Indeed that is a valid concern. As we are discussing a low level protocol with no “thing” discovery, I tend to agree with @rossko57 that ultimately user should be able to decide what kind of modbus requests the software is executing. Otherwise the binding developer has made the decision for the user, and in the worst case ending up with non-working config.

For example, we have seen so many “exotic” modbus devices (as @rossko57 said) in these forums, that any automatic “combination” of requests is error prone I think.

One of the other design criterias was not to reduce functionality compared to older binding (I think we have managed with this pretty well – although some limitations are there, as discussed in this thread). For example, with the openhab1 binding, one can configure Rollershutter “device” without any rules, ultimately represented by a single thing. Yes, there are additional “helper” things to make it happen but I think that’s a necessary compromise (see more discussion below).

If we would decide to leave the modbus binding with simple IO functionality (just supporting number items for example with no transformations), much of the binding complexity could be reduced. Naturally, the complexity would be introduced in the form of “proxy items” and rules.

For example of more complex example, rollershutter example from openhab1

modbus.things

Bridge modbus:tcp:endpointTCP [ host="127.0.0.1", port=502, id=2 ] {

    Bridge poller holding [ start=0, length=4, refresh=500, type="holding" ] {
        Bridge readwrite LivingRoomRollershutter { 
            // Roller shutter position is read from register 0
            Thing read readPosition [ start=0, valueType="int16" ]
            
            // UP(=1)/DOWN(=-1) commands are written to register 1
            Thing write writeUp [ start=1, trigger="UP", transform="1", valueType="int16", type="holding" ]
            Thing write writeDown [ start=1, trigger="DOWN", transform="-1", valueType="int16", type="holding" ]
            
            // MOVE(=1)/STOP(=0) commands are written to register 2
            Thing write writeMove [ start=2, trigger="MOVE", transform="1", valueType="int16", type="holding" ]
            Thing write writeStop [ start=2, trigger="STOP", transform="0", valueType="int16", type="holding" ]
        }

}

Here the item would be

Rollershutter RollershutterLivingRoomPosition "Roller shutter position [%.1f]" <temperature> {channel="modbus:readwrite:endpointTCP:holding:LivingRoomRollershutter:rollershutter"}

and sitemap same as in old version (see the link).

You can compare this to the openhab1 version (rows added for clarity) and see the analogy.

Rollershutter RollershutterItem "Roller shutter position [%.1f]" 
  <temperature> {modbus="<[slave1:0],
            >[slave1:1:trigger=UP,transformation=1],
            >[slave1:1:trigger=DOWN,transformation=-1],
            >[slave1:2:trigger=MOVE,transformation=1],
            >[slave1:2:trigger=STOP,transformation=0]"}

A bit unfortunately, we have had quite many cases requiring this kind of functionality (see the thread and linked threads).

We could support the “cryptical” item configuration pattern above and thus there would be no need for read and write things, just the readwrite. However, we then would lose the UI configuration possibilities and it’s easy to make typoes.

We could combine some things though: Say we would combine poller and endpoint things. Since we have different parameters for serial and tcp endpoints, we would have to introduce “tcp-poller” and “serial-poller”. In case of many “pollers” (e.g. user wants to poll coils and holding registers), one would have to carefully copy-paste the endpoint information (e.g. ip address and other relevant settings). The current design tries to be “orthogonal” and as such no information is repeated.

One thing that I would like to mention is that I do have a concern that we are inventing something here that is quite different from the other bindings. As said in this thread, I found no other as low level protocols supports as openHAB2 addons yet to take example from. For example, there has been quite long discussions with KNX and MQTT bindings – there are no easy/natural thing hierachy there.

Nevertheless, if the outcome feels like super-complex and hard to understand we have work to do. I hope that with clear examples and proper documentation this can be remedied…

What do you think? Does this make sense at all?

EDIT: managed to get rid of the mapping in the example by using rolleshutter channel instead of number channel.

@ssalonen where I can download the current .jar directly? I believe that the market version is not always up to date, right?

I’m stuck with the errors like the one quoted below :cry:

Exception occurred while calling thing updated at ThingHandler 'org.openhab.binding.modbus.handler.ModbusTcpThingHandler@263c4781': java.lang.NullPointerException

Hi,
marketplace should be up-to-date – perhaps I introduced some new issue?

When in doubt with the marketplace, you can check the timestamp from the download link in market place:

For your convenience, here are the links to folders with jars

The error message does not help much without more comprehensive log with stack trace.

EDIT: tried reproducing the issue you are experienced and managed to get it. It was an regression in the latest change today. Try with the latest version (27-Aug-2017 16:13 UTC or newer) please

One issue less, thanks @ssalonen
one issue more:

[WARN ] [dbus.handler.ModbusWriteThingHandler] - Cannot process command REFRESH with channel modbus:write:endpointTCP:coils:DO2:writeTCP:number since command is not OnOffType, OpenClosedType or Decimal trying to write to coil. Do not know how to convert to 0/1

Edit: that disappeared after restart

Previously that crashed, now it is logged. You can safely ignore that, REFRESH command is not yet supported.

Openhab itself sends these commands on startup, in order to ensure that data is refreshed from the physical device.

not sure what is the cause, but now I see this on startup: https://pastebin.com/2j3FZ0YE

Edit: after restart see the earlier REFRESH error. Weird.

@AndrewZ thanks for reporting these, really appreciate the effort!

I tried something to fix the error you pasted, not sure really what’s happening exactly. Please try again with the new version (2017-08-28 16:23 UTC or later)

Also removed the warning message from ModbusWriteThingHandler related to REFRESH command. Is this what you referred to with REFRESH error?

Best

@ssalonen yes, you understand me :wink:
Updated and see no more errors on restart(s). Thank you!

1 Like

Hi @ssalonen,

Thanks for your reply and the fix!
This seems to fix the issue on that setup. I also disabled the echo.

Thanks a lot!

Hi @ssalonen,

While the issue has been fixed on my raspberry pi which is directly connected to the USB -> RS485.
I’m now trying to connect to the RS485 converter from my production machine (Windows machine) via a virtual serial port. It is working with the v1 modbus binding but when using the openHAB2 binding I get the following error(s):

2017-08-31 13:25:15.088 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'modbus.things'
2017-08-31 13:25:15.089 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'modbus.things' is either empty or cannot be parsed correctly!
2017-08-31 13:25:15.101 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'modbus.things'
2017-08-31 13:25:15.110 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while calling thing updated at ThingHandler 'org.openhab.binding.modbus.handler.ModbusSerialThingHandler@56df802f': java.lang.NullPointerException
java.util.concurrent.ExecutionException: java.lang.NullPointerException
	at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]
	at java.util.concurrent.FutureTask.get(FutureTask.java:206) ~[?:?]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:194) ~[?:?]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:83) ~[?:?]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:67) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.ThingManager.thingUpdated(ThingManager.java:524) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.notifyTrackers(ThingRegistryImpl.java:209) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.notifyListenersAboutUpdatedElement(ThingRegistryImpl.java:132) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.notifyListenersAboutUpdatedElement(ThingRegistryImpl.java:1) ~[?:?]
	at org.eclipse.smarthome.core.common.registry.AbstractRegistry.updated(AbstractRegistry.java:181) ~[?:?]
	at org.eclipse.smarthome.core.common.registry.AbstractRegistry.updated(AbstractRegistry.java:1) ~[?:?]
	at org.eclipse.smarthome.core.common.registry.AbstractProvider.notifyListeners(AbstractProvider.java:57) ~[?:?]
	at org.eclipse.smarthome.core.common.registry.AbstractProvider.notifyListenersAboutUpdatedElement(AbstractProvider.java:81) ~[?:?]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.lambda$21(GenericThingProvider.java:1018) ~[?:?]
	at java.util.ArrayList.forEach(ArrayList.java:1249) ~[?:?]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.createThingsFromModelForThingHandlerFactory(GenericThingProvider.java:1027) ~[?:?]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.lambda$3(GenericThingProvider.java:298) ~[?:?]
	at java.lang.Iterable.forEach(Iterable.java:75) [?:?]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.createThingsFromModel(GenericThingProvider.java:300) [133:org.eclipse.smarthome.model.thing:0.9.0.201708041325]
	at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.modelChanged(GenericThingProvider.java:814) [133:org.eclipse.smarthome.model.thing:0.9.0.201708041325]
	at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.notifyListeners(ModelRepositoryImpl.java:287) [122:org.eclipse.smarthome.model.core:0.9.0.201708041325]
	at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.addOrRefreshModel(ModelRepositoryImpl.java:120) [122:org.eclipse.smarthome.model.core:0.9.0.201708041325]
	at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.checkFile(FolderObserver.java:234) [122:org.eclipse.smarthome.model.core:0.9.0.201708041325]
	at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.processWatchEvent(FolderObserver.java:297) [122:org.eclipse.smarthome.model.core:0.9.0.201708041325]
	at org.eclipse.smarthome.core.service.WatchQueueReader.run(WatchQueueReader.java:204) [98:org.eclipse.smarthome.core:0.9.0.201708041325]
	at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.lang.NullPointerException
	at org.openhab.binding.modbus.handler.ModbusSerialThingHandler.initialize(ModbusSerialThingHandler.java:60) ~[?:?]
	at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.thingUpdated(BaseThingHandler.java:193) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.ThingManager$6.call(ThingManager.java:528) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.ThingManager$6.call(ThingManager.java:1) ~[?:?]
	at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:181) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[?:?]
	... 1 more
2017-08-31 13:25:15.120 [DEBUG] [handler.ModbusPollerThingHandlerImpl] - Bridge not initialized fully (no endpoint) -- aborting init for org.openhab.binding.modbus.handler.ModbusPollerThingHandlerImpl@16274ee8
2017-08-31 13:25:15.122 [DEBUG] [odbus.handler.ModbusReadThingHandler] - ReadWrite bridge 'Modbus read-write definition' of ReadThing 'Modbus read definition' is offline. Aborting config validation
2017-08-31 13:25:15.122 [DEBUG] [odbus.handler.ModbusReadThingHandler] - ReadWrite bridge 'Modbus read-write definition' of ReadThing 'Modbus read definition' is offline. Aborting config validation
2017-08-31 13:25:15.123 [DEBUG] [odbus.handler.ModbusReadThingHandler] - ReadWrite bridge 'Modbus read-write definition' of ReadThing 'Modbus read definition' is offline. Aborting config validation
2017-08-31 13:25:15.124 [DEBUG] [odbus.handler.ModbusReadThingHandler] - ReadWrite bridge 'Modbus read-write definition' of ReadThing 'Modbus read definition' is offline. Aborting config validation
2017-08-31 13:25:15.124 [DEBUG] [odbus.handler.ModbusReadThingHandler] - ReadWrite bridge 'Modbus read-write definition' of ReadThing 'Modbus read definition' is offline. Aborting config validation
2017-08-31 13:25:15.124 [DEBUG] [odbus.handler.ModbusReadThingHandler] - ReadWrite bridge 'Modbus read-write definition' of ReadThing 'Modbus read definition' is offline. Aborting config validation
2017-08-31 13:25:15.127 [DEBUG] [odbus.handler.ModbusReadThingHandler] - ReadWrite bridge 'Modbus read-write definition' of ReadThing 'Modbus read definition' is offline. Aborting config validation
2017-08-31 13:25:15.129 [DEBUG] [odbus.handler.ModbusReadThingHandler] - ReadWrite bridge 'Modbus read-write definition' of ReadThing 'Modbus read definition' is offline. Aborting config validation
2017-08-31 13:25:15.130 [DEBUG] [odbus.handler.ModbusReadThingHandler] - ReadWrite bridge 'Modbus read-write definition' of ReadThing 'Modbus read definition' is offline. Aborting config validation
2017-08-31 13:25:15.132 [DEBUG] [odbus.handler.ModbusReadThingHandler] - ReadWrite bridge 'Modbus read-write definition' of ReadThing 'Modbus read definition' is offline. Aborting config validation

This is my current test things config:

Bridge modbus:serial:endpoint [ port="COM3", baud=9600, id=11, stopBits="1.0", parity="even",dataBits=8, echo=false, encoding="rtu", flowControlIn="none", flowControlOut="none", receiveTimeoutMillis=1500 ] {
	Bridge poller holding [ start=4000, length=12, refresh=500, type="holding" ] {
		Bridge readwrite Slave1 { 
			Thing read DeviceType [ start=1, transform="default", trigger="*", valueType="int16" ]
			Thing read DeviceVersion [ start=3, transform="default", trigger="*", valueType="int16" ]
			Thing read OutsideTemperature [ start=8, transform="default", trigger="*", valueType="int16" ]
			Thing read IndoorTemperature [ start=9, transform="default", trigger="*", valueType="int16" ]
		}
	}
}

Do you have any idea what the issue could be?
I also used Qmodbus to connect to the virtual serial port and it can read and write successfully.

Thanks!

Greetings,
Frederic

Thanks @FredericMa for reporting this. I see the issue in code and try to have fixed version for you in the near future.

Btw, I noticed that you have many read things inside single readwrite thing. This is technically ok if you are fine with just reading from modbus, but not writing. Also note you need to link the items to the read things. If you would link it to readwrite thing, the value changes a bit randomly as the read things represent quite different things.

If you would like to write the data, you need to introduce readwrite things and have read and write thing inside those. Refer to other examples in this thread for that.

Best
Sami

UPDATE: Should be fixed now. Can you please try @FredericMa with the new version?

Hi @ssalonen! Sounds like Finnish lastname :wink: or am I completely on the wrong tracks here?

Anyhow I’m running latest stable Openhabian on RPi3 and modbus server is siemens S7-1200 and here is my findings so far:

Installing through markeplace gives errors

2017-09-04 18:10:00.444 [WARN ] [ace.internal.BindingExtensionHandler] - Installed bundle, but failed to start it: Could not resolve module: org.openhab.binding.modbus [233]
  Unresolved requirement: Import-Package: org.eclipse.jdt.annotation; resolution:="optional"
  Unresolved requirement: Import-Package: org.openhab.io.transport.modbus
2017-09-04 18:10:00.450 [ExtensionEvent            ] - Extension 'market:binding-3528471' has been installed.
2017-09-04 18:10:11.657 [WARN ] [ace.internal.BindingExtensionHandler] - Installed bundle, but failed to start it: Could not resolve module: org.openhab.io.transport.modbus [234]
  Unresolved requirement: Import-Package: gnu.io
2017-09-04 18:10:11.660 [ExtensionEvent            ] - Extension 'market:binding-3528475' has been installed.

PaperUI does not show anything under binding or services configuration.

Next i dropped the binding and transport .jar files to addons folder. Karaf shows they are installed but nothing in logs nor PaperUI. Restarted openhab -->

2017-09-04 19:10:12.592 [ERROR] [org.openhab.binding.modbus          ] - FrameworkEvent ERROR - org.openhab.binding.modbus
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.modbus [235]
  Unresolved requirement: Import-Package: org.eclipse.jdt.annotation; resolution:="optional"
  Unresolved requirement: Import-Package: org.openhab.io.transport.modbus
    -> Export-Package: org.openhab.io.transport.modbus; bundle-symbolic-name="org.openhab.io.transport.modbus"; bundle-version="2.2.0.201709031748"; version="0.0.0"
       org.openhab.io.transport.modbus [236]
         Unresolved requirement: Import-Package: gnu.io
	at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
2017-09-04 19:10:12.611 [ERROR] [org.openhab.io.transport.modbus     ] - FrameworkEvent ERROR - org.openhab.io.transport.modbus
org.osgi.framework.BundleException: Could not resolve module: org.openhab.io.transport.modbus [236]
  Unresolved requirement: Import-Package: gnu.io
	at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]

Stupid question. Does this binding create needed configuration files witch can be modified through ESH Desinger?

Hi!

You are getting the error because you are missing the serial feature. Follow these instructions for installing the serial feature.

I’m not sure how the Oh designer works. You can certainly create configurations using the things file (examples in this thread), or alternatively using the paper ui.

Interesting to find fellow s1200 user! I’m using it as well with my production installation.

P.s. Yeah I’m Finnish indeed :slight_smile:

I’ll give it a new try hopefully tomorrow.

Do you have any readme or wiki that i have missed because this was the first time i heard about installing serial feature?

S7 is quite rare in home automation I think. For now its only controlling few valves, gathering temperatures from 3x logo8 and serving all those through modbus. Planning to use it as kwh counter also. But this might be a topic to continue elsewhere.

There is still some documentation gap for this new experimental version, something that definitely needs to be done before proper release.

I think that features might be installed automatically with final binding version, not sure though…