My suggestion was going to be to get it working via DNS.
The DNSmasq addon would have been my 1st suggestion (although I have no experience with it personally).
Is there a reason why you cannot resolve your own domain to your external IP and configure dasher with that?
Or configure dasher with internal IP?
Both work for me. I guess if your router is not supporting hairpin NAT then the 1st would not work.
With docker you can pass arguments to add hosts to etc hosts on run time like this: --add-host github.com:192.30.253.113
But I’m not sure if hassio add-ons support this arg. I didn’t see anywhere in config to set it, and it probably because working DNS is expected.
Configuring with an internal IP didn’t work because of https. Dasher throws an error because the ssl certificate does not match the web page.
I’m not sure what resolving my own domain to the external IP refers to. If you mean simply using the external IP address in the dasher configuration, for whatever reason it does not resolve on my network and simply times out, so I guess my router (Google Wifi) doesn’t support hairpin NAT. I’ve noticed the same behavior on my Windows PC and had already updated my host files on Windows machines as necessary.
DNS seems to be working well though, and I haven’t noticed any slowdown from adding the extra hop. Thanks for the response.
I’ve just updated my repo to include an add-on that uses rtl_433 to provide a 433MHz RF to MQTT bridge.
This allows use of a cheap USB DVB-T tuner (based on RTL chipset) to be re-purposed as a software defined radio… in this case specifically to sniff and decode 433MHz signals.
Currently 93 protocols are supported.
Addon details here:
rtl_433 details, including supported protocol list here:
Note that the addon requires a subdirectory to be created in your hassio config dir that will include the script that executes rtl_433. This is to provide flexibility for the numerous features that rtl_433 provides, and any other flexibility that script provides - e.g.
e.g.
alternative frequencies/frequency hopping
using multiple protocols
parsing/transforming JSON before publishing to topic etc
Did you copy the rtl2mqtt.sh into hassio config dir per the readme step 3?
Copy rtl2mqtt.sh to your hass.io config dir in a subdir called rtl4332mqtt. i.e. …/config/rtl4332mqtt/rtl2mqtt.sh This allows you to edit the start script if you need to make any changes
The reason for this is that rtl_433 is flexible and I saw lots of ways people are using it.
e.g. maybe you want to use a different freq (e.g. Honeywell @ 345mhz) or you want to hop frequencies, or you want to use two protocols etc.
So I decided to keep the script outside of the docker container so people can modify it as needed.
This is where is gets a bit harder to debug…
Are you running hassio on resinos - ie from the Raspberry Pi image?
If so case I’m not sure how/if I can help debug as I am running hassio on ubuntu.
Its possible that resinos does not have the necessary RTL DVB drivers/kernel modules.
If you are running on a standard linux you can check that a device was found with lsusb.
You should see “Realtek Semiconductor Corp. RTL2838 DVB-T”
e.g.:
james@hassio:~$ lsusb
Bus 001 Device 007: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
With hassio resinos/image you can check this with the terminal addon from here:
In the terminal run lsusb:
➜ / lsusb
Bus 001 Device 007: ID 0bda:2838
Bus 002 Device 002: ID 0e0f:0003
Bus 002 Device 003: ID 0e0f:0002
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0001
Not sure how far this gets us with debugging, but it’s a start.
Could be that the USB device ID will still be shown even if the kernel mod/drivers are not loaded. I don’t know I’m afraid.
If you are running rpi image maybe there are some others on in the community here that can help further?