Misinterpreted telegram data for two-tariff energy meter

I’m using an EnOcean energy meter Eltako DSZ12D-3x65 A for my photovoltaic system. I’ve configured this as EEP A5-12-01 with two channels for instant power and total usage. The current openHAB implentation (implicitly) assumes that there is only one tariff, whereas the EnOcean device supports two tariffs. Although I’m only using one tariff, the device sends telegram messages for both tariffs. The debug log shows the following messages:

08:42:16.547 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload A50A17F109FFF7600000 for FFF76000 received
08:42:16.755 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - ESP Packet payload A500000019FFF7600000 for FFF76000 received

The first one contains the relevant total usage count for the first tariff (0A17F1 = 661489 / 10 kWh). The second telegram message contains a total usage count of 0 for the (unused) second tariff. The tariff is encoded in the four-bit value following the meter reading according to EnOcean’s EEP specification. The 0 in the first message represents tariff 0, the 1 in the second message tariff 1.

The consequence of this is that the total usage is almost always shown as 0 because the correct value is immediately replaced by the wrong value (0). The validateValue parameter for the channel doesn’t help because it only filters out decreases of less than 1 kWh.

Is there any way to configure the thing or channel to filter out the wrong values other than to create a new item and a rule that eliminates these values?

The short answer is no. You’ll likely have to create a Rule and proxy Item. Some bindings support that sort of thing but most don’t.

Thanks for sparing me the time to search for a different solution. I setup a proxy item and a rule. I don’t like the design. But it didn’t take much time. And it’s working … :slightly_smiling_face:

However, I think that this should bw modified in the binding. If only one tariff is supported, all messages with a value other than 0 should be discarded. Alternatively, you would need to provide separate channels for the different tariffs. The current implementation yields false results.

Anyone can and should file an issue on the openhab-addon repo when they find a problem or something could work better.

You are absolutely right. I have opened an issue.

Hi Dietmar @sheldon,

I have created a PR

Best regards