Fix F6-02-01 RPS telegram decoding failure in HA overlay#173
Open
Hugo-HoB wants to merge 1 commit intomak-gitdev:developfrom
Open
Fix F6-02-01 RPS telegram decoding failure in HA overlay#173Hugo-HoB wants to merge 1 commit intomak-gitdev:developfrom
Hugo-HoB wants to merge 1 commit intomak-gitdev:developfrom
Conversation
When the HA overlay is enabled, F6 (RPS) devices like the PTM210 wall switch fail to decode with 'message not interpretable' errors, despite having correct mappings in mapping.yaml. Root cause: The overlay unconditionally sets device configuration fields (command, channel, direction, etc.) from mapping.yaml, even when those fields contain empty strings. For F6-02-01, all these fields are set to empty string "". The EnOcean library's parse_eep() method treats direction="" as an invalid parameter and fails to parse the telegram, returning no properties. This differs from direction=None, which correctly means 'no direction specified'. Fix: Only set configuration fields if they have non-empty values. This ensures the EnOcean library receives None for unset parameters instead of empty strings. Tested with: - PTM210 DB (F6-02-01) wall switch: Messages now decode and publish - ubiwizz relay (D2-01-01): Still works correctly (backwards compatible) Fixes issue where F6-02-01 and similar RPS devices cannot be used with the HA overlay despite being listed as supported.
This was referenced Jan 5, 2026
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
2 participants
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.
Summary
Fixes F6-02-01 RPS wall switches that fail to decode when HA overlay is enabled
Problem
When the HA overlay is enabled, F6 (RPS) devices like the PTM210 wall switch produce "message not interpretable" errors and fail to publish MQTT messages, despite having correct mappings in mapping.yaml.
Root Cause
The HA overlay unconditionally sets device configuration fields from mapping.yaml, even when those fields contain empty strings. For F6-02-01, all fields (command, channel, direction, etc.) are set to
"".The EnOcean library's
parse_eep()method treatsdirection=""as an invalid parameter and fails to parse, whiledirection=Nonecorrectly means "no direction specified."Solution
Modified
ha_communicator.pylines 46-58 to only set configuration fields if they have non-empty values. This ensures the EnOcean library receivesNonefor unset parameters instead of empty strings.Testing
Files Changed
enoceanmqtt/overlays/homeassistant/ha_communicator.py