halfbakery

I've had no time to check this problem yet, but I think this problem could lie within the firmware of the robot. Sometimes my own robot displays the map in...

> Interesting stuff. If I understand correctly you propose to split outputs into "payload generator/consumer" and "message transport", right? Definetely. The message transport parts are easily exendible, e.g. sending over...

> Thinking about this, independant of the behind-the-scenes, it might be easier for users if we only offer the -F mqtt... option and then on each additional instance lookup if...

One of the reasons behind the -L option is to let users use mqtt input without mqtt output. It's nicer than the hack in my mqtt_rfraw implementation.

Setting up a link could require a lot of parameters (e.g. TLS has a lot of options), I think it's nicer and gives us an opportunity to reuse, e.g.: ```...

Almost done... The MQTT driver has been split and refactored into a link driver and an output driver. The link driver is reuseable, so the ``` rtl_433 -L conn=mqtt: -F...

Why the -L option is useful? As I said earlier, transport link merging has been supported since the first version, so `-F csv:/tmp/a -F json:/tmp/a` will use the same transport...

output transport link / format combinations (with areas of improvement): | | json | csv | kv | syslog | mqtt(nested) |urlencoded | |--------|:------:|:----:|:---:|:---------:|:-----------------:|:---------------:| | file | X | X...

I've seen the new http server. Another good example for the -L option: :-) * instead of a hard-coded outputs, you can configure individually, e.g.: `-L server=http://0.0.0.0:8433 -F server/json:/path-for-device1,filter-device=wt1024 -F...

My idea is to make the new http-server configurable (not now, just as a possibility). I know the current endpoint layout is static, but it needn't be: * define event...