SX1278 support

[perfrankling]

Describe you new feature you'd like

The SX1278 seems to have similar capabilities as the CC1101, and it is available with ESP32 on a single board (LilyGo LoRa32). There is a project (https://github.com/loopj/open-rts) that implements RTS with both CC1101 and SX1278. It would be great to not have to connect two different boards, and simpler to find a good enclosure if the LilyGo LoRa32 could be used with ESPSomfy-RTS.

[rstrouse]

I'll have a look at it. I haven't played with an SX1278 so I'll see what functions it has.

[rgr101]

+1: I've got some unused Heltec LoRa Boards with SX1278 which I could use for it, and as the board states to be "LoRa" this might be an ideal solution for (multi-story) family house usage without range trouble... ?

[rstrouse]

The biggest issue right now is that I am very close to running out of program space on the device. At least that is true on the ESP32 series chips. I keep looking for places to meaningfully reduce the code size but I suspect that the comms libraries for the chip are the real culprits.

Keep in mind, the LoRa modulation part of that chip really doesn't mean anything since that term is actually discussing something that is not part of the RTS OOK modulation scheme.

[rgr101]

Ah, I see.
I thought, LoRa would mean the chipset provides a stronger radio hardware than others... 🤷‍♂️

And if there's no real advantage with the SX1278, its support doesn't greatly matter at all - I can easily use another board 😁

[rgr101]

Regarding program space issues -

I believe you've developed a really sophisticated and extensive solution providing many simultaneous communication options!

But - could you imagine to isolate some functions, e.g. split it into separate versions (e.g. one only with socket communication, and another only with MQTT)? - I believe in many environments it would be sufficient to only use one communication way (like in my case: I'll use it as a gateway for Loxone by only using HTTP Get... as Loxone still doesn't support MQTT; but if they would, I'd use only MQTT at most instead and not additionally...)

Sure, from a developers perspective this is not at all a desirable option in terms of the complexity of maintaining multiple versions, but short term it might be beneficial for keeping away your imminent space issues 😇 ?

[rstrouse]

I have no desire to support multiple builds of the software. Unfortunately, MQTT actually uses sockets under the hood so there is no savings to the core there. The publish code does chew up some space because it is all string based.

If I were you I would not seek out an MQTT solution when there is a socket option. It's a bit more work but reading off the socket is soooo much more efficient. In many cases MQTT is a solution in search of a problem where its benefits don't really come into play.

[perfrankling]

The biggest issue right now is that I am very close to running out of program space on the device. At least that is true on the ESP32 series chips. I keep looking for places to meaningfully reduce the code size but I suspect that the comms libraries for the chip are the real culprits.

Would the shortage of program space prevent the use of the SX1278?

[rstrouse]

Would the shortage of program space prevent the use of the SX1278?

Yes I would need to write an SPI driver for it. This takes codespace in the firmware and I am at 98% already. I may find economy as I plan to re-write the CC1101 driver to put it on a diet in the future.

[perfrankling]

Yes I would need to write an SPI driver for it. This takes codespace in the firmware and I am at 98% already. I may find economy as I plan to re-write the CC1101 driver to put it on a diet in the future.

OK! I thought it could be a different version for a different hardware - but I understand that you do not want multiple builds.