Modbus openHAB2 binding available for alpha testing

@ssalonen can you get anything of this error message

21:49:04.817 [ERROR] [internal.profiles.ProfileCallbackImpl] - Exception occurred while calling handler: org.apache.commons.lang.NotImplementedException: Code is not implemented
java.util.concurrent.ExecutionException: org.apache.commons.lang.NotImplementedException: Code is not implemented
	at org.eclipse.smarthome.core.common.SafeMethodCaller.executeDirectly(SafeMethodCaller.java:220) ~[?:?]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:189) ~[?:?]
	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.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:58) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:44) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.CommunicationManager.lambda$2(CommunicationManager.java:240) ~[?:?]
	at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) [?:?]
	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) [?:?]
	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) [?:?]
	at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) [?:?]
	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) [?:?]
	at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:270) [?:?]
	at java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3566) [?:?]
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) [?:?]
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) [?:?]
	at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) [?:?]
	at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) [?:?]
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) [?:?]
	at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) [?:?]
	at org.eclipse.smarthome.core.thing.internal.CommunicationManager.receiveCommand(CommunicationManager.java:235) [104:org.eclipse.smarthome.core.thing:0.9.0.201711101643]
	at org.eclipse.smarthome.core.thing.internal.CommunicationManager.receive(CommunicationManager.java:103) [104:org.eclipse.smarthome.core.thing:0.9.0.201711101643]
	at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:207) [97:org.eclipse.smarthome.core:0.9.0.201711101643]
	at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:1) [97:org.eclipse.smarthome.core:0.9.0.201711101643]
	at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:181) [97:org.eclipse.smarthome.core:0.9.0.201711101643]
	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: org.apache.commons.lang.NotImplementedException: Code is not implemented
	at org.openhab.binding.modbus.handler.ModbusDataThingHandler.handleCommand(ModbusDataThingHandler.java:201) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl$1.call(ProfileCallbackImpl.java:61) ~[?:?]
	at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl$1.call(ProfileCallbackImpl.java:1) ~[?:?]
	at org.eclipse.smarthome.core.common.SafeMethodCaller.executeDirectly(SafeMethodCaller.java:218) ~[?:?]
	... 28 more

Hi @Nanna_Agesen

What is the writeType of the thing(s)? It seems to be something else than “coil” or “holding”.

I will improve the error handling.

Hi @ssalonen

Sorry - was trying to write to an input register :slight_smile:

Hi,

Just updated both openHAB and modbus to latest version. Everything’s working and no errors. Even without timeBetweenTransactionsMillis=100. Good job!


We can forget this. It was my error in configuration.


I’ve edited post #187 where I had wrong information about single bit addressing in Siemens S7-1200 with this binding. Information is now correct. Post #187

As we can see the holding register bytes are swapped. Is this something done by siemens because there is a function block available that does byte swapping in a 16bit register (word)? So there is a possibility to get those bit in continuous order from 0.1 to 0.15.

1 Like

As we can see the holding register bytes are swapped. Is this something done by siemens because there is a function block available that does byte swapping in a 16bit register (word)? So there is a possibility to get those bit in continuous order from 0.1 to 0.15.

I’m not sure I understand? Do you mean the order of data?

The bit indexing in the binding is least significant first, most significant bit last. In modbus big endian ordering is used, most significant bits are transmitted first .

Is there any conflict?

Best
Sami

Yes I’m wondering the order of data. Bits in this case. I think the endianes confused me here. Couldn’t get over the idea that first bits address is 0.8 and not 0.0. Reading your last post there seems to be a reason it is done this way. My original thought was that siemens somehow swaps bytes and that’s why the start address is 0.8. Googled it at the time and found some topics where people were wondering this same thing and there someone mentioned the “swap block” to swap the order of bytes in a word.

No, there’s no conflict if I understood all this right. Reading single bits from register works.

Reading my last post I see that the question was not really well written.

1 Like

New update, list of changes

  • Always ensure inter-transaction delay, even with new connections.
  • Bug fix: also coils are written with “write multiple coils” FC if set

  • Data thing handler: much improved / more strict error handling. Check thing status or logs if you encounter issues
  • (internal/other bindings) Exception classes now exported, jamod wrapping exceptions internal
  • (internal/other bindings) monitoring for queue sizes with TRACE level. Helps to find misbehavior before filling up memory

Let me know if any new issues arise

Best,
Sami

1 Like

Started to update the binding. I first renamed my modbus.things file to stop all polling, uninstalled binding and transport module. Then I clicked on install modbus transport and after that modbus binding. Loads of errors. Here I picked only few but most of them is these same lines repeating. Next I renamed .things file back to original hoping it would start to work but no avail. Checked karaf console and both do show Active.

But after restarting OH everything works as it should. No errors visible :+1:

12:56:59.821 [INFO ] [ort.modbus.internal.ModbusManagerImpl] - Modbus manager activated
12:57:00.859 [ERROR] [org.openhab.io.transport.modbus      ] - [MODBUS Connection Service(225)] The activate method has thrown an exception
java.lang.IllegalArgumentException: [org.apache.commons.pool2.impl.DefaultEvictionPolicy] does not implement EvictionPolicy
        at org.apache.commons.pool2.impl.BaseGenericObjectPool.setEvictionPolicyClassName(BaseGenericObjectPool.java:618) [216:org.openhab.io.transport.modbus:2.2.0.201711221947]
...
... 
12:57:12.392 [INFO ] [ort.modbus.internal.ModbusManagerImpl] - Modbus manager activated
12:57:12.473 [ERROR] [org.openhab.io.transport.modbus      ] - [MODBUS Connection Service(225)] The activate method has thrown an exception
java.lang.IllegalArgumentException: [org.apache.commons.pool2.impl.DefaultEvictionPolicy] does not implement EvictionPolicy
        at org.apache.commons.pool2.impl.BaseGenericObjectPool.setEvictionPolicyClassName(BaseGenericObjectPool.java:618) [216:org.openhab.io.transport.modbus:2.2.0.201711221947]
...
...   
12:57:17.310 [WARN ] [org.openhab.io.transport.modbus      ] - FrameworkEvent WARNING - org.openhab.io.transport.modbus
org.osgi.framework.ServiceException: org.apache.felix.scr.impl.manager.SingleComponentManager.getService() returned a null service object
        at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:232) [?:?]
...
...
12:57:17.305 [INFO ] [ort.modbus.internal.ModbusManagerImpl] - Modbus manager activated
12:57:18.557 [WARN ] [org.openhab.binding.modbus           ] - FrameworkEvent WARNING - org.openhab.binding.modbus
org.osgi.framework.ServiceException: org.apache.felix.scr.impl.manager.SingleComponentManager.getService() returned a null service object
        at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:232) [?:?]
...
...
12:57:18.609 [ERROR] [org.openhab.io.transport.modbus      ] - [MODBUS Connection Service(225)] The activate method has thrown an exception
java.lang.IllegalArgumentException: [org.apache.commons.pool2.impl.DefaultEvictionPolicy] does not implement EvictionPolicy
        at org.apache.commons.pool2.impl.BaseGenericObjectPool.setEvictionPolicyClassName(BaseGenericObjectPool.java:618) [216:org.openhab.io.transport.modbus:2.2.0.201711221947]
1 Like

Thank you very much, I will see if I can somehow reproduce this.

I btw made additional updates this week regarding io errors in the modbus library level. It turned out that proper error message was not captured properly. Some people have had “cannot read” errors with openhab1 binding but this finding with poor logging explains that the true reason was hidden.

Otherwise I am feeling happy from my side to consider this ready for review in github. All the main features should be there, and no bugs have been reported for a while.

The review typically takes quite much time (1-2 months), similar to development of this binding, people like me and openhab2 maintainers are all volunteers after all :slight_smile:

I am pretty confident saying the binding is now fairly stable – it is the time to try this binding, see if you get any issues. I am also interested hearing any performance issues or memory/cpu consumption.

Best
Sami

EDIT: Some last minute fixes regarding write transformations returning JSON.

1 Like

I think this is a transient error, the apache pool was updated at some point, probably explaining the “internal error” the ".DefaultEvictionPolicy] does not implement EvictionPolicy"..

Cannot get anything similar at least by stopping/starting the bundle(s)

I think this is a transient error, the apache pool was updated at some point, probably explaining the “internal error” there “.DefaultEvictionPolicy] does not implement EvictionPolicy”


Ok. Next time when I update OH I’ll reinstall these to see if errors are still present.

Otherwise I am feeling happy from my side to consider this ready for review in github. All the main features should be there, and no bugs have been reported for a while.

+1 from here.

1 Like

Update here: The pull request is being worked on: PR 2246 and no changes are no longer expected unless issues are reported by You, or if the code review reveals something.

Please make sure you have the latest version of binding and transport, and feel free post any issues encountered. Any help testing the binding is much appreciated!

P.S. I’ve received note that the binding will probably go after 2.3 release, not the upcoming 2.2 release.

Some comments:

In the Paper IU:
I’ve added a Modbus TCP slave, then modified the “slave id”.
I was forced to restart the openHab server to apply the modification.

Concerning the “Regular pool”:
It would be great if we can define something like 30531/2, 30775/8 in the start field. It would mean 30531, 30532, 30775, 30776, 30777, 30778, 30779, 30780, 30781, 30782.
Instead of creating two different pools.

In the “bridge selection”, it would be really nice to write the unit (kWh, Watts, Amps. Volt).

Some more comments:

  • Integration is a hell :slight_smile: You did a great job and thank you! But finding the SMA specific settings is just terrible.
  • It’s difficult to know that you have to integrate “modbus” for “SMA Inverter”.
  • Having “profiles” may be great. As an example I select “SMA SunnyBoy Inverter” and automatically I can add a thing that monitor my current energy production (Total, Instantaneous).
  • Sometime I have a crazy high number (correspond to “NaN”). It would be cool to be able to define this number as crazy.
  • I have some numbers like 22600 (volts) that need to be divided by 100. (having something to be able to do it easily would be great.)

Perhaps adding “HowTo” in the documentation (I would be happy to participate in the creation of the documentation for the SMA inverter). As an example you need to enable “modbus” in my SMA
 and it’s not a trivial task :slight_smile:

Note for Sunny SMA interter (5000TL20)

  • Slave ID: 3 (you can change it in your documentation)
  • Instantaneous power: 30775 - uint 32.
  • Total production (wH): 30529 - uint 32. 30531 if you want to have it in kWh

Technical details are on

Aren’t these possible with mappings and transformation?

OpenHAB doesn’t know anything about units, so I don’t think that is practical.

People usually deal with that in sitemap labels etc.

@gabriel.klein thank you very much for the feedback. Some comments:

I’ve added a Modbus TCP slave, then modified the “slave id”.
I was forced to restart the openHab server to apply the modification.

I can reproduce this using PaperUI using the following steps. Same fault applies to all endpoint parameters. Thanks for this. It looks like the openHAB core was not behaving as expected causing this issue.

Sometime I have a crazy high number (correspond to “NaN”). It would be cool to be able to define this number as crazy.

This is actually possible (as mentioned by @gitMiguel also), using transformations:

// 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
    var CRAZY_LARGE = 1000;
    var number = parseFloat(inputData);
    return number > CRAZY_LARGE ? "NULL" : number;
})(input)

The above transformation transforms numbers over 1000 to NULL (usually shown as - in UI), while other numbers are passed is. Note that openHAB does not seem to support NULL commands to number channels, so the above transformation is meaningful only on read.

Also, please note that since decimal numbers in openHAB (DecimalType) use Java BigDecimal, they do not have concept of NaN.

I have some numbers like 22600 (volts) that need to be divided by 100. (having something to be able to do it easily would be great.)

Please consult the Scaling example in README.

Having “profiles” may be great. As an example I select “SMA SunnyBoy Inverter” and automatically I can add a thing that monitor my current energy production (Total, Instantaneous).

Perhaps adding “HowTo” in the documentation (I would be happy to participate in the creation of the documentation for the SMA inverter)

Profiles sounds very tempting and perhaps over time there will be specialized bindings for different devices. This new modbus binding actually consists of two parts, 1) the transport encapsulating the general protocol level stuff, and taking care of low level issues (e.g. too fast requests to slave); 2) the general purpose modbus binding.

The general purpose binding might be more complex than necessary when dealing with some specific device. There might come additional bindings dealing with with such devices. Or perhaps there is a way to “template” configurations – not sure what it would mean in openHAB world.

In the meanwhile, we can indeed share “How to” documentation for different devices, and incorporate that to a common place, for example.

I’m willing to help here for sure.

For large configurations, and sharing the how to, things file format (see README examples) might be the most convenient in my opinion. Why do you think?

Best,
Sami

Thank you for all the responses.

JS transformation <<

I’ve enabled the JS transformation, then written some javscripts. I call the script using JS(nameOfScript.js).

I would love to have a transformation built on top of exp4j and then be able to use things like EXP4J(i/100). Or more complex - a mix between EXP4J and logical operatiuons: EXP(i<0?0:(i>25000?0:(i/100))). – it’s another topic :slight_smile:

“OpenHAB doesn’t know anything about units”<<

You may be right - but I have the units is some other addons: Example: 17.8 °C.
I hate working without units :slight_smile: :slight_smile:
Another point is the possibility to define a “type”. As an example if I use the android application and I see a nice “humidity, temperature, pressure” icon if I select data from other modules. If I select data from this module I only see “Value as Number” and no value :slight_smile:

In the XML description of other modules it’s defined as typeId=“humidity” or typeId=“temperature”

Many things may be resolved already if we use the *.thing (textual) and not using PaperUI!

Another point is a cosmetic detail :slight_smile: I want to be able to join similar informations in the same “area”. Example

Another suggestion is to use the “advanced=true” for all the channel except the first one (Value as Number) Something similar to what is defined in "thing-types.xml: "

Thank you for the work! Lot of remarks - but I want to share ideas. I’m already quite happy with this work!!

What an great idea! Ideally it really should be just a openhab transformation, usable by all bindings. Perhaps it’s better to start new thread regarding this?

I believe this is done using item label? Am I missing something?

I believe this is done using item icon?

I am not sure what this refers to. Can you give some example?

What do you mean? Are you saying that paper ui is missing features?

I find the control view more as an debugging screen. Have you looked into sitemaps? They are meant for grouping items etc

Best
Sami

@gabriel.klein – The issue described (slave id not updating without restart) should be now fixed. Please update your binding and transport and let me know if you still encounter any issues.

How is it going with SMA inverter?

Best,
Sami