Before commenting read Forum rules
Don't comment the topic if you have a new question.
You can create a new topic selecting correct category from Gurux Forum and then create a new topic selecting "New Topic" from the top left.
Forums
Hi,
I was very happy to see that you provided a full example to receive and decrypt push messages from the meter with python a couple of days ago!
but after testing it I noticed that you read the serial until you encounter 7E but this byte can also occur as part of the "regular packet". its even quite often because if I let the python push listener run even though I get a push message every second, only once every 20 seconds a packet is received correctly and can be decrypted.
this issue bugged me also while trying to implement a simple serial reader script myself... and when I saw you provided an example I was hopefull that you figured it out how to read the push packet without relying on "reading until 7E" but instead something like... buffer the serial input until its a correct HDLC packet (with matching CRC and length data etc.)
I'm not sure how to tackle this problem so that its solved "correctly".
Maybe its something like: Read the serial and if the first byte you read is NOT 7E stop reading because we are "in the middle" of a packet.. (there is still the edge case that we could start reading in the middle of a serial burst and it COULD start with a 7E...)
so maybe the lib should then read the next bytes where the length of the whole packet is defined and then serial read only for this amount? so its save to assume that a whole DLMS push packet is in the buffer?
Happy for your thoughts on this...
cheers,
Tobias
Hi Tobias,
Hi Tobias,
Can you post one of the failed messages here so we can test with that?
BR,
Mikko
Hey,
Hey,
I've uploaded the file for you here:
https://upload.bitconnect.at/files/output.txt
the command was:
python3 main.py -S /dev/ttyS7 -t Verbose -B X...X
and by the way:
on the WSL (windows subsystem on linux) bash the "available devices" is always empty.
but for example serial.tools.list_ports.comports() lists them all.
my naive approach was to just read 105 Bytes and check if first and last byte are the same... but I also saw that not all austrian smart meters send 105 Bytes long messages...
cheers,
Tobias
Hello Tobias, I'm from
Hello Tobias, I'm from Austria and I'm currently reading my smart meter. Can you give me a link for example a code?
And if you want, we can also keep in touch via e-mail
Hi, you need help with your
Hi, you need help with your mbus interface so you should check out this:
http://www.gurux.fi/comment/19798#comment-19798
Hey Mikko,
Hey Mikko,
do you have an Idea how to go about reading the serial interface? since reading until 7E does not work... maybe the only way is to read and interpret the first bytes where the length is encoded...
Hi,
Hi,
It depends on what kind of framing your meter is using.
Are you receiving data that starts with 0x7E or something else?
BR,
Mikko
yes it starts and ends with
yes it starts and ends with 7E but 7E can also be part of the message so reading until 7E is not an option.
Hi,
Hi,
Gurux DLMS client can handle this. Just read bytes from the serial port and use GXDLMSClient.GetData method to get parsed value.
BR,
Mikko
yeah, isn't this what this
yeah, isn't this what this script is doing?
https://github.com/Gurux/Gurux.DLMS.Python/blob/master/Gurux.DLMS.Push…
but this produces the output I sent above since it seems to not read some packages in full since the messages contain 7E also as part of the message...
Hi,
Hi,
This waits for 0x7e before the client tries to parse the data. Data parsing is done in GXDLMSClient getData-method. Use GXDLMSClient to parse the data. There are several reasons that might cause problems with data reading and GXDLMSClient can handle them all.
BR,
Mikko
Hi,
Hi,
I'm not sure I can follow what you mean...
I just thought... isn't it inherently a problem to set end of packet to 0x7e but it can be part of the message itself so a lot of databursts will not be decryptable because they are either not read fully and/or started to be read in the middle of a packet..
and isn't there another/better way to read the serial and pass it on to the GXDLMSClient? or should this demo script actually read more data if it realises the data received so far is not a full package?
Hi,
Hi,
The parser can handle this. This is happening all the time.
The serial port component reads data until 0x7E and it doesn't understand from DLMS. GXDLMSClient will handle DLMS parsing and it will check if all the data is received and check the CRC, etc.
BR,
Mikko
Okay so its expected that
Okay so its expected that like 30 - 40% of "received" triggers will not yield any data... so even though the meter would send a packet ever second - on average only like every 10 seconds the script will output usable data...