Added support for for Tauron ZE.314 used in Poland. #48
Conversation
There was a problem hiding this comment.
Thanks for your contribution, it looks good. I left a few more comments inline.
Cool to see the same format is being used across Europe now. Do you happen to have any specification documentation about the format as it is used in Poland (or if not, maybe about this meter specifically)? And maybe an example telegram which I can use to test the code later?
| DEFINE_FIELD(meter_time, String, ObisId(1, 0, 0, 9, 1), StringField, 0, 8); | ||
| DEFINE_FIELD(meter_date, String, ObisId(1, 0, 0, 9, 2), StringField, 0, 8); | ||
| DEFINE_FIELD(total_imported_inductive_reactive_energy, FixedValue, ObisId(1, 0, 5, 8, 0), FixedField, units::kvarh, units::kvarh); | ||
| DEFINE_FIELD(total_imported_capacitive_reactive_energy, FixedValue, ObisId(1, 0, 8, 8, 0), FixedField, units::kvarh, units::kvarh); |
There was a problem hiding this comment.
units:kvarh is not defined yet, did you forget to commit that addition maybe?
There was a problem hiding this comment.
Hi
As I know it is from IEC standard:
https://www.promotic.eu/en/pmdoc/Subsystems/Comm/PmDrivers/IEC62056_OBIS.htm
https://www.ungelesen.net/protagWork/media/downloads/solar-steuerung/iec62056-21%7Bed1.0%7Den_.pdf
There is also page from Tauron (one of PL company) and it confirms that OBIS codes are used:
https://www.tauron-dystrybucja.pl/kody-obis
There was a problem hiding this comment.
Yes, it is my mistake with kvarh. It is fixed now.
My meter, ZE.314, from Tauron use EDIS codes, not OBIS, so part A-B: is missing.
So in my code I added to each line that 1-0: part. And with that change I can use DSMR parser. So telegram from my meter is useless for test purposes.
Maybe it could be good to add EDIS support to DSMR parser? I know it is not DSMR specyfic, but, It is best OBIS parser that I found.
| @@ -357,6 +357,13 @@ DEFINE_FIELD(slave_valve_position, uint8_t, ObisId(0, SLAVE_MBUS_ID, 24, 4, 0), | |||
| * E meter) (Note: 4.x spec has "hourly meter reading") */ | |||
| DEFINE_FIELD(slave_delivered, TimestampedFixedValue, ObisId(0, SLAVE_MBUS_ID, 24, 2, 1), TimestampedFixedField, units::m3, units::dm3); | |||
|
|
|||
| /* extra field for Tauron ZE.314 */ | |||
| DEFINE_FIELD(meter_time, String, ObisId(1, 0, 0, 9, 1), StringField, 0, 8); | |||
| DEFINE_FIELD(meter_date, String, ObisId(1, 0, 0, 9, 2), StringField, 0, 8); | |||
There was a problem hiding this comment.
Are these strings always a fixed length? Then maybe it would be good to define a DateField and TimeField similar to the existing TimestampField (which is just a subclass of StringField, so it would work pretty much the same, but might be a bit more clear).
There was a problem hiding this comment.
Yes, it looks like fixed length. OK, I will define DateField and TimeField.
Added fields used in ZE.314 meter by polish Tauron company.