[TCP] correct item could not be parsed correctly

[MichielVanwelsenaere]

Expected Behavior

item not marked as 'could not be parsed correctly'

Current Behavior

item marked as 'could not be parsed correctly', the two items below generate an error in the karaf console: Switch DO_02_2 "DO_02_2" {modbus="<[wago750_DO:10]", tcp=">[ON:WagoPLC:2000:'\u0024\u0041\u0003\u0000\u000**A**\u0002\u0023'], >[OFF:WagoPLC:2000:'\u0024\u0041\u0003\u0000\u000**A**\u0001\u0023']", autoupdate="false"}

Switch DO_02_5 "DO_02_5" {modbus="<[wago750_DO:9]", tcp=">[ON:WagoPLC:2000:'\u0024\u0041\u0003\u0000\u000**D**\u0002\u0023'], >[OFF:WagoPLC:2000:'\u0024\u0041\u0003\u0000\u000**D**\u0001\u0023']", autoupdate="false"}

exception:

09:40:06.788 [Start Level: Equinox Container: 593b400e-24c4-406b-9899-04faad52e5f2] ERROR org.eclipse.smarthome.model.item.internal.GenericItemProvider - Binding configuration of type 'tcp' of item 'DO_02_5' could not be parsed correctly. OpenHAB2_1 | org.eclipse.smarthome.model.item.BindingConfigParseException: bindingConfig#']' doesn't contain a valid binding configuration OpenHAB2_1 | at org.openhab.core.binding.internal.BindingConfigReaderDelegate.processBindingConfiguration(BindingConfigReaderDelegate.java:52) [194:org.openhab.core.compat1x:2.3.0] OpenHAB2_1 | at org.eclipse.smarthome.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:400) [127:org.eclipse.smarthome.model.item:0.10.0.oh230] OpenHAB2_1 | at org.eclipse.smarthome.model.item.internal.GenericItemProvider.dispatchBindingsPerType(GenericItemProvider.java:353) [127:org.eclipse.smarthome.model.item:0.10.0.oh230] OpenHAB2_1 | at org.eclipse.smarthome.model.item.internal.GenericItemProvider.addBindingConfigReader(GenericItemProvider.java:164) [127:org.eclipse.smarthome.model.item:0.10.0.oh230] OpenHAB2_1 | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] OpenHAB2_1 | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?] OpenHAB2_1 | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] OpenHAB2_1 | at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?] OpenHAB2_1 | at org.apache.felix.scr.impl.inject.BaseMethod.invokeMethod(BaseMethod.java:229) [39:org.apache.felix.scr:2.0.12]

I have many of these items yet only these two cause a problem, if I update the bold character to by example '9' the error is not logged and the item works (but not as desired ofcourse)

Possible Solution

A workaround could be using a transformation map, yet this behavior probably shouldn't be occurring? In addition I'm worried that this also causes problems in rules, in the future I'm planning to send dynamic values via tcp using rules

Steps to Reproduce

Use the item configuration mentioned above

Context

custom tcp communication with a plc (please don't make my rewrite the plc logic for this bug :D )

Your Environment

OpenHAB2.3 dockerized

Let me know if any further information is required

[9037568]

Do you get the same behaviour if you use \u000d and \u000a (lower case instead of upper) ?

[MichielVanwelsenaere]

just verified with lower case and indeed the same behavior unfortunately

[9037568]

The failure here appears to be happening outside of the binding, when the binding calls its super class AbstractGenericBindingProvider's processBindingConfiguration() method.

We may need some input from @kaikreuzer or another core dev to tell us whether it's possible to support newlines in these strings...

[kaikreuzer]

Sorry, I have no clue - but having newlines in the string sounds ugly indeed. I can imagine that it already causes issues during parsing. I guess this would need to be debugged in detail to see what string ends up where and what happens to the newlines on the way...

[9037568]

I guess I'll try to debug further in the superclass, though at the moment I don't have a clue what it's doing.

[9037568]

I finally figured this one out.

Because of the way the binding config string is parsed, newlines are not allowed.

We could change the regular expression used to allow newlines. Here's an updated binding that does this.

It's not clear if this would cause breakage for existing setups. I'll make a request in the community for feedback.