I’m getting the same error message as Powskierman. I had the add on working on a previous installation, but I’m in the process of upgrading to running Home Assistant from a Raspberry Pi 4 using an SSD.
I’m running Home Assistant supervisor-2021.03.6 on a Docker version 20.10.5 installation. I just tried again today and I still get the same message about Can’t build 74930c0d/armv7-addon-rtl433:0.1.2:
@allmyhinges Hi again Peter, the fix you made for my WH51 moisture sensors work great, I do have one small issue though.
For some reason the battery level on the sensors are all either 1% or 100% there is never anything in between, is this an issue with the sensor itself or is there something else going on?
Hi Jon, based on a log snippet you included in your initial post, it looks like the template is receiving a battery_ok value from the sensor (which I’m guessing is either set to 0 or 1) and turning it into a percentage using a somewhat silly formula: "value_template": "{{ float(value|int) * 99 + 1 }}" - that’s how you end up with either 0*99+1 = 1% or 1*99+1 = 100%. The sensor itself probably isn’t reporting actual battery charge percentage - I have the same situation with my Acurite temp/humidity sensors, btw.
Sorry to hear you are running into issues with the install. I haven’t been able to reproduce the error, unfortunately. I’m running hass OS on RPi4, with latest supervisor. Rebuilding the add-on works fine on my end.
Is your error message exactly same as Powskierman’s? If so, could you try downloading https://dl-cdn.alpinelinux.org/alpine/v3.13/main/armv7/APKINDEX.tar.gz in your browser and let me know whether that returns an error for you?
@allmyhinges I see now, would it be more appropriate to calculate the battery level based on the battery_mV value that the sensor is reporting?
I was able to download the file without any issues. I tried to install it but I’m really new to all this Linux stuff and don’t know how to do much at this point in time.
This is the log message I get after clicking install.
21-03-31 19:21:13 ERROR (SyncWorker_0) [supervisor.docker.addon] Can’t build 74930c0d/armv7-addon-rtl433:0.1.2: The command ‘/bin/ash -o pipefail -c apk add --no-cache --virtual build-deps alpine-sdk cmake git libusb-dev && mkdir /tmp/src && cd /tmp/src && git clone git://git.osmocom.org/rtl-sdr.git && mkdir /tmp/src/rtl-sdr/build && cd /tmp/src/rtl-sdr/build && cmake …/ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr/local && make && make install && chmod +s /usr/local/bin/rtl_* && cd /tmp/src/ && git clone https://github.com/merbanan/rtl_433 && cd rtl_433/ && mkdir build && cd build && cmake …/ && make && make install && apk del build-deps && rm -r /tmp/src && apk add --no-cache libusb’ returned a non-zero code: 5
21-03-31 19:21:13 ERROR (SyncWorker_0) [supervisor.docker.addon] Build log:
Step 1/15 : ARG BUILD_FROM
Step 2/15 : FROM $BUILD_FROM
—> c04f52c3c7ff
Step 3/15 : ENV LANG C.UTF-8
—> [Warning] The requested image’s platform (linux/arm) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
—> Running in 1e41ff5faede
Removing intermediate container 1e41ff5faede
—> 79a65e6d7563
Step 4/15 : MAINTAINER [email protected]
—> [Warning] The requested image’s platform (linux/arm) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
—> Running in ca1fff654abb
Removing intermediate container ca1fff654abb
—> 9ef70cbd0ab0
Step 5/15 : RUN apk add --no-cache --virtual build-deps alpine-sdk cmake git libusb-dev && mkdir /tmp/src && cd /tmp/src && git clone git://git.osmocom.org/rtl-sdr.git && mkdir /tmp/src/rtl-sdr/build && cd /tmp/src/rtl-sdr/build && cmake …/ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr/local && make && make install && chmod +s /usr/local/bin/rtl_* && cd /tmp/src/ && git clone https://github.com/merbanan/rtl_433 && cd rtl_433/ && mkdir build && cd build && cmake …/ && make && make install && apk del build-deps && rm -r /tmp/src && apk add --no-cache libusb
—> [Warning] The requested image’s platform (linux/arm) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
—> Running in 6ac7d6751492
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/main/armv7/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/community/armv7/APKINDEX.tar.gz
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.13/main: temporary error (try again later)
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.13/community: temporary error (try again later)
@allmyhinges Peter do you happen to know if you must have a SDR dongle to use RTL433 or if its possible with just a 433 receiver?
Hey, first, thanks for the awesome work. Through some reading here and a little trial and error I got this reading 915mhz water sensors in my garden and feeing into home assistant.
I grabbed another nooelec stick and was thinking I’d leave one dedicated to 915mhz, and the other for 433 devices, rather than have one radio hop back and forth. Is this a deployment that this plugin supports?
Is it a matter of just listing a “device 0” section in the configuration file followed by a device 1 section? or do I need two instances of the plugin running with two different configuration files?
Not sure - hopefully this list of receivers/dongles that rtl_433 supports will answer your question…
More clues in your latest log output…
—> [Warning] The requested image’s platform (linux/arm) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
I’m sorry that you can’t get the thing running - I haven’t been able to reproduce the problem. I need to do more research…
Reading rtl_433’s docs, I’m not 100% sure whether it supports reading data from multiple dongles at the same time… I suspect not. Unfortunately, I haven’t gotten around to buying another dongle (been meaning to do the same - listen on diff frequencies). Are you able to test this scenario without disrupting your HA setup too much?
Thanks, I know you can call a device at the command line so I assume you could run two processes concurrently with different device IDs.
Yeah, its no problem for me to test if you can point me in a direction.
Of course not,
Just wondered if anyone had tested with any other device than that super limited list — or had an educated guess.
Hi Peter, so I’m a bit more confused now. I was able to copy the input from in the error log in the home assistant terminal (but not including the '/bin/bash -o pipefail -c ') as it doesn’t seem to know what to do with that and it appears to install everything correctly. However, when I go back to the add-on manager and try to install your add-on it still fails and gives the same error message.
So it might be installed, but I’m not sure how to access it. Any further thoughts?
I have both Addons running and publishing on mqtt, but I cant See any Sensors in HA.
Do i have to Set them Manuell? I thought “Auto Discover” should do this Job.
Anyone else having issues with the auto discovery script bailing out?
Starting rtl_433_mqtt_hass.py...
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
self.run()
File "/usr/lib/python3.8/threading.py", line 870, in run
self._target(*self._args, **self._kwargs)
File "/usr/lib/python3.8/site-packages/paho/mqtt/client.py", line 3452, in _thread_main
self.loop_forever(retry_first_connection=True)
File "/usr/lib/python3.8/site-packages/paho/mqtt/client.py", line 1779, in loop_forever
rc = self.loop(timeout, max_packets)
File "/usr/lib/python3.8/site-packages/paho/mqtt/client.py", line 1181, in loop
rc = self.loop_read(max_packets)
File "/usr/lib/python3.8/site-packages/paho/mqtt/client.py", line 1572, in loop_read
rc = self._packet_read()
File "/usr/lib/python3.8/site-packages/paho/mqtt/client.py", line 2310, in _packet_read
rc = self._packet_handle()
File "/usr/lib/python3.8/site-packages/paho/mqtt/client.py", line 2936, in _packet_handle
return self._handle_publish()
File "/usr/lib/python3.8/site-packages/paho/mqtt/client.py", line 3216, in _handle_publish
self._handle_on_message(message)
File "/usr/lib/python3.8/site-packages/paho/mqtt/client.py", line 3444, in _handle_on_message
self.on_message(self, self._userdata, message)
File "/rtl_433_mqtt_hass.py", line 481, in mqtt_message
bridge_event_to_hass(client, topicprefix, data)
File "/rtl_433_mqtt_hass.py", line 562, in bridge_event_to_hass
if publish_config(mqttc, topic, model, instance, mappings[key]):
File "/rtl_433_mqtt_hass.py", line 534, in publish_config
mqttc.publish(path, json.dumps(config), retain=args.retain)
File "/usr/lib/python3.8/site-packages/paho/mqtt/client.py", line 1249, in publish
raise ValueError('Publish topic cannot contain wildcards.')
ValueError: Publish topic cannot contain wildcards.
Found it, a device had a “+” in the name
{"time":"2021-05-24 08:06:56.521611","protocol":154,"model":"SCM+","id":95895498,"ProtocolID":"0x1E","EndpointType":"0x9C","EndpointID":95895498,"Consumption":655037,"Tamper":"0x0C08","PacketCRC":"0xBC10","MeterType":"Gas","mic":"CRC","mod":"ASK","freq":915.21728,"rssi":-7.45925,"snr":19.49981,"noise":-26.9591}
Handling this in the github issue that you opened. Thanks for reaching out.
Sorry, haven’t been able to work on this feature. Naive approach would require the add-on to launch two instances of rtl_433. Brute force: run two copies of the add-on with different command line options, by maybe forking the repo - ugly though…
Apologies for long delay - haven’t had the time to work on this. Asking about some of the errors in the log elsewhere in this forum - maybe someone else has seen this behavior. Will be back to you if/when I hear anything.