Home Assistant Add-On

[AnthonyPluth]

Would you open to making your project installable as a Home Assistant Add-On? The amount of work to do so is pretty minimal and if I can get a better understanding of your use-case, I think I can put this together in a way that works with your existing workflow.

[allangood]

Hello @AnthonyPluth ,

Thank you for your contributions.

From the feedback I have received so far, many users uses this project as a standalone container in some remote machine, like myself.

I have my HA instance running in a NUC in my Living Room and I have an Orange Pi running this docker container in my basement. That Pi in the basement doesn't have HA. How this would work been a HA Add-On in a machine without HA?

Unless I create some sort of API to make it possible to configure it remotely what would open a new world of work and security problems that I don't want to deal with...

[AnthonyPluth]

@allangood It should be possible to use the same docker image for both a standalone service and an Add-On. By doing this, there shouldn't be any change in maintainability

[allangood]

I don't have experience creating HA Add-ons.
The previous PR had changes to remove YAML what makes configuration much difficult.
How does it will work?

[AnthonyPluth]

Yeah sorry about that, that was a bit aggressive. Now that I understand your use case, I think a better solution would be to add the option to configure via json with the default being yaml

[allangood]

Let me create a new branch and we can work on this together, what do you thing?

[AnthonyPluth]

let's do it!

[allangood]

I have been fixing a few problems reported in the last days, the project has changed a bit since the last PR.

A new branch ha-addon has been created.

[allangood]

Merged your PR and merged main with ha-addon branch.
Now I am fixing some issues to make Travis happy again!

Thank you for your contribution!

[allangood]

Travis is happy again.
Now I will be working to fix the github action to push all branches to a tag on GitHub!

Let's see how it goes!

[allangood]

Finally I've managed to fix my Github action to build multi-arch containers using only new actions. All deprecated action have been removed.
Merges to the ha-addon branch will trigger a new build/push to Docker.

[allangood]

@AnthonyPluth , the first image has been pushed to Dockerhub and it is ready to be tested!

https://hub.docker.com/r/allangood/rtlamr2mqtt/tags?page=1&name=ha-addon

Thank you very much for all your effort! :)

[allangood]

@AnthonyPluth ,I don't have or use HASSIO, could test the image, please?

[AnthonyPluth]

Sorry for the delay - this does work, we just need to update the json config schema to match the updated yaml config. I'll try to get a PR in for this tomorrow.

One more thing - you don't need to build an image for the addon; this gets built locally when installed

[datdamnzotz]

Works just fine - Hassio Home Assistant OS 6.4 supervisor-2021.09.6 on core-2021.9.7

Took the directory in this branch https://github.com/allangood/rtlamr2mqtt/tree/ha-addon/rtlamr2mqtt-addon and dropped it in add-ons.
Ran the Supervisor -> Addons -> Reload.
Installed it.

I had to update config.json to (was complaining about normal,test) loaded it up and away she went.

    "name": "rtlamr2mqtt",
    "version": "0.10.3",
    "slug": "rtlamr2mqtt",
    "panel_icon": "mdi:gauge",
    "description": "RTLAMR to MQTT Bridge",
    "startup": "application",
    "boot": "auto",
    "map": [
        "config:rw"
    ],
    "url": "https://gitlab.com/abpluth/rtlamr2mqtt",
    "uart": true,
    "udev": true,
    "usb": true,
    "host_network": false,
    "arch": [
        "amd64",
        "armv7",
        "i386"
    ],
    "services": ["mqtt:need"],
    "options": {
        "general": {
            "sleep_for": 300,
            "mode": "normal",
            "debug": false
        },
        "mqtt": {
            "host": "hassio.local",
            "port": 1883,
            "user": "",
            "password": "",
            "ha_autodiscovery": true,
            "ha_autodiscovery_topic": "homeassistant"
        },
        "rtl": {
            "rtltcp": "-s 2048000",
            "rtlamr": "-unique=true"
        },
        "meters": [
            {
                "id": 123456789,
                "protocol": "scm",
                "name": "gas_meter",
                "format": "####.###",
                "unit_of_measurement": "m³",
                "icon": "mdi:gas_canister"
            }
        ]
    },
    "schema": {
        "general": {
            "sleep_for": "int",
            "mode": "str",
            "debug": "bool?"
        },
        "mqtt": {
            "host": "str?",
            "port": "int?",
            "user": "str?",
            "password": "str?",
            "ha_autodiscovery": "bool?",
            "ha_autodiscovery_topic": "str?"
        },
        "rtl": {
            "rtltcp": "str?",
            "rtlamr": "str?"
        },
        "meters": [
            {
                "id": "int",
                "protocol": "list(idm|netidm|r900|r900bcd|scm|scm+)",
                "name": "str",
                "format": "str?",
                "unit_of_measurement": "str",
                "icon": "str"
            }
        ]
    }
}

I assume we are terminating and just relaunching after 5 mins?

RTL_TCP started with PID 8
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Tuned to 100000000 Hz.
listening...
RTLAMR started with PID 13
Allocating 15 zero-copy buffers
Meter "32907488" - Consumption 113810. Sending value to MQTT.
Sleep_for defined, time to sleep!
Terminating all subprocess...
Signal caught, exiting!
Signal caught, exiting!
Signal caught, exiting!
RTL_TCP terminated.
RTLAMR terminated.
Sleeping for 300 seconds, see you later...
RTL_TCP started with PID 24
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Tuned to 100000000 Hz.
listening...
RTLAMR started with PID 29
Allocating 15 zero-copy buffers
Meter "32907488" - Consumption 113812. Sending value to MQTT.
Sleep_for defined, time to sleep!
Terminating all subprocess...
Signal caught, exiting!
Signal caught, exiting!
Signal caught, exiting!
RTL_TCP terminated.
RTLAMR terminated.
Sleeping for 300 seconds, see you later...```

[allangood]

Yes, this behavior can be controlled by the sleep_for parameter.
This parameter is there to save some resources. Many meters doesn't send updates in real time or sometimes too many small updates are not desired.

[allangood]

Thank you very much @AnthonyPluth for your contribution!
I am closing this issue now. Feel free to re-open or open new issues!

Regards

[jeffeb3]

Oh man, you two are doing exactly what I was working on today. Small world, I guess.

I was looking at the config.json and the dockerfiles. I will try your add on shortly, but I just wanted to point a few things out I saw. These are either very clever critiques, or most likely, something you know that I don't 😄

In the config.json, you have uart: true, udev: true and usb: true. In the testing I've done, I only needed usb: true. Are those other permissions needed for other platforms? Other sdrs?

The docker file I wrote uses go get to install rtlasm. Is there a reason why you did the tarball? Was that just to grab a released version instead of the latest? This is what my Dockerfile looks like:

ARG BUILD_FROM
FROM $BUILD_FROM

ENV LANG C.UTF-8

# Install requirements for add-on
RUN apk add --no-cache \
 python3 \
 py3-pip \
 go \
 rtl-sdr

RUN pip3 install paho-mqtt

RUN go get github.com/bemasher/rtlamr

WORKDIR /data

# Copy data for add-on
COPY rtlamr_ha /

RUN chmod a+x /rtlamr_ha

CMD [ "/rtlamr_ha" ]

That's only for the add on. I wasn't planning on making a standalone docker image.

I hope I can quit doing it. It looks like you two have done a lot of the hard work already. I am just hoping something I learned in the last few days is useful somehow 🤷

[AnthonyPluth]

@jeffeb3 Some of the changes I made were inspired by this repo. With that said, udev and uart are helpful if you have multiple usb devices as it allows you can specify the specific device you want to use. So rather than specifying /dev/ttyUSB0, you would do /dev/serial/by-id/xxxxxxxx-xxxxxxx. Since we're now looking at a 'serial' port, we need uart. At least this is my understanding of how it works but please correct me if I'm mistaken.

I'll defer to @allangood regarding using tarball over go

[allangood]

hi @jeffeb3 , the main reason for downloading the tar.gz is because a problem in the rtlamr (see: bemasher/rtlamr#57). During my tests I've experienced the same issue and the CPU was pinned during the execution.
This issue is related to cross compiling and only seems to happen when using tool chain like dockerx or qemu. This is how I push multi-arch images to DockerHub.

The first try to fix this was when I've introduced the sleep_for parameter. This helped to keep the CPU down for a few minutes but it actually doesn't address the problem, just make it less apparent.
Using the tar.gz, the problem went completely away.

As said by @AnthonyPluth , the addon build itself in the client machine, using the native tools. Probably the problem would not happen this way.

My first version had both rtl_tcp and rtlamr compiled from the source, but due to the problems I had with cross-compiling using dockerx and qemu I have opted to use the packaged version.

[allangood]

@jeffeb3 you can check my first Dockerfile version here:
https://github.com/allangood/rtlamr2mqtt/blob/0a7332bd9fb394d03d471d36046d874766f82acb/Dockerfile

[jeffeb3]

Great. You are all over it then. I'll keep poking at it and hopefully I can add value to the project.

[allangood]

@jeffeb3 your question made me to investigate this a bit further, I am doing more tests with compiling everything (the old Dockerfile) and see if the error persists after I changed the Github actions to ditch dockerx and use qemu instead.

I may revert the Dockerfile to what it was before! :)

Thank you for your suggestion!

[allangood]

After a few tests, looks like the new settings for the Github Actions doesn't show the cross-compiling problem for rtlamr.

This is what my RPi looks like running with the new Dockerfile version:

Everything looks good. :)