halfbakery

From my point of view, this PR is ready to integrate. The code compiles and the tests are fine (except the maintainer_update). There are output modules which haven't been converted...

> The "link" abstraction is really interesting. But e.g. I need to ponder what this offers for the simple stuff like KV and CSV. Maybe this should just be JSON...

> Intriguing. > > Could you post some brief instructions? > > e.g. Do I need to manually put the rf bridge into rfraw 177 mode or will that be...

> Interesting proof-of-concept. Using an output module to feed input data seems hacky though ;) Yes, but: * I couldn't find any abstraction layer for input devices * The MQTT...

Busy week, but I'm back: - found my second sonoff rf-bridge device - did some development and testing on the Portisch firmware - bricked the second sonoff rf-bridge device too...

I gave it a second look, and maybe using file_info_t->raw_format can be a solution? (keeping file_info_t->format == PULSE_OOK and settings file_info_t->raw_format to PULSE_RFRAW). The raw_format field is there, but used...

I was busy fixing the the TAB/space issue when you mentioned it :-) The realloc()s are checked, but both of them are in the same if. Maybe that's the problem....

The mainloop is simplified, merged back to the regular file loop. Now the usage is the following: ``` rtl_433 -F mqtt -F kv -r mqtt/rfraw:tele/rf-bridge0/RESULT ``` I hope you'll find...

Is there something to check? I have an idea how to remove the I/O layer from outputs and create an input layer, but I don't want to duplicate effort.

I hope I'll have some time in the near future to rework this PR. :-)