Support for 0x62 Async transmit/receive to capture DSMR P1 "smart meter" data

[rhpijnacker]

Recently I purchased a RFXtrxLAN with both a RFXtrx443XL and a DSMR P1 cable installed.

After plugging in the P1 cable into my "smart" electricity meter, it sends the data pushed onto the P1 port as type 0x62 package data to the RFXtfx. I would like to process this data in Home Assistant to show the current electricity.

[rhpijnacker]

After reading up on how the RFXtrx module is integrated in Home Assistant, I'm left wondering what would be a good place to fit the decoding of the data packets coming from the DSMR meter.

As can be seen here, the DSMR pushes a multi-line "telegram" on to the P1 port. The RFXcom device converts the lines in this telegram to a sequence of RFX packets with packet type 0x62. To get the full telegram, one would have to collect the sequence of RFX packets until the "Checksum" packet is received, which ends the telegram.

My first thought was to convert each individual entry as a Dsmr SensorPacket without interpreting the data from the telegram. However, this does not fit the current model of the RFXtrx Home Assistant integration very well: the integration expects the pyRFXtrx layer to pass it fully interpreted events, with the measured sensor data in the "values" property.

My second idea was to do the interpretation of the "telegram" data line-by-line in pyRFXtrx and include this in the Dsmr packet / event as the packet's "value". This would yield a stream of events, where some of the events do not contain any value, and others contain at most one value. The nice part about this is that this can be done without waiting for the full telegram to be constructed.
A drawback is that each packet will a different attribute / value pair compared to the rest. This is causing some issues in Home Assistant.

A third idea is to add collect the separate telegram lines until the full telegram is received and only then return a Dsmr Sensor package with all the values filled in in one go. The intermediate events should then contain a packet that is unfinished and thus get discarded by the HA integration.
One problem I can see occurring is that one telegram contains multiple sensor values for the electricity meter, but also from the gas meter and possibly a water meter or more. I'm not sure whether it makes sense to include all of this as values for one individual Dsmr SensorPacket.

[rhpijnacker]

After taking a good look at the dsmr_parser library, I realised that it would be trivial to interpret and skip the bytes added by the RFXtrx integration at the lowest level. That makes it possible to use the existing DSMR integration of Home Assistant instead of the RFXtrx integration.

Would it still make sense to extend the pyRFXtrx library with support for the 0x62 Async packet type?

[ericsche]

Just plug similar tech for my French Smart Meter and the current version of RFXtrx has an issue :

2022-01-17 17:55:26 DEBUG (Thread-3) [RFXtrx] Recv: 0x15 0x60 0x01 0x09 0x09 0xcb 0xf0 0x83 0xfd 0x11 0x01 0x77 0x23 0xeb 0x00 0x00 0x00 0x00 0x0f 0xa0 0x02 0x79
2022-01-17 17:55:26 ERROR (Thread-3) [root] Uncaught thread exception
Traceback (most recent call last):
File "/usr/local/lib/python3.9/threading.py", line 973, in _bootstrap_inner
self.run()
File "/usr/local/lib/python3.9/threading.py", line 910, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python3.9/site-packages/RFXtrx/init.py", line 893, in _connect
event = self.transport.receive_blocking()
File "/usr/local/lib/python3.9/site-packages/RFXtrx/init.py", line 705, in receive_blocking
return self.parse(pkt)
File "/usr/local/lib/python3.9/site-packages/RFXtrx/init.py", line 637, in parse
pkt = lowlevel.parse(data)
File "/usr/local/lib/python3.9/site-packages/RFXtrx/lowlevel.py", line 2750, in parse
pkt.load_receive(data)
File "/usr/local/lib/python3.9/site-packages/RFXtrx/lowlevel.py", line 2196, in load_receive
self.battery = self.rssi_byte & 0x0f
TypeError: unsupported operand type(s) for &: 'NoneType' and 'int'

It seems that is use the same technology to send data :) looking forward for a positive outlook :)

Count me in if you need testing