Repository navigation
Document TFA Marbella pool thermometer - #1566
Merged
Merged
Conversation
5 of 6 tasks
The TFA Dostmann Marbella transmits the water temperature on 868 MHz once a minute; Tasmota receives it with a CC1101 and reports temperature, sensor id, rolling counter, battery state and link quality. The LQI needs the note that it runs the other way round than the one Zigbee transceivers report - low is good here. The RSSI is deliberately absent: the value the chip appends to the packet is not reachable through RadioLib, and the register that is holds the noise floor once the frame is complete, which would look like a reading and be none.
pschroee
marked this pull request as draft
August 14, 2026 22:25
pschroee
changed the title
pschroee
changed the title
pschroee
marked this pull request as ready for review
August 15, 2026 08:31
pschroee
marked this pull request as draft
August 18, 2026 12:10
Follows the driver change: SetOption166 is gone, readings are published as they arrive and SetOption147 suppresses that, shared with the other receiving drivers. Adds the "Marbella <MHz>" tuning command and a section explaining what it is for. A CC1101 derives its frequency from a 26 MHz crystal, and a cheap one lands the receiver beside the frequency it was told - measured on one module, 868.000 put it on 867.973. That still fits inside the receive filter but spends the margin the signal needs, and the symptom is losing frames while the sensor is demonstrably transmitting.
pschroee
changed the title
pschroee
marked this pull request as ready for review
August 24, 2026 17:13
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.
Documentation for the TFA Marbella driver proposed in arendst/Tasmota#24959.
Adds:
docs/TFA-Marbella.md- wiring, configuration, commands, tuning, sensor outputdocs/Supported-Peripherals.mdThe wiring table deliberately separates the shared SPI bus lines from the two roles that belong to the module (
CC1101 CS,CC1101 GDO0), since that is the part that is easy to get wrong. It also mentions the antenna: the wire supplied with common CC1101 breakout boards is cut for 433 MHz, not 868 MHz.The sensor output section documents
LQIwith an explicit warning that it runs the other way round than the LQI of Zigbee transceivers - 0 to 127 with low being good. It also states why no RSSI is reported: the value the chip appends to the packet is not reachable through RadioLib, and the register that is holds the noise floor by the time the frame is complete, so publishing it would show a plausible number that means nothing.Updated after review of the driver PR.
SetOption166is gone; readings are published as they arrive andSetOption147suppresses that, shared with the other receiving drivers. TheSetOption166row indocs/Commands.mdis removed again.Also documents the new
Marbella <MHz>tuning command and adds a section explaining what it is for. A CC1101 derives its frequency from a 26 MHz crystal, and a cheap one lands the receiver beside the frequency it was told - measured on one module,868.000put it on 867.973. That still fits inside the 135 kHz receive filter but spends the margin the signal needs, and the symptom is losing frames while the sensor is demonstrably transmitting.