[dsmr] Add bridgeUID to thingUID during discovery

[wborn]

Additional validation got added in OH3 to make sure that the bridgeUID is added to Things with bridges (openhab/openhab-core#1481).

The DSMRBridgeDiscoveryService did not add the bridgeUID so it would cause the following exceptions during discovery:

java.lang.IllegalArgumentException: Thing UID 'dsmr:device_v4:default' does not match bridge UID 'dsmr:dsmrBridge:22e5393c'
	at org.openhab.core.config.discovery.DiscoveryResultBuilder.validateThingUID(DiscoveryResultBuilder.java:166) ~[bundleFile:?]
	at org.openhab.core.config.discovery.DiscoveryResultBuilder.withBridge(DiscoveryResultBuilder.java:120) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.discovery.DSMRDiscoveryService.meterDiscovered(DSMRDiscoveryService.java:81) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.discovery.DSMRBridgeDiscoveryService.lambda$1(DSMRBridgeDiscoveryService.java:171) ~[bundleFile:?]
	at java.util.HashMap$Values.forEach(HashMap.java:976) ~[?:?]
	at org.openhab.binding.dsmr.internal.discovery.DSMRBridgeDiscoveryService.handleTelegramReceived(DSMRBridgeDiscoveryService.java:171) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRTelegramListener.telegramReceived(DSMRTelegramListener.java:97) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.parse(P1TelegramParser.java:265) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.SmartyDecrypter.parse(SmartyDecrypter.java:107) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRTelegramListener.handleData(DSMRTelegramListener.java:74) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRBaseConnector.handleDataAvailable(DSMRBaseConnector.java:116) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.handleDataAvailable(DSMRSerialConnector.java:317) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.serialEvent(DSMRSerialConnector.java:276) [bundleFile:?]
	at org.openhab.core.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(RxTxSerialPort.java:81) [bundleFile:?]
	at gnu.io.RXTXPort.sendEvent(RXTXPort.java:834) [bundleFile:5.2.1]
	at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:5.2.1]
	at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:108) [bundleFile:5.2.1]

[Hilbrand]

LGTM. You probably found out using it? Maybe we should create an issue to check all other bindings?

[wborn]

Yes I'm testing OH3 and fixing the bugs I run into so it becomes a bit more stable. I'll have a look at the other add-ons next. We might have already caught some of these bugs if we could build add-ons for OH3 with tests enabled. Though that is currently not an option because the tests need to be migrated to JUnit 5. 😉

[Hilbrand]

Ough. Can we already add JUnit 5 to 2.5? to start migration?

[wborn]

We'd have to upgrade several dependencies including bnd which may cause regressions in 2.5.x. It's probably less risky and easier to do this when the code has been ported to the master branch (which already has all JUnit 5 infrastructure in place).