Fix emitter by not considering NaN/no state as a reason to split packet - #14
Open
haroal wants to merge 1 commit into
Open
Fix emitter by not considering NaN/no state as a reason to split packet#14haroal wants to merge 1 commit into
haroal wants to merge 1 commit into
Conversation
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Current implementation has a bug that makes the system send multiple packets when some data are NaN/no state, considering we have too much data to send for 1 advertisement and so using the feature to split the payload in multiple advertisements. In this case, the ordering index is messed up and sends data in an unwanted order.
This fix updates the BTHome emitter code to distinguish cases when we indeed have an overflow (and so another advertisement will need to be sent with remaining data) VS when some values are NaN/no state and so should just be ignored.
This is particularly important when using HomeAssistant BTHome integration as the receiver because it expects measurements order to be consistent to know to which "entity" each measurement refers (especially when you have multiple measurements sharing the same "object id" from HA point of view).
With this fix, my HA integration reliably assigns my sensor values to the right entity.