No power failure logs in DSMR

Dear all,
System setup:
Clean Debian 11 minimal and only openHAB, initially OH3.2 upgraded to 3.3.
P1 to ethernet connection, server is in another building.
One binding DSMR (4.2), all 4 Things and items for all channels.
Serial: rfc2217://x.x.x.x:23
Telnet session: telegrams arrive complete and at intervals of 10 seconds.
All P1 variables are imported in openHAB correctly and updated every 10 seconds, except the logs.
It’s not a “life-threatening” situation, but merely annoying.

The part of the P1 telegram with the logs:


TRACE logging:

2022-07-01 00:05:07.681 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:99.97.0, obisId: 1-0:99.97.0, values: (10)(0-0:96.7.19)(210707130951S)(0000002930*s)(190813010343S)(0000003459*s)(190331143203S)(0000000620*s)(160907122752S)(0000000717*s)(160513140148S)(0000001030*s)(160513095721S)(0000001119*s)(160503143305S)(0000000646*s)(160503121845S)(0000000686*s)(160503120522S)(0000000182*s)(160502094435S)(0000242041*s)

The OBIS ID is recognized, but parsing seems to skip assigning the 10 to EMETER_POWER_FAILURE_LOG_ENTRIES (the value of the item remains NULL):

2022-07-01 00:05:07.681 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Found obisId 1-99.97.0 in the fixed lookup table
2022-07-01 00:05:07.682 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: EMETER_POWER_FAILURE_LOG
2022-07-01 00:05:07.682 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (10)(0-0:96.7.19)(210707130951S)(0000002930*s)(190813010343S)(0000003459*s)(190331143203S)(0000000620*s)(160907122752S)(0000000717*s)(160513140148S)(0000001030*s)(160513095721S)(0000001119*s)(160503143305S)(0000000646*s)(160503121845S)(0000000686*s)(160503120522S)(0000000182*s)(160502094435S)(0000242041*s)

2022-07-01 00:05:07.682 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 22 is supported

2022-07-01 00:05:07.689 [TRACE] [l.device.p1telegram.P1TelegramParser] - Adding Cosem Object(type:EMETER_POWER_FAILURE_LOG, cosemValues:{timestamp1=2019-08-13T01:03:43.000+0200, duration9=242041 s, timestamp0=2021-07-07T13:09:51.000+0200, duration8=182 s, timestamp5=2016-05-13T09:57:21.000+0200, duration5=1119 s, timestamp4=2016-05-13T14:01:48.000+0200, duration4=1030 s, timestamp3=2016-09-07T12:27:52.000+0200, duration7=686 s, timestamp2=2019-03-31T14:32:03.000+0200, duration6=646 s, entries=10, obisId=0-0:96.7.19, duration1=3459 s, timestamp9=2016-05-02T09:44:35.000+0200, duration0=2930 s, timestamp8=2016-05-03T12:05:22.000+0200, duration3=717 s, timestamp7=2016-05-03T12:18:45.000+0200, duration2=620 s, timestamp6=2016-05-03T14:33:05.000+0200}) to list of Cosem Objects

In updating entries are assigned to unexisting concatenated variables:

2022-07-01 00:05:11.176 [DEBUG] [mr.internal.handler.DSMRMeterHandler] - Updating state for channel emeter_power_failure_log_timestamp1 to value 2019-08-13T01:03:43.000+0200
2022-07-01 00:05:11.177 [DEBUG] [mr.internal.handler.DSMRMeterHandler] - Updating state for channel emeter_power_failure_log_timestamp1_duration9 to value 242041 s
2022-07-01 00:05:11.177 [DEBUG] [mr.internal.handler.DSMRMeterHandler] - Updating state for channel emeter_power_failure_log_timestamp1_duration9_timestamp0 to value 2021-07-07T13:09:51.000+0200

Maybe in this statement?:
                    if (!entry.getKey().isEmpty()) {
                        /* CosemObject has a specific sub channel */
                        channel += "_" + entry.getKey();

However, it is not a subchannel, but an array of values.

This is where my knowledge of openHAB / java ends. How can we proceed?

Looks like a bug in handling these channels with multiple values. The channels do exist, but the update doesn’t use the correct naming. It keeps appending the key, I’ve created a pull request to fix this. This fix is already merged and available in the snapshot version of openHAB and will be a available on the next release.

Great! Thanks for the fix. I created a testhab environment with openhab (3.4.0~S2990-1) and DSMR Binding 3.4.0.SNAPSHOT. The values in the log items are indeed the same as in the P1 telegram. For my production environment I will wait for the next stable release.