sonoff rf bridge, handling of variable protocol speeds #913
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.
Hi, this patch responds to the issue raised in #885 (rf bridge and energenie remotes) being able to receive but not to transmit codes from the rf bridge.
In the initial implementation I suppressed the timing information from rc-switch output in order to emit consistent RC codes (if timing varies from one key stroke to the other, the consumer the other side of MQTT would have a hard time to recognize the varying code.
The varying time in RC codes is an issue also in the 'vanilla' rf-bridge implementation, as signaled also in #910 (Controlling rf433 bridge via MQTT broker)
The changes I have made for the -direct firmware address these points.
(if timing is not available, the default timing for protocol is used from rc-switch)
In practice, when we receive an RF code we first try to match with learned ones. If that matches, the stored one replaces the received one (standardizes it) before continuing the processing and publishing to MQTT, or whatever. This also allows to store a 'known' code by hand with the UI interface and keep a consistent output everywhere, avoiding the timing variance brought while learning.
I made this latest change independent from bridge hacks (vanilla, direct, and portish) variants as I think they can all benefit the improvement. In particular, it might ease the issue #910 too.
This patch relies on the standard rc-switch library and in consequence of this does not contain the rf tracing features.