Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Smartmeter-datacollector failed to extract data from HDLC frame #59

Open
urskle opened this issue Jan 28, 2024 · 13 comments
Open

Smartmeter-datacollector failed to extract data from HDLC frame #59

urskle opened this issue Jan 28, 2024 · 13 comments
Assignees
Labels
bug Something isn't working

Comments

@urskle
Copy link

urskle commented Jan 28, 2024

Smartmeter-datacollector shows warnings (smartmeter:Failed to extract data from HDLC frame: 'Invalid Command.' Some data got lost.) , then after a few minutes or hours (irregular intervals) an error (smartmeter:Failed to extract data from HDLC frame: 'Invalid Command.' Some data got lost.).
I have to restart the smartmeter-datacollector service, then the data are delivered without any problem for a few minutes or hours. Attached the log file.
I wonder why this behaviour is happening. I am running smartmeter-datacollector on a Raspberry Pi 3B with an ISKRA AM 550.
Any hints and suggestions are welcome!

main.log

@raymar9
Copy link
Contributor

raymar9 commented Jan 29, 2024

Smartmeter-datacollector should recover after such warning or error and continue parsing data. To get more information on this matter I require some DEBUG log. Please modify the configuration (either manually in /var/lib/smartmeter-datacollector/datacollector.ini or with the web configurator) and set the log level to DEBUG (see also https://github.com/scs/smartmeter-datacollector/wiki/Configuration#logging-settings) Restart the software and wait until the problem appears again.

What version of the software do you use?

@raymar9 raymar9 added the bug Something isn't working label Jan 29, 2024
@urskle
Copy link
Author

urskle commented Jan 30, 2024 via email

@raymar9
Copy link
Contributor

raymar9 commented Jan 31, 2024

Is there any more log after this listing of raw values at 21:40:17? Or does the software just freezes there?
I see the error "ERROR:smartmeter:DLMS data is no list or empty list. Not parsable.". But the software should recover from that. However maybe there is a bug concerning switching to system time as noted in the warning following. I will look into that.

@urskle
Copy link
Author

urskle commented Jan 31, 2024 via email

@raymar9
Copy link
Contributor

raymar9 commented Jan 31, 2024

Can you also provide some of the DEBUG log following after 21:40:17?

@urskle
Copy link
Author

urskle commented Jan 31, 2024 via email

@urskle
Copy link
Author

urskle commented Jan 31, 2024 via email

@urskle
Copy link
Author

urskle commented Jan 31, 2024 via email

@raymar9
Copy link
Contributor

raymar9 commented Jan 31, 2024

I think I found a / the problem: when receiving non-parsable data from the smartmeter (ERROR in log) the datacollector falls back to system time (followup WARNING in log). However if you compare the unix timestamps which accompany the data sent to the MQTT broker and therefore the influxDB before and after 21:40:17 you detect a backwards time leap about 1 hour. So we feed non-monotonic time samples into the database. Somehow the system time is not correctly determined in the datacollector service. I'll look into that. You would might find the data 1 hour earlier if the influx db weren't crashing.

However I'm still not sure why the influxDB crashes. It should handle a request from Grafana when no data is available in the requested timespan. The error from telegraf (which sits between the MQTT broker and the influxDB) probably only appears because of the crashed influxdb which telegraf cannot connect to.

First check your time settings (timezone) on the RPi with timedatectl and alter them if incorrect.
A workaround for now that you can try is to manually edit the config file stored at /var/lib/smartmeter-datacollector/datacollector.ini by adding systemtime = true to the smartmeter config section. This enforces using system time from the beginning which mitigates the time leap problem.

@urskle
Copy link
Author

urskle commented Jan 31, 2024 via email

@raymar9 raymar9 self-assigned this Feb 1, 2024
@urskle
Copy link
Author

urskle commented Feb 4, 2024 via email

@raymar9
Copy link
Contributor

raymar9 commented Feb 5, 2024

Add systemtime = true to the reader0 section.

@urskle
Copy link
Author

urskle commented Feb 5, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants