NorthernMan54
commented
3 years ago Would a better approach be to use the MQTT mode of rtl_433 then use something like homebridge-mqttthings or node-red and HomeKit-bridged to create the devices?
That way you aren't tied to homebridge-rtl with your dongles and just need to normalize everything to MQTT based messaging? Since I wrote this package, I have started normalizing onto MQTT as my message transport of choice for my sensors ( openmqttgateway ) and devices ( Tasmota ).
Hello, I wanted to start a discussion about the best way to accommodate more advanced functionality. I'm new to homebridge (quite familiar with rtl_433 though) so some of this may be accomplished in different ways but I'm envisioning the following scenarios:
1) a user wants to use a single dongle/process for both homebridge and another supported rtl_433 output (eg: influxdb) 2) a user wants to use rtl_tcp as the source 'dongle' for rtl_433 3a) a user wants to listen on a non-default frequency (eg 345 mhz) 3b) a user wants to use multiple dongles to listen to multiple frequencies (433 for temp/humidity sensors and 345 for honeywell door sensors, for example)
I understand there may be certain flags that could break this plugin (if I tell rtl_433 to send everything as farenheit, will the plugin be able to handle that?)
Is it possible/adviced to install homebridge-rtl multiple times to accommodate multiple dongles listening on different frequencies? If so, I think most of this, if not all, could be implemented by editing the line that calls rtl_433. That being said, a config file, or option to use one, might be a cleaner solution than mucking around in the source code. Is there an option to not log the 'unknown ID' messages?
I want to also add that this is a really cool project, rtl_433 has long been one of my all-time favorite open source projects, and this plugin is a great example of why.