Wireless M-Bus binding keeps discarding chunk of data

[JensHoRi]

following io-bundles installed and active (searched for .io.):

169 x Active x  80 x 4.0.3                  x org.openhab.core.io.console.karaf
170 x Active x  80 x 4.0.3                  x org.openhab.core.io.http
171 x Active x  80 x 4.0.3                  x org.openhab.core.io.http.auth
173 x Active x  80 x 4.0.3                  x org.openhab.core.io.monitor
174 x Active x  80 x 4.0.3                  x org.openhab.core.io.net
175 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest
176 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.audio
177 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.auth
178 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.core
179 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.mdns
180 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.sitemap
181 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.sse
182 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.swagger
183 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.transform
184 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.ui
185 x Active x  80 x 4.0.3                  x org.openhab.core.io.rest.voice
186 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.mdns
187 x Active x  80 x 4.0.3                  x org.openhab.core.io.websocket
296 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.modbus
297 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.mqtt
298 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.serial
299 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.serial.rxtx
300 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.serial.rxtx.rfc2217
301 x Active x  80 x 4.0.3                  x org.openhab.core.io.transport.upnp

binding gives following output in debug mode:

2023-07-01 16:28:53.770 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 12 bytes
2023-07-01 16:28:55.802 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 12 bytes
2023-07-01 16:29:28.675 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 13 bytes
2023-07-01 16:29:33.682 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 1 bytes
2023-07-01 16:29:33.780 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 100 bytes
2023-07-01 16:29:43.601 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 3 bytes
2023-07-01 16:29:48.608 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 6 bytes
2023-07-01 16:29:48.721 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 100 bytes
2023-07-01 16:29:51.071 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 9 bytes
2023-07-01 16:29:59.709 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 1 bytes
2023-07-01 16:30:13.627 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 14 bytes
2023-07-01 16:30:14.678 [DEBUG] [ransport.WMBusMessageListenerAdapter] - Discarding chunk of data stream containing 0 bytes```

wmbus stick is following AMB8465-M

[splatch]

Hello Jens, Thank you for bringing issue. I also noticed that use of openHAB serial port API in place of jrxtx librar (as it is done in wmbus binding you tested), caused jmbus to discard large amounts of data. This issue is likely related to how internal implementation of serial port listener in jmbus works with retrieved data. As a side note - jmbus serial transport can discard a ton of data on its own, however its clear that probability of discarding is much higher with OH transport than with jrxtx.

I'll bring a jrxtx "bridge" in order to provide a quick testing possibility.

[JensHoRi]

Never decided for a special serial handler. But this combination works fine, as I use enocean, zwave (Gen5) and zwave (Gen7) in parallel, and furthermore wmbus.

[JensHoRi]

jrxtx Bridge seems to work now,

While looking on devices an channels, looks like a lot of telegrams are dicarded. Devices seems to work, but updates take really long times. Is there a special paket I should debug to get this confirmed and understood?

[JensHoRi]

Very interesting: Deactivating wmbus-Stick and activate again let the channels apear from earlier discovered and added devices.

Strange. Should work without disable and enable stick, that channels appears

[splatch]

While looking on devices an channels, looks like a lot of telegrams are dicarded. Devices seems to work, but updates take really long times. Is there a special paket I should debug to get this confirmed and understood? Strange. Should work without disable and enable stick, that channels appears

The serial port listener from jmbus can discard data on its own as it sometimes have troubles scanning "beginning" of frame and then keeps jumping blindly over data stream. I remember that sometimes it was sufficient to close and open port (that's what disable/enable cycle of bridge does) to restart listener and let it catch fresh breath.

For debugging purposes the old binding included a special "tool" I've made to log all received telegrams. Current binding does not have it. I did an early draft of such tool (called "communication inspector") together with wmbus binding with intention to make it useful for other bindings too. Obviously wmbus binding is first candidate to benefit from it. :-)

Another implication is - some wmbus devices can report two kinds of frames (or even more). For example Karmstrup devices have "short" frame which is reported frequently and "long" one which is reported every 30 minutes, or even less often. Each consist different payload resulting in different update frequency. In order to debug received payloads you can enable debug output for org.connectorio.addons.binding.wmbus.internal.transport.WMBusMessageListenerAdapter. It drops each and every message properly recognized by jmbus library.

[JensHoRi]

Yes, but the binding and the things were active for hours and still most meters don't have channels shown in UI.

Maybe because I used customIDs adding the things?

[JensHoRi]

Well, if everything is configured, all channels are sometime there, the devices working got actual data.

So only issue left is: It tooks a lot of time (restart Stick oder openhab helps somehow) until channels are up.

[JensHoRi]

All watermeters working fine and stable now.

But beware: With PR31 if I add my wmbus Stick with normal serial instead of jrxtx, openhab is directly killed without any log entry and restarts. After that dev/wmbus is stuck, so busy: Only a full reboot works.

So my opinion: Erase possibility for normal serial stick, better use jrxtx serial ;-)