You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have been experimenting to use this LoRaWAN stack in ESPHome but would in that case want to re-use the native ESPHome LoRa radio integrations. For that this library will have to allow proxying the radio communication parts to code outside the library code.
This PR adds this possibility by adding the build-flag -D CFG_external_radio=1
Thanks for the PR, @dala318. The use case is valid -- being able to substitute an external radio driver is something we need.
However, we're deferring this for now because it intersects with two larger efforts:
Radio driver interface design (V7 architecture: structured initialization and configuration layering #1067). The internal functions that a radio driver must implement (os_radio(), radio_init(), radio_config(), etc.) are not a stable or documented interface. The v6.0.0 refactor added os_radio_v2() and changed how radio state is managed. Simply suppressing the built-in drivers and hoping an external implementation matches the current internals is fragile. We need to define a proper radio driver contract first.
LoRaWAN-over-Meshtastic (LWoM). We're actively working on tunneling LoRaWAN Class A traffic over Meshtastic transport, which requires replacing the radio layer with something that isn't a LoRa PHY at all -- Meshtastic packet transport with soft RX timing and runtime region selection. This is a more demanding version of the same abstraction your PR enables, and the interface design needs to accommodate both use cases.
We'll keep this open as a reference. When the radio driver interface is properly specified (likely as part of a v7 architecture effort), we'll revisit enabling external radio drivers in a way that's maintainable.
Thanks for the update.
My LoRaWAN projects has been put on hold for a while now due to lack of time but am looking forward to your future improvements. Might spring some new life into my attempt of adding LoRaWAN support to ESPHome.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Have been experimenting to use this LoRaWAN stack in ESPHome but would in that case want to re-use the native ESPHome LoRa radio integrations. For that this library will have to allow proxying the radio communication parts to code outside the library code.
This PR adds this possibility by adding the build-flag
-D CFG_external_radio=1ESPHome PR /dala318/esphome/pull/16