CC1101 docs #5614
CC1101 docs #5614
Conversation
✅ Deploy Preview for esphome ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
| pullup: true | ||
| open_drain: true | ||
| allow_other_uses: true | ||
| carrier_duty_percent: 100% |
There was a problem hiding this comment.
| carrier_duty_percent: 100% | |
| carrier_duty_percent: 100% | |
| eot_level: false |
content/components/cc1101.md
Outdated
| mode: | ||
| input: true | ||
| output: true | ||
| pullup: true | ||
| open_drain: true | ||
| allow_other_uses: true |
There was a problem hiding this comment.
Split pin does not require open drain
There was a problem hiding this comment.
Do i need input: true on the split pin mode? Also does it need eot_level for the split pin example?
There was a problem hiding this comment.
Dont need eot_level for split. For split you shouldnt need anything special for pin.
content/components/cc1101.md
Outdated
| gdo0_pin: | ||
| pin: | ||
| number: GPIOXX # CC1101 GDO0 | ||
| mode: | ||
| input: true | ||
| output: true | ||
| pullup: true | ||
| open_drain: true | ||
| allow_other_uses: true |
There was a problem hiding this comment.
Can probably remove gdo0_pin from cc1101, it is not needed. It will break single pin on esp32.
There was a problem hiding this comment.
You need to change the input and output direction if you cant use open drain. That is the only time it would be useful for cc1101 to take the gdo0_pin. It should not be available on ESP32. Could also validate it does not have open drain enabled.
There was a problem hiding this comment.
Going to have to document these as separate use cases:
- single pin + open drain (esp32 must use this)
- single pin + not open drain
- dual pins
There was a problem hiding this comment.
Okay, ill get gdo0 removed.
to be clear, esp32 would still work as dual pin right?
Although, being it can't receive while it transmits, i'm not sure there's really any reason to use the dual pin option? Unless you had more than 1 cc1101 wired to the same device, I think you could share a pin for receive and have separate transmit pins
There was a problem hiding this comment.
Yeah esp32 can work with dual. I mean you don't have to use open drain and can remove the extra writes and state changes in the remote transmitter triggers. So dual is preferred.
You actually do receive when transmitting on a single pin. The receiver actually receives what you transmitted lol. Its actually very handy to debug.
There was a problem hiding this comment.
I think i got it but AI generated the config for the single pin non open drain config so let me know if it is even close.
There was a problem hiding this comment.
Is there a way to run the linter before I commit? I tried originally but couldn't find a script or anything to run it
There was a problem hiding this comment.
If you look at the logs and expand run you can see what it is running. I have never actually run it locally though:
/usr/bin/docker run --name f39ffa26c4dedf04b83ad8b67069982105b_8de1c5 --label 813f39 --workdir /github/workspace --rm -e "pythonLocation" -e "PKG_CONFIG_PATH" -e "Python_ROOT_DIR" -e "Python2_ROOT_DIR" -e "Python3_ROOT_DIR" -e "LD_LIBRARY_PATH" -e "INPUT_CONFIG_FILE" -e "INPUT_FILES" -e "INPUT_DOT" -e "INPUT_IGNORE_FILES" -e "INPUT_IGNORE_PATH" -e "INPUT_RULES" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_ENVIRONMENT" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e "ACTIONS_RESULTS_URL" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/esphome-docs/esphome-docs":"/github/workspace" 813f39:ffa26c4dedf04b83ad8b67069982105b
2 participants
Description:
Adding docs for CC1101 component
Related issue (if applicable): fixes
Pull request in esphome with YAML changes (if applicable):
Checklist:
I am merging into
nextbecause this is new documentation that has a matching pull-request in esphome as linked above.or
I am merging into
currentbecause this is a fix, change and/or adjustment in the current documentation and is not for a new component or feature.Link added in
/components/index.rstwhen creating new documents for new components or cookbook.New Component Images
If you are adding a new component to ESPHome, you can automatically generate a standardized black and white component name image for the documentation.
To generate a component image:
Comment on this pull request with the following command, replacing
COMPONENT_NAMEwith your component name in UPPER_CASE format with underscores (e.g.,BME280,SHT3X,DALLAS_TEMP):The ESPHome bot will respond with a downloadable ZIP file containing the SVG image.
Extract the SVG file and place it in the
images/folder of this repository.Use the image in your component's index table entry in
/components/index.rst.Example: For a component called "DHT22 Temperature Sensor", use: