rtlamr2mqtt: Software gets stuck until restart

Is there anything that can be done to prevent the container from being stuck and not processing anything until I restart? Here is an example of my log:

You can see march 2nd it stopped updating, and something is not running. Then I just restarted it and it continues on again until it gets stuck. Usually lasts a few hours to a day before it is stuck like this.

Let me know what info you need from me.

[2022-03-02 02:40:54] {"Time":"2022-03-02T02:40:54.85853604Z","Offset":0,"Length":0,"Type":"SCM+","Message":{"FrameSync":5795,"ProtocolID":30,"EndpointType":171,"EndpointID":12345,"Consumption":189410,"Tamper":18688,"PacketCRC":39682}}
[2022-03-02 02:40:54] Meter "12345" - Consumption 189410. Sending value to MQTT.
[2022-03-02 02:40:54] Predicted reading: 189333.7495830916 - Actual reading: 189410
[2022-03-02 02:40:54] Grow rate avg: 39.44736842105263
[2022-03-02 02:40:54] Possible anomaly detected!
[2022-03-02 02:40:54] Distance from prediction: 76.25041690841317
[2022-03-02 02:40:54] Threshold for anomaly: 189373.19695151263
[2022-03-02 02:40:54] Sending message to MQTT:
[2022-03-02 02:40:54]  > topic => rtlamr/12345/attributes
[2022-03-02 02:40:54]  > payload => {"Message Type": "SCM+", "Predicted": 189333.7495830916, "Anomaly": true, "FrameSync": 5795, "ProtocolID": 30, "EndpointType": 171, "EndpointID": 12345, "Consumption": 189410, "Tamper": 18688, "PacketCRC": 39682}
[2022-03-02 02:40:54]  > retain => True
[2022-03-02 02:40:54] Sending message to MQTT:
[2022-03-02 02:40:54]  > topic => rtlamr/12345/state
[2022-03-02 02:40:54]  > payload => 189410
[2022-03-02 02:40:54]  > retain => True
[2022-03-02 02:40:54] Sleep_for defined, time to sleep!
[2022-03-02 02:40:54] Terminating all subprocess...
[2022-03-02 02:40:54] Kill process called.
[2022-03-02 02:40:54] Killing RTL_TCP...
[2022-03-02 02:40:59] Killed.
[2022-03-02 02:40:59] Killing RTLAMR...
[2022-03-02 02:40:59] Killed in the first attempt.
[2022-03-02 02:40:59] Sleeping for 300 seconds, see you later...
[2022-03-02 02:46:00] Sending message to MQTT:
[2022-03-02 02:46:00]  > topic => rtlamr/status
[2022-03-02 02:46:00]  > payload => online
[2022-03-02 02:46:00]  > retain => True
[2022-03-02 02:46:00] Trying to start RTL_TCP: /usr/bin/rtl_tcp -s 2048000
[2022-03-02 02:46:00] RTL_TCP started with PID 1569
[2022-03-02 02:46:05] RTL_TCP is ready to receive connections!
[2022-03-02 02:46:05] Trying to start RTLAMR: /usr/bin/rtlamr -msgtype=scm+ -format=json -filterid=12345 -unique=true -symbollength=32
[2022-03-02 02:46:05] RTLAMR started with PID 1574
[2022-03-02 02:46:05] 02:46:05.104925 decode.go:45: CenterFreq: 912600155
[2022-03-02 02:46:05] 02:46:05.105145 decode.go:46: SampleRate: 1048576
[2022-03-02 02:46:05] 02:46:05.105158 decode.go:47: DataRate: 32768
[2022-03-02 02:46:05] 02:46:05.105168 decode.go:48: ChipLength: 32
[2022-03-02 02:46:05] 02:46:05.105179 decode.go:49: PreambleSymbols: 16
[2022-03-02 02:46:05] 02:46:05.105189 decode.go:50: PreambleLength: 1024
[2022-03-02 02:46:05] 02:46:05.105199 decode.go:51: PacketSymbols: 128
[2022-03-02 02:46:05] 02:46:05.105209 decode.go:52: PacketLength: 8192
[2022-03-02 02:46:05] 02:46:05.105222 decode.go:59: Protocols: scm+
[2022-03-02 02:46:05] 02:46:05.105233 decode.go:60: Preambles: 0001011010100011
**[2022-03-02 02:46:05] 02:46:05.105244 main.go:124: GainCount: 29
[2022-03-05 00:57:05] Shutdown detected, killing process.**
[2022-03-05 00:57:05] Killing RTL_TCP...
[2022-03-05 00:57:10] Killed.
[2022-03-05 00:57:10] Killing RTLAMR...
[2022-03-05 00:57:10] Killed in the first attempt.
[2022-03-05 00:57:10] Graceful shutdown.
[2022-03-05 00:57:10] Sending message to MQTT:
[2022-03-05 00:57:10]  > topic => rtlamr/status
[2022-03-05 00:57:10]  > payload => offline
[2022-03-05 00:57:10]  > retain => True
[2022-03-05 00:57:14] Configured MQTT sender:
[2022-03-05 00:57:14]  > hostname => 10.150.1.231
[2022-03-05 00:57:14]  > port => 8045
[2022-03-05 00:57:14]  > username => None
[2022-03-05 00:57:14]  > client_id => rtlamr2mqtt
[2022-03-05 00:57:14] Sending message to MQTT:
[2022-03-05 00:57:14]  > topic => rtlamr/status
[2022-03-05 00:57:14]  > payload => online
[2022-03-05 00:57:14]  > retain => True
[2022-03-05 00:57:14] Trying to start RTL_TCP: /usr/bin/rtl_tcp -s 2048000
[2022-03-05 00:57:14] RTL_TCP started with PID 8
[2022-03-05 00:57:19] RTL_TCP is ready to receive connections!
[2022-03-05 00:57:19] Trying to start RTLAMR: /usr/bin/rtlamr -msgtype=scm+ -format=json -filterid=12345 -unique=true -symbollength=32
[2022-03-05 00:57:19] RTLAMR started with PID 13
[2022-03-05 00:57:19] 00:57:19.161118 decode.go:45: CenterFreq: 912600155
[2022-03-05 00:57:19] 00:57:19.162200 decode.go:46: SampleRate: 1048576
[2022-03-05 00:57:19] 00:57:19.162658 decode.go:47: DataRate: 32768
[2022-03-05 00:57:19] 00:57:19.162974 decode.go:48: ChipLength: 32
[2022-03-05 00:57:19] 00:57:19.162999 decode.go:49: PreambleSymbols: 16
[2022-03-05 00:57:19] 00:57:19.163014 decode.go:50: PreambleLength: 1024
[2022-03-05 00:57:19] 00:57:19.163025 decode.go:51: PacketSymbols: 128
[2022-03-05 00:57:19] 00:57:19.163037 decode.go:52: PacketLength: 8192
[2022-03-05 00:57:19] 00:57:19.163052 decode.go:59: Protocols: scm+
[2022-03-05 00:57:19] 00:57:19.163063 decode.go:60: Preambles: 0001011010100011
[2022-03-05 00:57:19] 00:57:19.163075 main.go:124: GainCount: 29

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 20 (11 by maintainers)

Most upvoted comments

Function added on #101 Ready to be tested.

If you want to test, use the main tag: docker pull allangood/rtlamr2mqtt:main

allangood on Apr 1, 2022

I too have the “NooElec NESDR Mini” from Amazon. I contacted the manufacturer complaining about the issue of the device failing to respond until I restarted it (after a few hours of it running) and they suggested that it is a power problem from the device I have it plugged into (in my case, a proxmox server). They suggested a powered USB hub. I bought this one on amazon and have been using it for over a week now without the issue occurring.

kspearrin on May 16, 2022

I forgot to mention: To test this new feature you need to add a new parameter reset_usb to the general section:

general:
  sleep_for: 300
  verbosity: debug
  tickle_rtl_tcp: false
  reset_usb: "005:002"

You can get the bus and device number from lsusb

allangood on Apr 2, 2022

Just for reference, the code to reset the USB is this:

    printf("Resetting USB device %s\n", filename);
    rc = ioctl(fd, USBDEVFS_RESET, 0);
    if (rc < 0) {
        perror("Error in ioctl");
        return 1;
    }
    printf("Reset successful\n");

allangood on Apr 1, 2022