Join forces with OpenMQTTGateway

[torwag]

There is another MQTT-Gateway project under active development.

https://github.com/1technophile/OpenMQTTGateway

I believe that both projects address the same idea.
They both developed in different directions

Differences to the MQTT433Gateway

1. Supports officially ESP32 and ESP8266
2. Supports other hardware, BLE, IR, direct Sensors, RFM69, GSM, etc.
3. Programming structure keeps it open for other Protocols as well (Zigbee, Zwave, Enocean)

Differences of this project to the OpenMQTTGateway

1. User interface for configuration (now very newbie friendly)
2. Uses the an own version of the pilight lib and hence supports many 433 MHz devices

I think both projects would benefit from each other and we might have at the end an ultimate Foo2MQTT-Gateway system, which ideally is even newbie friendly enough for non-programmers.

[renearts]

As far as I know the RC-switch library used in that project is not as good as ESPilight, it also does not support the newer KoKo protocols.

[torwag]

Therefore, I would propose to join forces here... why not using the epsilight lib of this project but using the BLE, RFM69 and other modules of the OpenMQTT project. That would bring us the best of both projects

[puuu]

All the magic towards parsing the rf signals will be performed with ESPiLight which based on the protocol implementations of pilight.

ESPiLight is intentionally a library by it's own. Every project is free to use this library and I will happily support this.

But keep in mind that pilight was not developed with micrcocontoller in mind and thus is relativly bulky and memory hungry.

Btw. I would like to see ESPiLight support in esphomelib.

[1technophile]

Hello,

Thanks for your library @puu, for your information we integrated it into OMG a few weeks ago:

Of course it will not work on an uno but we can use it with ESP.

[torwag]

@1technophile you beat me, as I was just going to post this.
Now, in my opinion we have a project with a nice fancy GUI for config (even after flashing) and platformio support (which I find much better rather then the arduino gui, if only for the dependency checks).
And we have a project which goes much more further and above 433 MHz devices most important being BLE.
Maybe there are even more ways to join both projects?

[puuu]

@1technophile cool, ESPiLight is already integrated into OpenMQTTGateway, this is amazing!

I had a short look into the integration. As I understood, you need to select between rcswitch and ESPiLight but can not run both with the same receiver/transmitter? I think, it would be interesting to receive/transmit with one implementation and parse with both. Unfortunately (as far as I understand), the raw data formats are different and rcswitch does not support impulse trains as implemented in ESPiLight. The pulse trains (array of pulses in µs) are at a lower abstraction level, then the rcswitch data formats. Thus, to provide interoperability between ESPiLight and rcswitch, pulse train support must be implemented into rcswitch.

If you interested in a web frontend, please have a look to this project or blinkenhat. @janLo did a great job by implementing a lightweight rest api in combination with a feature full javascript web frontend.

[1technophile]

Hi,
it's cool your library will add more protocols compatible!

now pilight is integrated I need to do some test to see how it behaves with OMG, and in particular the overlap differences in terms of protocol scopes with rcswitch.
I think that it should cover more protocol, and in this case it could replace rcswitch for the bigger processors.

I will take a look to this frontend. Thanks for the infos