Modbus openHAB2 binding available for alpha testing

openhab2-addons
modbus
binding
Tags: #<Tag:0x00007fe054c8b6a8> #<Tag:0x00007fe054c8b568> #<Tag:0x00007fe054c8b400>

(Ssalonen) #435

OK haven’t experienced anything this bad certainly. Thanks for the help debugging this.


(Michael Parment) #436

Now i have this installed and it works good. I think it was some problem whit the ipcamera binding that was the problem.

/Mike


(Ssalonen) #437

@randipandu, have you had to chance to see my comments?


(Bogumil J.) #438

Hi I try to configure my binding to work with Fatek FBs over Modbus RTU via serial.
http://www.fatek.com/en/data%2Fftp%2FPLC%2FFBs_Manual%2FManual_1%2FInstruction%2FChapter_2.pdf
http://www.esea.cz/support/fatek/FBs_Manual/Manual_2/Chapter_13.pdf
I configured poll for markers (coils) with range from 0 to 2001.
Then I added things for each marker and configured items as switches.
I’m getting:
[WARN ] [ternal.ModbusManagerImpl.PollMonitor] - Many (676) tasks queued in callbackThreadPool! This might be sign of bad design or bug in the binding code.
and increases in time
[WARN ] [ternal.ModbusManagerImpl.PollMonitor] - Many (3099) tasks queued in callbackThreadPool! This might be sign of bad design or bug in the binding code.

Haven’t had issues with previous modbus binding with length of 2001 for poll.
How to deal with this case?

Is there a better way to poll multiple markers?


(Rolf) #439

Dear all

I’m new to the Modbus binding. I try to get it running, however so far no success. I use a USR-TCP232-410S with following configuration:

My things file looks liket that:

Bridge modbus:tcp:Pool [ host="192.168.178.30", port=26, id=1 ] {
	Bridge poller holding [ start=1, length=1, refresh=500, type="holding"]{
        Thing data holding1 [ readStart="1", readValueType="int16", writeStart="1", writeValueType="int16", writeType="holding" ]
    }
}

I get following errors (smarthome:things list):

modbus:tcp:Pool (Type=Bridge, Status=ONLINE, Label=Modbus TCP slave, Bridge=null)
modbus:poller:Pool:holding (Type=Bridge, Status=OFFLINE (COMMUNICATION_ERROR): Error with read: org.openhab.io.transport.modbus.internal.ModbusSlaveIOExceptionImpl: null, Label=Regular poll, Bridge=modbus:tcp:Pool)
modbus:data:Pool:holding:holding1 (Type=Thing, Status=OFFLINE (COMMUNICATION_ERROR): Error (ModbusSlaveIOExceptionImpl) with read. Request: ModbusPollerThingHandlerImpl.ModbusPollerReadRequest@1c21836[slaveId=1,functionCode=READ_MULTIPLE_REGISTERS,start=1,length=1,maxTries=3]. Description: ModbusSlaveIOException(cause=ModbusIOException, EOF=false, message='I/O exception: SocketTimeoutException Read timed out', cause=null). Message: null, Label=Modbus data, Bridge=modbus:poller:Pool:holding)

or in the log:tail:

12:00:18.874 [ERROR] [.wimpi.modbus.io.ModbusTCPTransaction] - execute try 1/1 error: I/O exception: SocketTimeoutException Read timed out. Request: net.wimpi.modbus.msg.ReadMultipleRegistersRequest@9d3b40 (unit id 1 & transaction 11648). Address: /192.168.178.30:26
12:00:18.918 [ERROR] [.wimpi.modbus.io.ModbusTCPTransaction] - execute reached max tries 1, throwing last error: I/O exception: SocketTimeoutException Read timed out. Request: net.wimpi.modbus.msg.ReadMultipleRegistersRequest@9d3b40 (unit id 1 & transaction 11648). Address: /192.168.178.30:26

Could anyone please help me. I’m somehow stuck.

Many thanks for your help
Best regards
Rolf


(Ssalonen) #440

Hi,

Can you please paste here your configuration?

  • If you are using textual configuration, please paste the contents of items and things files
  • If you are using paper UI, please paste pages OPENHAB:8080/rest/items and OPENHAB:8080/rest/things

Please use proper formatting when pasting the config: How to use code fences

Finally, some further questions:

  • does the warning message come on openHAB startup? Does the number in parentheses decrease (in your example, 676 and 3099). The reason might be that openHAB automatically tries to REFRESH all data things, generating many read requests in a queue. With 2001 data things, it would generate 2001 modbus requests to the queue.

Best,
Sami


(Bogumil J.) #441

Hi,
(…) - I limited marker things to 200 for this post

modbus.things

Bridge modbus:serial:fatekplcusb0  "FatekPLC_USB0" [ baud=115200, timeBetweenTransactionsMillis=35, connectMaxTries=3, stopBits="1.0", parity="none", receiveTimeoutMillis=1500, dataBits=8, echo=false, encoding="rtu", flowControlIn="none", port="/dev/ttyUSB0", flowControlOut="none", connectTimeoutMillis=10000, id=1 ] {
    Bridge poller coils_Y0_to_Y255 "FatekPLC_Poller_Y0_to_Y255" [ start=0, length=256, refresh=100, type="coil" ] {
        // Note the zero based indexing: first coil is index 0.
        Thing data FatekPLC_Modbus_Y0 "FatekPLC_Modbus_Y0" @ "Modbus" [ readStart="0", readValueType="bit", writeStart="0", writeValueType="bit", writeType="coil" ]
        Thing data FatekPLC_Modbus_Y1 "FatekPLC_Modbus_Y1" @ "Modbus" [ readStart="1", readValueType="bit", writeStart="1", writeValueType="bit", writeType="coil" ]
    }
//M0 to M2001
    Bridge poller markers_M0_to_M199 "FatekPLC_Poller_M0_to_M199" [ start=2000, length=200, refresh=5000, type="coil" ] {
        // Note the zero based indexing: first coil is index 0.
        Thing data FatekPLC_Modbus_M0 "FatekPLC_Modbus_M0" @ "Modbus" [ readStart="2000", readValueType="bit", writeStart="2000", writeValueType="bit", writeType="coil" ]
        Thing data FatekPLC_Modbus_M1 "FatekPLC_Modbus_M1" @ "Modbus" [ readStart="2001", readValueType="bit", writeStart="2001", writeValueType="bit", writeType="coil" ]
        Thing data FatekPLC_Modbus_M199 "FatekPLC_Modbus_M199" @ "Modbus" [ readStart="2199", readValueType="bit", writeStart="2199", writeValueType="bit", writeType="coil" ]
    }
}

modbus.items

Group gModbus (All)
Switch FatekPLC_Modbus_M0 "FatekPLC_Modbus_M0" (gModbus) { channel="modbus:data:fatekplcusb0:markers_M0_to_M199:FatekPLC_Modbus_M0:switch" }
Switch FatekPLC_Modbus_M1 "FatekPLC_Modbus_M1" (gModbus) { channel="modbus:data:fatekplcusb0:markers_M0_to_M199:FatekPLC_Modbus_M1:switch" }
Switch FatekPLC_Modbus_M2 "FatekPLC_Modbus_M2" (gModbus) { channel="modbus:data:fatekplcusb0:markers_M0_to_M199:FatekPLC_Modbus_M2:switch" }
Switch FatekPLC_Modbus_M3 "FatekPLC_Modbus_M3" (gModbus) { channel="modbus:data:fatekplcusb0:markers_M0_to_M199:FatekPLC_Modbus_M3:switch" }

(…) up to M199

Answering your question. On the beginning I have had poll refresh set to 1000 for 2001 things. First I limited amount of things to 200. Then I was getting the message and the amount of tasks was quicky increasing. I started increase poll refresh to the moment when amount of tasks started to decrease and I finished at about 5000. Poll refresh at 5000 is unfortunately much to high and is meaningless for any of my home purposes.
With the old binding I didn’t have such kind of issue. It just worked.
The question I have is, what is the best way to poll high amount of coils when I use them only for “Switch” type?


Modbus binding only works sometimes (CRC error)
(Ssalonen) #442

Hi ,

thanks for the configs. In your config you have length=200 with the “markers”. What is the true configuration? Most importantly, how many data things you have? How many pollers with what configuration? I don’t understand how the true configuration has been modified for the thread post?

I have seen similar issue with my testing but there the queue sizes were much smaller and thus not an real issue (see explanation below).

I presume the queue is getting large due to openHAB requesting refresh on startup, when the things are introduced to the system. Basically, all the data things receive REFRESH command to the channels bound to items.

Can you provide verbose logs (see logging guide in docs), starting from openHAB startup, so I can confirm this “theory”?

The openHAB core sends REFRESH command to each of the data things. Each command translates to one modbus request, explaining the large queue size.

The queue size should decrease over time. In your case with 35ms between requests, queue of 3000 requests takes around 1.5 minutes to clear. This is quite a long time.

The poll period should not make a difference here, I think. However, if you are sending commands to modbus items (writing to modbus) within rules with fast pace, the queue can and will increase as well.

Can you observe that queue size decreases over time? Check how the number in the log message evolves using this console command `log:tail | grep ‘tasks queued’

Old binding does not have this issue since it did not support concept of REFRESH at all.

Unfortunately, I don’t have a workaround for you in this case. I appreciate if you can provide the logs and provide answer to the above points so we get a comfirmation on this. I probably need to consult the openHAB maintainers as well the best/cleanest way to solve this.

Best
Sami


Possible performance of bindings?
(Sven V Beuningen) #443

Hi,

I’m new to this modbus binding and could need some help. The last few days I played around with connecting my arduino via modbus with my raspberry pi. With the old modbus1 binding, I didn’t get it to work.
Now I tried this modbus2 binding and it works way better than before.
Unfortunately, there is one thing which I don’t understand. Here is my Setup:

  1. Openhab on Raspberry PI
  2. USB to RS485 converter
  3. Max485 IC
  4. Arduino with a modbus library and 16 outputs configured as coils

I did all configuration in the paper UI, because it has been very easy :slight_smile:

These are my things:

  1. Modbus Serial Slave with Port /dev/ttyUSB0, Baud 38400, ID 2

  2. Regular Poll, Intervall 500, start 0, length 16 (because of the 16 coils on the arduino), type coil

  3. 16 times Modbus data. one for each coil.

    1. read address 0, write address 0, write type coil
    2. read address 1, write address 1, write type coil
    3. read address 2, write address 2, write type coil
    4. read address 15, write address 15, write type coil
  4. Each Modbus data has one switch linked to control the outputs

Now the fun part:
coil 0-6 are working fine
coil 7 can’t be changed. Everytime I switch to “on” it immediately switches back to off
coil 8-14 are working fine
coil 15 can’t be changed. Everytime I switch to “off” it immediately switches back on

It feels strange that always the last of 8 coils is not working fine? Is there a special case, because the 8th is using the highest bit in a byte? Just speculating…

Btw. No errors in the logs.

So Long

Sven


(Rolf) #444

Dear Sami

Coming back to my post 8 days ago: Most of the things I could get running (was an issue on USR IOT side). I have only one problem left. Reading registers is not a problem, but when trying to write into a register, that does not work. E.g. When trying to do it via paper UI:
modbus

I type in a different value, e.g. 210 however number goes always back to 230 (even when typing (maybe it has something to do wish refreshing?)

the things file looks like that:

Bridge modbus:tcp:Pool [ host="192.168.178.30", port=502, id=1 ] {
     Bridge poller holding_high [ start=128, length=45, refresh=500, type="holding"]{
        Thing data holding134 [ readStart="134", readValueType="uint16", writeStart="134", writeValueType="uint16", writeType="holding" ]
     }
}

The item file like that:

Number Pumpenspannung "Sollspannung [%.0f V]" {channel="modbus:data:Pool:holding_high:holding134:number"}

When trying to adjust the number via sitemap also this does not work:

Setpoint	item=Sollspannung 			minValue=0 maxValue=230 step=10 icon=temperature

It would be great to get a hint on this issue

Thank you in advance and best regards
Rolf


(Rossko57) #445

Because Modbus is a polling protocol, I would not expect you to have any luck writing a register from PaperUI. By the time you have finished typing a new value, modbus will read the old value from your device and update your Item to overwrite what you typed.

You could make the Item write-only. But that often won’t be useful.

You can update the Item from a rule, where the value to be written is not affected by any read poll.
If you need to type something in for testing, use an intermediate Item that you can update from UI, and a rule that triggers on that Item being updated and writes that new value to the ‘real’ register Item.


(Rolf) #446

Dear rossko57

Thank you very much for the quick reply. I suspected that this is the problem. What about using e.g. setpoint in a sitemap? Do you expect the same problems? I already tried that but could not do anything meaningful with it.

Thank you very much in advance for a hint.

Best regards
Rolf


(Rolf) #447

Dear roosko57

I understand better, why there seems to be an issue with setpoint: I’m using a Transformationservice for the data thing:

Thing data holding1 [ readStart="1", readValueType="int16" , readTransform="JS(divide10.js)",writeStart="1", writeValueType="int16", writeTransform="JS(multiply10.js)", writeType="holding" ]

with item

Number Pumpenfrequenz "Pumpenfrequenz" {channel="modbus:data:Pool:holding_low:holding1:number"}

and with setpoint

Setpoint	item=Pumpenfrequenz 		minValue=0 maxValue=50 step=5 icon=temperature

somehow the values are messed up by dividing too many times by 10, when trying to change the value. When I take out the scaling the setpoint is working perfectly.

Any ideas would be highly appreciated.

Best regards
Rolf


(Rossko57) #448

I’m not at all familiar with the interaction of transforms and setpoints, sorry.


(Sven V Beuningen) #449

Ok, found it by myself. I now use a different modbus lib on the arduino. It seems to work fine now

So long

Sven


(Rolf) #450

Dear Sami or anybody else

Somebody else an idea. For your information, When looking into the log file there is an error:

21:20:08.102 [ERROR] [inding.modbus.internal.Transformation] - transformation throws exception [transformation=JS(multiply10.js), response=3.6]
org.eclipse.smarthome.core.transform.TransformationException: An error occurred while executing script.
        at org.eclipse.smarthome.transform.javascript.internal.JavaScriptTransformationService.transform(JavaScriptTransformationService.java:84) [224:org.eclipse.smarthome.transform.javascript:0.10.0.b1]
        at org.openhab.binding.modbus.internal.Transformation.transform(Transformation.java:150) [222:org.openhab.binding.modbus:2.3.0.201804290926]
        at org.openhab.binding.modbus.handler.ModbusDataThingHandler.handleCommand(ModbusDataThingHandler.java:163) [222:org.openhab.binding.modbus:2.3.0.201804290926]
        at sun.reflect.GeneratedMethodAccessor142.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [111:org.eclipse.smarthome.core:0.10.0.b1]
        at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [111:org.eclipse.smarthome.core:0.10.0.b1]
        at com.sun.proxy.$Proxy136.handleCommand(Unknown Source) [222:org.openhab.binding.modbus:2.3.0.201804290926]
        at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:72) [118:org.eclipse.smarthome.core.thing:0.10.0.b1]
        at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:49) [118:org.eclipse.smarthome.core.thing:0.10.0.b1]
        at sun.reflect.GeneratedMethodAccessor141.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [111:org.eclipse.smarthome.core:0.10.0.b1]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [111:org.eclipse.smarthome.core:0.10.0.b1]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: javax.script.ScriptException: <eval>:1:0 Expected an operand but found /
/ Wrap everything in a function (no global variable pollution)
^ in <eval> at line number 1 at column number 0
        at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:470) ~[?:?]
        at jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:537) ~[?:?]
        at jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:524) ~[?:?]
        at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402) ~[?:?]
        at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:150) ~[?:?]
        at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:249) ~[?:?]
        at org.eclipse.smarthome.transform.javascript.internal.JavaScriptTransformationService.transform(JavaScriptTransformationService.java:82) ~[?:?]
        ... 19 more
Caused by: jdk.nashorn.internal.runtime.ParserException: <eval>:1:0 Expected an operand but found /
/ Wrap everything in a function (no global variable pollution)
^
        at jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:294) ~[?:?]
        at jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:279) ~[?:?]
        at jdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:3182) ~[?:?]
        at jdk.nashorn.internal.parser.Parser.expression(Parser.java:3282) ~[?:?]
        at jdk.nashorn.internal.parser.Parser.expressionStatement(Parser.java:1150) ~[?:?]
        at jdk.nashorn.internal.parser.Parser.statement(Parser.java:967) ~[?:?]
        at jdk.nashorn.internal.parser.Parser.sourceElements(Parser.java:773) ~[?:?]
        at jdk.nashorn.internal.parser.Parser.program(Parser.java:709) ~[?:?]
        at jdk.nashorn.internal.parser.Parser.parse(Parser.java:283) ~[?:?]
        at jdk.nashorn.internal.parser.Parser.parse(Parser.java:249) ~[?:?]
        at jdk.nashorn.internal.runtime.Context.compile(Context.java:1284) ~[?:?]
        at jdk.nashorn.internal.runtime.Context.compileScript(Context.java:1251) ~[?:?]
        at jdk.nashorn.internal.runtime.Context.compileScript(Context.java:627) ~[?:?]
        at jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:535) ~[?:?]
        at jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:524) ~[?:?]
        at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402) ~[?:?]
        at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:150) ~[?:?]
        at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:249) ~[?:?]
        at org.eclipse.smarthome.transform.javascript.internal.JavaScriptTransformationService.transform(JavaScriptTransformationService.java:82) ~[?:?]
        ... 19 more

I used the code as proposed in the readme:

// Wrap everything in a function (no global variable pollution)
// variable "input" contains data passed by openhab
(function(inputData) {
    // on read: the polled number as string
    // on write: i openHAB command as string
    var MULTIPLY_BY = 10;
    return Math.round(parseFloat(inputData, 10) * MULTIPLY_BY);
})(input)

Any help would be highly appreciated.

Best regards
Rolf


(Rolf) #451

I have found the mistake, very silly. was a copy-paste mistake. instead of // I lost the first / at the beginning of the function. Now it is working…

Thank all of you anyhow.

Best regards rolf


(Ssalonen) #452

Have not encountered this kind of behavior unfortunately. Could it be that your device is changing the coil state as well?

UPDATE now saw your reply, never mind

Best
Sami


(Bogumil J.) #453

Hi, my true config contains about 200 “markers” as I have this amount of coils in my system, I just cut it for this thread purposes as it was very long. Every single marker is configured the same way from 0 to 199. I will do more tests with verbose logging soon however I’m busy right now, sorry. I will back to the issue asap.


(Martin Vasko) #454

Hi, I want to read data from 2 modbus RTU slaves. both are connected at MOXA nport230. It is working with one slave. For 2 slaves I modified modbus.things

/poller thing -lenght, type are required
Bridge modbus:serial:endpointMOXA [port="/dev/ttyr01",baud=9600,id=11,dataBits=8,parity=“none”,stopBits=“1”,encoding=“rtu”] {
Bridge poller holdingsREG1[ start=0, length=6, refresh=4000, type=“holding”] {
Thing data temp1 [ readStart=“0”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data temp2 [ readStart=“1”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data temp3 [ readStart=“2”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data temp4 [ readStart=“3”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data temp5 [ readStart=“4”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data temp6 [ readStart=“5”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
}

}
Bridge modbus:serial:endpointMOXA2 [port="/dev/ttyr01",baud=9600,id=10,dataBits=8,parity=“none”,stopBits=“1”,encoding=“rtu”] {
Bridge poller holdingsREG2[ start=0, length=8, refresh=4500, type=“holding”] {
Thing data teplota1 [ readStart=“0”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data teplota2 [ readStart=“1”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data teplota3 [ readStart=“2”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data teplota4 [ readStart=“3”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data teplota5 [ readStart=“4”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data teplota6 [ readStart=“5”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
}

poller2 is in error
Error with read: org.openhab.io.transport.modbus.internal.ModbusSlaveIOExceptionImpl:
null
Have you any idea? Thanx