Upstream/esphome-docs
1
0
Fork 0
mirror of https://github.com/esphome/esphome-docs.git synced 2024-11-12 10:24:00 +01:00
Code Issues Projects Releases Wiki Activity

Merge branch 'current' into beta

Browse Source
This commit is contained in:
Jesse Hills 2024-07-16 16:51:03 +12:00
commit a6d42d5ebd
No known key found for this signature in database
GPG Key ID: BEAAE804EFD8E83A
37 changed files with 657 additions and 614 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
components/binary_sensor/ble_presence.rst
View File

@ -10,7 +10,7 @@ The ``ble_presence`` binary sensor platform lets you track the presence of a Blu
.. warning::
The BLE software stack on the ESP32 consumes a significant amount of RAM on the device.
**Crashes are likely to occur** if you include too many additional components in your device's
configuration. Memory-intensive components such as :doc:`/components/voice_assistant` and other
audio components are most likely to cause issues.
@ -27,7 +27,7 @@ The ``ble_presence`` binary sensor platform lets you track the presence of a Blu
binary_sensor:
# Presence based on MAC address
- platform: ble_presence
mac_address: AC:37:43:77:5F:4C
mac_address: XX:XX:XX:XX:XX:XX
name: "ESP32 BLE Tracker Google Home Mini"
min_rssi: -80dB
# Presence based on Identity Resolving Key (IRK)
@ -96,7 +96,7 @@ the logs to see discovered Bluetooth Low Energy devices.
Using the configuration above, first you should see a ``Starting scan...`` debug message at
boot-up. Then, when a BLE device is discovered, you should see messages like
``Found device AC:37:43:77:5F:4C`` together with some information about their
``Found device XX:XX:XX:XX:XX:XX`` together with some information about their
address type and advertised name. If you don't see these messages, your device is unfortunately
currently not supported.

32
components/ble_client.rst
View File

@ -12,7 +12,7 @@ connections to them for use by other components.
.. warning::
The BLE software stack on the ESP32 consumes a significant amount of RAM on the device.
**Crashes are likely to occur** if you include too many additional components in your device's
configuration. Memory-intensive components such as :doc:`/components/voice_assistant` and other
audio components are most likely to cause issues.
@ -36,7 +36,7 @@ to discover available client devices.
esp32_ble_tracker:
ble_client:
- mac_address: FF:FF:20:00:0F:15
- mac_address: XX:XX:XX:XX:XX:XX
id: itag_black
auto_connect: true
@ -73,7 +73,7 @@ This automation is triggered when the client connects to the BLE device.
.. code-block:: yaml
ble_client:
- mac_address: 11:22:33:44:55:66
- mac_address: XX:XX:XX:XX:XX:XX
id: ble_itag
on_connect:
then:
@ -90,7 +90,7 @@ This automation is triggered when the client disconnects from a BLE device.
.. code-block:: yaml
ble_client:
- mac_address: 11:22:33:44:55:66
- mac_address: XX:XX:XX:XX:XX:XX
id: ble_itag
on_disconnect:
then:
@ -108,7 +108,7 @@ This automation is triggered when the BLE device requests a passkey for authenti
.. code-block:: yaml
ble_client:
- mac_address: 11:22:33:44:55:66
- mac_address: XX:XX:XX:XX:XX:XX
id: ble_itag
on_passkey_request:
then:
@ -126,7 +126,7 @@ This automation is triggered when a passkey is received from the BLE device.
.. code-block:: yaml
ble_client:
- mac_address: 11:22:33:44:55:66
- mac_address: XX:XX:XX:XX:XX:XX
id: ble_itag
on_passkey_notification:
then:
@ -144,7 +144,7 @@ This automation is triggered when a numeric comparison is requested by the BLE d
.. code-block:: yaml
ble_client:
- mac_address: 11:22:33:44:55:66
- mac_address: XX:XX:XX:XX:XX:XX
id: ble_itag
on_numeric_comparison_request:
then:
@ -174,10 +174,10 @@ on, hence the stop and start of the scan during connect.
ble_client:
- id: ble_clock
mac_address: 17:75:BC:F2:94:4D
mac_address: XX:XX:XX:XX:XX:XX
auto_connect: false
- id: other_device
mac_address: 0D:33:12:66:00:D4
mac_address: XX:XX:XX:XX:XX:XX
interval:
- interval: 60min
@ -222,7 +222,7 @@ Example usage:
.. code-block:: yaml
ble_client:
- mac_address: 11:22:33:44:55:66
- mac_address: XX:XX:XX:XX:XX:XX
id: my_ble_client
switch:
@ -308,7 +308,7 @@ Example usage:
.. code-block:: yaml
ble_client:
- mac_address: 11:22:33:44:55:66
- mac_address: XX:XX:XX:XX:XX:XX
id: my_ble_client
on_connect:
then:
@ -391,9 +391,9 @@ display them in the log:
.. code-block:: text
[18:24:56][D][ble_client:043]: Found device at MAC address [FC:58:FA:B1:F8:93]
[18:24:56][I][ble_client:072]: Attempting BLE connection to fc:58:fa:b1:f8:93
[18:24:56][I][ble_client:097]: [fc:58:fa:b1:f8:93] ESP_GATTC_OPEN_EVT
[18:24:56][D][ble_client:043]: Found device at MAC address [XX:XX:XX:XX:XX:XX]
[18:24:56][I][ble_client:072]: Attempting BLE connection to XX:XX:XX:XX:XX:XX
[18:24:56][I][ble_client:097]: [XX:XX:XX:XX:XX:XX] ESP_GATTC_OPEN_EVT
[18:24:57][I][ble_client:143]: Service UUID: 0x1800
[18:24:57][I][ble_client:144]: start_handle: 0x1 end_handle: 0x5
[18:24:57][I][ble_client:305]: characteristic 0x2A00, handle 0x3, properties 0x2
@ -445,7 +445,7 @@ Secure connection with a fixed passkey:
esp32_ble_tracker:
ble_client:
- mac_address: A4:C1:38:B1:CD:7F
- mac_address: XX:XX:XX:XX:XX:XX
id: pvvx_ble_display
on_passkey_request:
then:
@ -483,7 +483,7 @@ Secure connection with a dynamically generated passkey:
esp32_ble_tracker:
ble_client:
- mac_address: AA:BB:CC:DD:EE:FF
- mac_address: XX:XX:XX:XX:XX:XX
id: my_ble_client
on_passkey_request:
then:

2
components/button/wake_on_lan.rst
View File

@ -14,7 +14,7 @@ by specifying its MAC address.
button:
- platform: wake_on_lan
name: "Start the Server"
target_mac_address: E9:48:B8:CA:58:A1
target_mac_address: XX:XX:XX:XX:XX:XX
Configuration variables:
------------------------

498
components/canbus.rst
View File

@ -1,498 +0,0 @@
.. _canbus:
CAN bus
=======
.. seo::
:description: Instructions for setting up an CAN bus in ESPHome
:image: canbus.svg
:keywords: CAN
Controller Area Network (CAN bus) is a serial bus protocol to connect individual systems and sensors
as an alternative to conventional multi-wire looms.
It allows automotive components to communicate on a single or dual-wire networked data bus up to 1Mbps.
CAN is an International Standardization Organization (ISO) defined serial communications bus originally
developed for the automotive industry to replace the complex wiring harness with a two-wire bus. The
specification calls for high immunity to electrical interference and the ability to self-diagnose and repair
data errors. These features have led to CAN’s popularity in a variety of industries including building
automation, medical, and manufacturing.
The current ESPHome implementation supports single frame data transfer. In this way you may send and
receive data frames up to 8 bytes.
With this you can transmit the press of a button or the feedback from a sensor on the bus.
All other devices on the bus will be able to get this data to switch on/off a light or display the
transmitted data.
The CAN bus itself has only two wires named Can High and Can Low or CanH and CanL. For the ESPHome
CAN bus to work you need to select the device that has the physical CAN bus implemented.
You can configure multiple buses.
Any can bus node can transmit data at any time, and any node can send any ``can_id`` value and any
node can receive any can_id too. Is up to you how to organize the can_id values. You can setup a can
bus network where each node has a can id which will use to broadcast data about itself, if a node
should, e.g. turn on a light, it can listen for can messages with the can id assigned to it.
So you can have several nodes being able to control a light in e.g. node 20.
Base CAN Bus Configuration
--------------------------
Each canbus platform extends this configuration schema.
.. code-block:: yaml
# Example configuration entry
canbus:
- platform: ...
can_id: 4
on_frame:
- can_id: 500
use_extended_id: false
then:
- lambda: |-
std::string b(x.begin(), x.end());
ESP_LOGD("can id 500", "%s", &b[0] );
.. _config-canbus:
Configuration variables:
************************
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **can_id** (**Required**, int): default *can id* used for transmitting frames.
- **use_extended_id** (*Optional*, boolean): default *false* identifies the type of *can_id*:
*false*: Standard 11 bits IDs, *true*: Extended 29 bits ID
- **bit_rate** (*Optional*, enum): One of the supported bitrates. Defaults to ``125KBPS``.
- ``1KBPS`` - Support by ``esp32_can`` depends on ESP32 variant
- ``5KBPS`` - Support by ``esp32_can`` depends on ESP32 variant
- ``10KBPS`` - Support by ``esp32_can`` depends on ESP32 variant
- ``12K5BPS`` - Support by ``esp32_can`` depends on ESP32 variant
- ``16KBPS`` - Support by ``esp32_can`` depends on ESP32 variant
- ``20KBPS`` - Support by ``esp32_can`` depends on ESP32 variant
- ``25KBPS``
- ``31K25BPS`` - Not supported by ``esp32_can``
- ``33KBPS`` - Not supported by ``esp32_can``
- ``40KBPS`` - Not supported by ``esp32_can``
- ``50KBPS``
- ``80KBPS`` - Not supported by ``esp32_can``
- ``83K3BPS`` - Not supported by ``esp32_can``
- ``95KBPS`` - Not supported by ``esp32_can``
- ``100KBPS``
- ``125KBPS`` - (Default)
- ``200KBPS`` - Not supported by ``esp32_can``
- ``250KBPS``
- ``500KBPS``
- ``1000KBPS``
See :ref:`this table <esp32-can-bit-rate>` for a list of supported bit rates by the internal CAN (TWAI) controllers of different ESP32 variants.
Automations:
------------
- **on_frame** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a
CAN frame is received. See :ref:`canbus-on-frame`.
.. _canbus-on-frame:
``on_frame`` Trigger
********************
This automation will be triggered when a CAN frame is received. The variables ``x`` (of type
``std::vector<uint8_t>``) containing the frame data, ``can_id`` (of type ``uint32_t``) containing the actual
received CAN id and ``remote_transmission_request`` (of type ``bool``) containing the corresponding field
from the CAN frame are passed to the automation for use in lambdas.
.. note::
Messages this node sends to the same ID will not show up as received messages.
.. code-block:: yaml
canbus:
- platform: ...
on_frame:
- can_id: 43 # the received can_id
then:
- if:
condition:
lambda: 'return (x.size() > 0) ? x[0] == 0x11 : false;'
then:
light.toggle: light1
- can_id: 0b00000000000000000000001000000
can_id_mask: 0b11111000000000011111111000000
use_extended_id: true
remote_transmission_request: false
then:
- lambda: |-
auto pdo_id = can_id >> 14;
switch (pdo_id)
{
case 117:
ESP_LOGD("canbus", "exhaust_fan_duty");
break;
case 118:
ESP_LOGD("canbus", "supply_fan_duty");
break;
case 119:
ESP_LOGD("canbus", "supply_fan_flow");
break;
// to be continued...
}
Configuration variables:
************************
- **can_id** (**Required**, int): The received CAN id to trigger this automation on.
- **can_id_mask** (*Optional*, int): The bit mask to apply to the received CAN id before trying to match it
with *can_id*, defaults to ``0x1fffffff`` (all bits of received CAN id are compared with *can_id*).
- **use_extended_id** (*Optional*, boolean): Identifies the type of *can_id* to match on, defaults to *false*.
- **remote_transmission_request** (*Optional*, boolean): Whether to run for CAN frames with the "remote
transmission request" bit set or not set, defaults to not checking, i.e. to run for both cases.
``canbus.send`` Action
**********************
The can bus can transmit frames by means of the ``canbus.send`` action.
There are several forms to use it:
.. code-block:: yaml
on_...:
- canbus.send:
data: [ 0x10, 0x20, 0x30 ]
canbus_id: my_mcp2515 # optional if you only have 1 canbus device
can_id: 23 # override the can_id configured in the can bus
on_...:
- canbus.send: [ 0x11, 0x22, 0x33 ]
- canbus.send: 'hello'
# Templated, return type is std::vector<uint8_t>
- canbus.send: !lambda return {0x00, 0x20, 0x42};
Configuration variables:
- **data** (**Required**, binary data, :ref:`templatable <config-templatable>`): Data to transmit, up to 8 bytes or
characters are supported by can bus per frame.
- **canbus_id** (*Optional*): Optionally set the can bus id to use for transmitting
the frame. Not needed if you are using only 1 can bus.
- **can_id** (*Optional*, int): Allows to override the can id configured in
the can bus device.
- **use_extended_id** (*Optional*, boolean): default *false* identifies the type of *can_id*:
*false*: Standard 11 Bit IDs, *true*: Extended 29Bit ID
- **remote_transmission_request** (*Optional*, boolean): Set to send CAN bus frame to request data from another node
(defaults to *false*). If a certain data length code needs to be sent, provide as many (dummy) bytes in *data*.
ESP32 CAN Component
-------------------
The ESP32 has an integrated CAN controller and therefore doesn't need an external controller necessarily.
You only need to specify the RX and TX pins. Any GPIO will work.
.. code-block:: yaml
# Example configuration entry
canbus:
- platform: esp32_can
tx_pin: GPIOXX
rx_pin: GPIOXX
can_id: 4
bit_rate: 50kbps
on_frame:
...
.. _esp32-can-bit-rate:
The table lists the specific bit rates supported by the component for ESP32 variants:
=================== ======= ========== ========== ========== ========== ==========
bit_rate ESP32 ESP32-S2 ESP32-S3 ESP32-C3 ESP32-C6 ESP32-H2
=================== ======= ========== ========== ========== ========== ==========
1KBPS x x x x x
5KBPS x x x x x
10KBPS x x x x x
12K5BPS x x x x x
16KBPS x x x x x
20KBPS x x x x x
25KBPS x x x x x x
31K25BPS
33KBPS
40KBPS
50KBPS x x x x x x
80KBPS
83K38BPS
95KBPS
100KBPS x x x x x x
125KBPS (Default) x x x x x x
250KBPS x x x x x x
500KBPS x x x x x x
800KBPS x x x x x x
1000KBPS x x x x x x
=================== ======= ========== ========== ========== ========== ==========
Wiring options
**************
5V CAN transceivers are cheap and generate compliant levels. If you power your
board with 5V this is the preferred option. R501 is important to reduce the 5V
logic level down to 3.3V, to avoid damaging the ESP32. You can alternatively
use a voltage divider here instead.
.. figure:: images/canbus_esp32_5v.png
:align: center
:target: ../_images/canbus_esp32_5v.png
If you prefer to only have a 3.3V power supply, special 3.3V CAN transceivers are available.
.. figure:: images/canbus_esp32_3v3.png
:align: center
:target: ../_images/canbus_esp32_3v3.png
Configuration variables:
************************
- **rx_pin** (**Required**, :ref:`Pin <config-pin>`): Receive pin.
- **tx_pin** (**Required**, :ref:`Pin <config-pin>`): Transmit pin.
- All other options from :ref:`Canbus <config-canbus>`.
MCP2515 Component
-----------------
The MCP2515 is a spi device and therefore you must first add the configuration for the spi bus to your file.
You need to have an :ref:`SPI bus <spi>` in your configuration with both the **mosi_pin** and **miso_pin** set.
For wiring up the MSP2515 please refer to the section below.
.. code-block:: yaml
# Example configuration entry
canbus:
- platform: mcp2515
cs_pin: GPIOXX
can_id: 4
bit_rate: 50kbps
on_frame:
- can_id: 500
then:
- lambda: |-
std::string b(x.begin(), x.end());
ESP_LOGD("canid 500", "%s", &b[0] );
- light.turn_off: light_1
- can_id: 501
then:
- light.turn_on:
id: light_1
brightness: !lambda "return (x.size() > 0) ? (float) x[0]/255 : 0;"
Configuration variables:
************************
- **cs_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): Is used to tell the receiving SPI device
when it should listen for data on the SPI bus. Each device has an individual ``CS`` line.
Sometimes also called ``SS``.
- **clock** (*Optional*): One of ``8MHZ``, ``12MHz``, ``16MHZ`` or ``20MHZ``. Clock crystal used on the MCP2515 device.
Defaults to ``8MHZ``.
- **mode** (*Optional*): Operation mode. Default to ``NORMAL``
- ``NORMAL``: Normal operation
- ``LOOPBACK``: Loopback mode can be used to just test you spi connections to the device
- ``LISTENONLY``: only receive data
- All other options from :ref:`Canbus <config-canbus>`.
Note that not all combinations of clock and bitrate are supported. An unsupported
combination will not be flagged at compile time, check the runtime log for a message like
``Invalid frequency/bitrate combination`` if you suspect this is an issue.
Wiring options
**************
Easiest approach is to just use fully assembled boards and just add one resistor in the MISO line.
This runs MOSI, SCK and CS out of specification which is nearly never a problem.
.. figure:: images/canbus_mcp2515_resistor.png
:align: center
:target: ../_images/canbus_mcp2515_resistor.png
A more advanced option is to fully convert the 5V and 3.3V logic levels with a level shifter.
.. figure:: images/canbus_mcp2515_txs0108e.png
:align: center
:target: ../_images/canbus_mcp2515_txs0108e.png
Extended ID
-----------
Standard IDs and Extended IDs can coexist on the same segment.
.. note::
It is important to know that for example Standard 0x123 and Extended 0x123 are different addresses.
This example shows how the different ID types are used in the configuration for transmission and receiving.
For the IDs decimal or hexadecimal notation is possible:
0x000 - 0x7ff / 0-2047 for Standard IDs only.
0x00000000 - 0x1fffffff / 0-536870911 for Extended IDs.
.. code-block:: yaml
# Transmission of extended and standard ID 0x100 every second
time:
- platform: sntp
on_time:
- seconds: /1
then:
- canbus.send:
# Extended ID explicit
use_extended_id: true
can_id: 0x100
data: [0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08]
- canbus.send:
# Standard ID by default
can_id: 0x100
data: [0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08]
canbus:
- platform: mcp2515
id: my_mcp2515
spi_id: McpSpi
cs_pin: GPIOXX
can_id: 0x1fff
use_extended_id: true
bit_rate: 125kbps
on_frame:
- can_id: 0x123
use_extended_id: true
then:
- lambda: |-
std::string b(x.begin(), x.end());
ESP_LOGD("can extended id 0x123", "%s", &b[0] );
- can_id: 0x123
then:
- lambda: |-
std::string b(x.begin(), x.end());
ESP_LOGD("can standard id 0x123", "%s", &b[0] );
Binary Sensor Example
---------------------
Example for the following application:
Button is connected on a can node which sends an A message on ID 0x100 with payload 0x01 for contact closed and 0x00 for contact open.
.. code-block:: yaml
spi:
id: McpSpi
clk_pin: GPIOXX
mosi_pin: GPIOXX
miso_pin: GPIOXX
binary_sensor:
- platform: template
name: "CAN Bus Button"
id: "can_bus_button"
canbus:
- platform: mcp2515
id: my_mcp2515
spi_id: McpSpi
cs_pin: GPIOXX
can_id: 4
bit_rate: 125kbps
on_frame:
- can_id: ${0x100}
then:
- lambda: |-
if(x.size() > 0) {
switch(x[0]) {
case 0x0: id(can_bus_button).publish_state(false); break; // button release
case 0x1: id(can_bus_button).publish_state(true); break; // button down
}
}
Cover Example
-------------
Example for following application:
Buttons are connected on the CAN-Node and also the motor is connected via CAN.
.. epigraph::
| **Button 1:** ID 0x50B - 1 byte payload
| (0: Button release, 1: Button down, 2: long down, 3: long release, 4 double click)
| **Button 2:** ID 0x50C - 1 byte payload
| (0: Button release, 1: Button down, 2: long down, 3: long release, 4 double click)
| **Motor:** ID 0x51A - 1 byte payload
| (0: off, 1: open, 2: close)
.. code-block:: yaml
spi:
id: McpSpi
clk_pin: GPIOXX
mosi_pin: GPIOXX
miso_pin: GPIOXX
canbus:
- platform: mcp2515
id: my_mcp2515
spi_id: McpSpi
cs_pin: GPIOXX
can_id: 4
bit_rate: 125kbps
on_frame:
- can_id: 0x50c
then:
- lambda: |-
if(x.size() > 0) {
auto call = id(TestCover).make_call();
switch(x[0]) {
case 0x2: call.set_command_open(); call.perform(); break; // long pressed
case 0x1: // button down
case 0x3: call.set_command_stop(); call.perform(); break; // long released
case 0x4: call.set_position(1.0); call.perform(); break; // double click
}
}
- can_id: 0x50b
then:
- lambda: |-
if(x.size() > 0) {
auto call = id(TestCover).make_call();
switch(x[0]) {
case 0x2: call.set_command_close(); call.perform(); break; // long pressed
case 0x1: // button down
case 0x3: call.set_command_stop(); call.perform(); break; // long released
case 0x4: call.set_position(0.0); call.perform(); break; // double click
}
}
cover:
- platform: time_based
name: "MyCanbusTestCover"
id: TestCover
device_class: shutter
has_built_in_endstop: true
open_action:
- canbus.send:
data: [ 0x01 ]
canbus_id: my_mcp2515
can_id: 0x51A
open_duration: 2min
close_action:
- canbus.send:
data: [ 0x02 ]
canbus_id: my_mcp2515
can_id: 0x51A
close_duration: 2min
stop_action:
- canbus.send:
data: [ 0x00 ]
canbus_id: my_mcp2515
can_id: 0x51A
See Also
--------
- :apiref:`spi/spi.h`
- :ghedit:`Edit`

83
components/canbus/esp32_can.rst Normal file
View File

@ -0,0 +1,83 @@
ESP32 CAN
=========
.. seo::
:description: Instructions for setting up the ESP32 CAN bus platform in ESPHome
:image: canbus.svg
:keywords: CAN, ESP32
The ESP32 has an integrated CAN controller and therefore doesn't necessarily need an external controller.
You only need to specify the RX and TX pins. Any GPIO will work.
.. code-block:: yaml
# Example configuration entry
canbus:
- platform: esp32_can
tx_pin: GPIOXX
rx_pin: GPIOXX
can_id: 4
bit_rate: 50kbps
on_frame:
...
Configuration variables:
------------------------
- **rx_pin** (**Required**, :ref:`Pin <config-pin>`): Receive pin.
- **tx_pin** (**Required**, :ref:`Pin <config-pin>`): Transmit pin.
- All other options from :ref:`Canbus <config-canbus>`.
.. _esp32-can-bit-rate:
The following table lists the bit rates supported by the component for ESP32 variants:
=================== ======= ========== ========== ========== ========== ==========
bit_rate ESP32 ESP32-S2 ESP32-S3 ESP32-C3 ESP32-C6 ESP32-H2
=================== ======= ========== ========== ========== ========== ==========
1KBPS x x x x x
5KBPS x x x x x
10KBPS x x x x x
12K5BPS x x x x x
16KBPS x x x x x
20KBPS x x x x x
25KBPS x x x x x x
31K25BPS
33KBPS
40KBPS
50KBPS x x x x x x
80KBPS
83K38BPS
95KBPS
100KBPS x x x x x x
125KBPS (Default) x x x x x x
250KBPS x x x x x x
500KBPS x x x x x x
800KBPS x x x x x x
1000KBPS x x x x x x
=================== ======= ========== ========== ========== ========== ==========
Wiring options
--------------
5V CAN transceivers are cheap and generate compliant levels. If you power your
board with 5V this is the preferred option. R501 is important to reduce the 5V
logic level down to 3.3V, to avoid damaging the ESP32. You can alternatively
use a voltage divider here instead.
.. figure:: images/canbus_esp32_5v.png
:align: center
:target: ../_images/canbus_esp32_5v.png
If you prefer to only have a 3.3V power supply, special 3.3V CAN transceivers are available.
.. figure:: images/canbus_esp32_3v3.png
:align: center
:target: ../_images/canbus_esp32_3v3.png
See Also
--------
- :doc:`index`
- :apiref:`canbus/canbus.h`
- :ghedit:`Edit`

0
components/images/canbus_esp32_3v3.png → components/canbus/images/canbus_esp32_3v3.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 753 KiB

After

Width:  |  Height:  |  Size: 753 KiB

0
components/images/canbus_esp32_5v.png → components/canbus/images/canbus_esp32_5v.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 759 KiB

After

Width:  |  Height:  |  Size: 759 KiB

0
components/images/canbus_mcp2515_resistor.png → components/canbus/images/canbus_mcp2515_resistor.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 168 KiB

After

Width:  |  Height:  |  Size: 168 KiB

0
components/images/canbus_mcp2515_txs0108e.png → components/canbus/images/canbus_mcp2515_txs0108e.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 208 KiB

After

Width:  |  Height:  |  Size: 208 KiB

369
components/canbus/index.rst Normal file
View File

@ -0,0 +1,369 @@
CAN Bus
=======
.. seo::
:description: Instructions for setting up an CAN bus in ESPHome
:image: canbus.svg
:keywords: CAN
The Controller Area Network (CAN) bus is a serial bus protocol to connect individual systems and sensors
as an alternative to conventional multi-wire looms. It allows automotive components to communicate on a
single or dual-wire data bus at speeds up to 1Mbps.
CAN is an International Standardization Organization (ISO) defined serial communications bus originally
developed for the automotive industry to replace the complex wiring harness with a two-wire bus. The
specification calls for high immunity to electrical interference and the ability to self-diagnose and repair
data errors. These features have led to CAN’s popularity in a variety of industries including building
automation, medical, and manufacturing.
The current ESPHome implementation supports single frame data transfer. In this way you may send and
receive data frames up to 8 bytes.
With this you can transmit the press of a button or the feedback from a sensor on the bus.
All other devices on the bus will be able to get this data to switch on/off a light or display the
transmitted data.
The CAN bus itself has only two wires named Can High and Can Low or CanH and CanL. For the ESPHome
CAN bus to work, you need to select the device that has the physical CAN bus implemented.
You can configure multiple buses.
Any CAN bus node can transmit data at any time; any node can both send and/or receive any ``can_id`` value.
You must determine how to organize the ``can_id`` values; for example, you can set up a CAN bus network where
each node has a ``can_id`` it will use to broadcast data about itself. If a given node should (for example) turn
on a light, it can listen to the CAN bus for messages containing its specific ``can_id`` and react accodingly.
With this architecture, you can have multiple nodes able to control a light connected to a single, specific node.
Base CAN Bus Configuration
--------------------------
Each ``canbus`` platform extends the following configuration schema:
.. code-block:: yaml
# Example configuration entry
canbus:
- platform: ...
can_id: 4
on_frame:
- can_id: 500
use_extended_id: false
then:
- lambda: |-
std::string b(x.begin(), x.end());
ESP_LOGD("can id 500", "%s", &b[0] );
.. _config-canbus:
**Configuration variables:**
- **platform** (**Required**, :ref:`platform<platforms-canbus>`): One of the supported CAN bus :ref:`platforms-canbus`.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **can_id** (**Required**, int): default *CAN ID* used for transmitting frames.
- **use_extended_id** (*Optional*, boolean): Identifies the type of ``can_id``:
- ``false``: Standard 11-bit IDs *(default)*
- ``true``: Extended 29-bit IDs
- **bit_rate** (*Optional*, enum): One of the supported bit rates. See :ref:`this table <esp32-can-bit-rate>` for a
list of supported bit rates by the internal CAN (TWAI) controllers of different ESP32 variants. Defaults to ``125KBPS``.
- ``1KBPS`` - Support by ``esp32_can`` depends on ESP32 variant
- ``5KBPS`` - Support by ``esp32_can`` depends on ESP32 variant
- ``10KBPS`` - Support by ``esp32_can`` depends on ESP32 variant
- ``12K5BPS`` - Support by ``esp32_can`` depends on ESP32 variant
- ``16KBPS`` - Support by ``esp32_can`` depends on ESP32 variant
- ``20KBPS`` - Support by ``esp32_can`` depends on ESP32 variant
- ``25KBPS``
- ``31K25BPS`` - Not supported by ``esp32_can``
- ``33KBPS`` - Not supported by ``esp32_can``
- ``40KBPS`` - Not supported by ``esp32_can``
- ``50KBPS``
- ``80KBPS`` - Not supported by ``esp32_can``
- ``83K3BPS`` - Not supported by ``esp32_can``
- ``95KBPS`` - Not supported by ``esp32_can``
- ``100KBPS``
- ``125KBPS`` - *Default*
- ``200KBPS`` - Not supported by ``esp32_can``
- ``250KBPS``
- ``500KBPS``
- ``1000KBPS``
- **on_frame** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a
CAN frame is received. See :ref:`canbus-on-frame`.
.. _platforms-canbus:
Platforms
---------
.. toctree::
:maxdepth: 1
:glob:
*
Automations
-----------
.. _canbus-on-frame:
``on_frame`` Trigger
********************
This automation will be triggered when a CAN frame is received. The variables ``x`` (of type
``std::vector<uint8_t>``) containing the frame data, ``can_id`` (of type ``uint32_t``) containing the actual
received CAN ID and ``remote_transmission_request`` (of type ``bool``) containing the corresponding field
from the CAN frame are passed to the automation for use in lambdas.
.. note::
Messages this node sends to the same ID will not show up as received messages.
.. code-block:: yaml
canbus:
- platform: ...
on_frame:
- can_id: 43 # the received can_id
then:
- if:
condition:
lambda: 'return (x.size() > 0) ? x[0] == 0x11 : false;'
then:
light.toggle: light1
- can_id: 0b00000000000000000000001000000
can_id_mask: 0b11111000000000011111111000000
use_extended_id: true
remote_transmission_request: false
then:
- lambda: |-
auto pdo_id = can_id >> 14;
switch (pdo_id)
{
case 117:
ESP_LOGD("canbus", "exhaust_fan_duty");
break;
case 118:
ESP_LOGD("canbus", "supply_fan_duty");
break;
case 119:
ESP_LOGD("canbus", "supply_fan_flow");
break;
// to be continued...
}
**Configuration variables:**
- **can_id** (**Required**, int): The CAN ID which, when received, will trigger this automation.
- **can_id_mask** (*Optional*, int): The bit mask to apply to the received CAN ID before trying to match it
with *can_id*. Defaults to ``0x1fffffff`` (all bits of received CAN ID are compared with *can_id*).
- **use_extended_id** (*Optional*, boolean): Identifies the type of ``can_id`` to match on. Defaults to ``false``.
- **remote_transmission_request** (*Optional*, boolean): Whether to run for CAN frames with the "remote
transmission request" bit set or not set. Defaults to not checking (the automation will run for both cases).
``canbus.send`` Action
**********************
The CAN bus can transmit frames by means of the ``canbus.send`` action. There are several ways to use it:
.. code-block:: yaml
on_...:
- canbus.send:
data: [ 0x10, 0x20, 0x30 ]
canbus_id: my_mcp2515 # optional if you only have 1 canbus device
can_id: 23 # override the can_id configured in the can bus
on_...:
- canbus.send: [ 0x11, 0x22, 0x33 ]
- canbus.send: 'hello'
# Templated; return type must be std::vector<uint8_t>
- canbus.send: !lambda return {0x00, 0x20, 0x42};
**Configuration variables:**
- **data** (**Required**, binary data, :ref:`templatable <config-templatable>`): Data to transmit, up to eight
bytes/characters are supported by CAN bus per frame.
- **canbus_id** (*Optional*): Sets the CAN bus ID to use for transmitting the frame. Required if you are have multiple
CAN bus platforms defined in your configuration.
- **can_id** (*Optional*, int): Allows overriding the ``can_id`` configured for the CAN bus device.
- **use_extended_id** (*Optional*, boolean): Identifies the type of ``can_id``:
- ``false``: Standard 11-bit IDs *(default)*
- ``true``: Extended 29-bit IDs
- **remote_transmission_request** (*Optional*, boolean): Set to send CAN bus frame to request data from another node.
If a certain data length code needs to be sent, include the necessary (dummy) bytes in ``data``. Defaults to ``false``.
Extended ID
-----------
Standard IDs and Extended IDs can coexist on the same segment.
.. note::
It is important to know that "standard" and "extended" addresses denote different addresses. For example,
Standard ``0x123`` and Extended ``0x123`` are, in fact, different addresses.
Decimal or hexadecimal notation may be used for IDs:
- Standard IDs use ``0x000`` to ``0x7ff`` (hexadecimal) or ``0`` to ``2047`` (decimal)
- Extended IDs use ``0x00000000`` to ``0x1fffffff`` (hexadecimal) or ``0`` to ``536870911`` (decimal)
This example illustrates how different ID types may be used in your configuration for both transmitting and receiving.
.. code-block:: yaml
# Transmission of extended and standard ID 0x100 every second
time:
- platform: sntp
on_time:
- seconds: /1
then:
- canbus.send:
# Extended ID explicit
use_extended_id: true
can_id: 0x100
data: [0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08]
- canbus.send:
# Standard ID by default
can_id: 0x100
data: [0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08]
canbus:
- platform: ...
can_id: 0x1fff
use_extended_id: true
bit_rate: 125kbps
on_frame:
- can_id: 0x123
use_extended_id: true
then:
- lambda: |-
std::string b(x.begin(), x.end());
ESP_LOGD("CAN extended ID 0x123", "%s", &b[0]);
- can_id: 0x123
then:
- lambda: |-
std::string b(x.begin(), x.end());
ESP_LOGD("CAN standard ID 0x123", "%s", &b[0]);
Binary Sensor Example
---------------------
Given that we have a button connected to a remote CAN node which will send a message to ID ``0x100`` with the payload
``0x1`` for contact closed and ``0x0`` for contact open, this example will look for this message and update the state
of its ``binary_sensor`` accordingly.
.. code-block:: yaml
binary_sensor:
- platform: template
name: CAN Bus Button
id: can_bus_button
canbus:
- platform: ...
can_id: 4
bit_rate: 125kbps
on_frame:
- can_id: ${0x100}
then:
- lambda: |-
if(x.size() > 0) {
switch(x[0]) {
case 0x0: // button release
id(can_bus_button).publish_state(false);
break;
case 0x1: // button press
id(can_bus_button).publish_state(true);
break;
}
}
Cover Example
-------------
In this example, three nodes are connected to the CAN bus:
- Node 1 sends a one-byte payload to ID ``0x50B``
- Node 2 sends a one-byte payload to ID ``0x50C``
These nodes send the following one-byte payload which is based on the state of a button connected to each of them:
- 0: Button release
- 1: Button press
- 2: Long press
- 3: Long release
- 4: Double-click
- Node 3 controls a motor connected to it. It expects a message to ID ``0x51A`` where the one-byte payload is:
- 0: Off
- 1: Open
- 2: Close
.. code-block:: yaml
canbus:
- platform: ...
id: my_canbus
can_id: 4
bit_rate: 125kbps
on_frame:
- can_id: 0x50c
then:
- lambda: |-
if(x.size() > 0) {
auto call = id(TestCover).make_call();
switch(x[0]) {
case 0x2: call.set_command_open(); call.perform(); break; // long press
case 0x1: // button press
case 0x3: call.set_command_stop(); call.perform(); break; // long release
case 0x4: call.set_position(1.0); call.perform(); break; // double-click
}
}
- can_id: 0x50b
then:
- lambda: |-
if(x.size() > 0) {
auto call = id(TestCover).make_call();
switch(x[0]) {
case 0x2: call.set_command_close(); call.perform(); break; // long press
case 0x1: // button press
case 0x3: call.set_command_stop(); call.perform(); break; // long release
case 0x4: call.set_position(0.0); call.perform(); break; // double-click
}
}
cover:
- platform: time_based
name: Canbus Test Cover
id: TestCover
device_class: shutter
has_built_in_endstop: true
open_action:
- canbus.send:
data: [ 0x01 ]
canbus_id: my_canbus
can_id: 0x51A
open_duration: 2min
close_action:
- canbus.send:
data: [ 0x02 ]
canbus_id: my_canbus
can_id: 0x51A
close_duration: 2min
stop_action:
- canbus.send:
data: [ 0x00 ]
canbus_id: my_canbus
can_id: 0x51A
See Also
--------
- :apiref:`canbus/canbus.h`
- :ghedit:`Edit`

79
components/canbus/mcp2515.rst Normal file
View File

@ -0,0 +1,79 @@
MCP2515
=======
.. seo::
:description: Instructions for setting up the MCP2515 CAN bus platform in ESPHome
:image: canbus.svg
:keywords: CAN, MCP2515
The MCP2515 communicates with ESPHome via the :ref:`SPI bus <spi>`; to use it, you must have at least one
:ref:`SPI bus <spi>` with both the ``mosi_pin`` and ``miso_pin`` defined in your ESPHome configuration.
The :ref:`mcp2515-wiring` section below illustrates how to wire up your MCP2515.
.. code-block:: yaml
# Example configuration entry
canbus:
- platform: mcp2515
cs_pin: GPIOXX
can_id: 4
bit_rate: 50kbps
on_frame:
- can_id: 500
then:
- lambda: |-
std::string b(x.begin(), x.end());
ESP_LOGD("canid 500", "%s", &b[0] );
- light.turn_off: light_1
- can_id: 501
then:
- light.turn_on:
id: light_1
brightness: !lambda "return (x.size() > 0) ? (float) x[0]/255 : 0;"
Configuration variables:
------------------------
- **cs_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): Is used to signal to a SPI device when it should
listen for data on the SPI bus. Each SPI device has its own ``CS`` line. Sometimes also called ``SS``.
- **clock** (*Optional*, frequency): The frequency of the clock crystal used on the MCP2515 device. One of ``8MHZ``,
``12MHz``, ``16MHZ`` or ``20MHZ``. Defaults to ``8MHZ``.
- **mode** (*Optional*, enum): Operating mode. One of:
- ``NORMAL``: Normal operation. *(default)*
- ``LOOPBACK``: Loopback mode is useful for testing your connections to/from the device.
- ``LISTENONLY``: Receive data only.
- All other options from :ref:`Canbus <config-canbus>`.
.. note::
Not all combinations of clock and bitrate are supported. An unsupported combination will not be flagged at
compile time. Check your ESPHome device's logs for a message like ``Invalid frequency/bitrate combination``
if you suspect this is an issue.
.. _mcp2515-wiring:
Wiring options
--------------
The easiest approach is to use fully assembled boards and just add one resistor on the MISO line. This runs MOSI, SCK
and CS out of specification which is rarely a problem.
.. figure:: images/canbus_mcp2515_resistor.png
:align: center
:target: ../_images/canbus_mcp2515_resistor.png
A more complex option is to properly convert the 3.3V and 5V logic levels with a level shifter.
.. figure:: images/canbus_mcp2515_txs0108e.png
:align: center
:target: ../_images/canbus_mcp2515_txs0108e.png
See Also
--------
- :doc:`index`
- :apiref:`canbus/canbus.h`
- :ghedit:`Edit`

2
components/climate/anova.rst
View File

@ -36,7 +36,7 @@ need to do conversion again within the frontend if you use Fahrenheit.
.. code-block:: yaml
ble_client:
- mac_address: 11:22:33:aa:bb:cc
- mac_address: XX:XX:XX:XX:XX:XX
id: my_anova
climate:

2
components/climate/bedjet.rst
View File

@ -31,7 +31,7 @@ and delegates status updates to individual platform components.
esp32_ble_tracker:
ble_client:
- mac_address: C4:4F:33:00:00:01
- mac_address: XX:XX:XX:XX:XX:XX
id: bedjet_ble_id1
bedjet:

2
components/cover/am43.rst
View File

@ -27,7 +27,7 @@ and state of the motor.
esp32_ble_tracker:
ble_client:
- mac_address: AA:BB:CC:DD:EE:FF
- mac_address: XX:XX:XX:XX:XX:XX
id: am43_kitchen
cover:

12
components/display/pvvx_mithermometer.rst
View File

@ -29,7 +29,7 @@ The firmware configuration can be changed via browser using `TelinkMiFlasher.htm
esp32_ble_tracker:
ble_client:
- mac_address: "A4:C1:38:B1:CD:7F"
- mac_address: XX:XX:XX:XX:XX:XX
id: pvvx_ble_display
display:
@ -139,12 +139,12 @@ The following example display the sensor states of a MiFlora sensor on a pvvx di
esp32_ble_tracker:
ble_client:
- mac_address: "A4:C1:38:B1:CD:7F"
- mac_address: XX:XX:XX:XX:XX:XX
id: pvvx_ble_display
sensor:
- platform: pvvx_mithermometer
mac_address: "A4:C1:38:B1:CD:7F"
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "PVVX Temperature"
humidity:
@ -154,7 +154,7 @@ The following example display the sensor states of a MiFlora sensor on a pvvx di
battery_voltage:
name: "PVVX Battery-Voltage"
- platform: xiaomi_hhccjcy01
mac_address: '94:2B:FF:5C:91:61'
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "Xiaomi HHCCJCY01 Temperature"
id: miflora_temperature
@ -199,12 +199,12 @@ The following example will synchronized the time of the pvvx device once a day.
esp32_ble_tracker:
ble_client:
- mac_address: "A4:C1:38:B1:CD:7F"
- mac_address: XX:XX:XX:XX:XX:XX
id: pvvx_ble_display
sensor:
- platform: pvvx_mithermometer
mac_address: "A4:C1:38:B1:CD:7F"
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "PVVX Temperature"
humidity:

20
components/esp32_ble_tracker.rst
View File

@ -14,7 +14,7 @@ the MAC address of a device and track it using ESPHome.
.. warning::
The BLE software stack on the ESP32 consumes a significant amount of RAM on the device.
**Crashes are likely to occur** if you include too many additional components in your device's
configuration. Memory-intensive components such as :doc:`/components/voice_assistant` and other
audio components are most likely to cause issues.
@ -26,15 +26,15 @@ the MAC address of a device and track it using ESPHome.
binary_sensor:
- platform: ble_presence
mac_address: AC:37:43:77:5F:4C
mac_address: XX:XX:XX:XX:XX:XX
name: "ESP32 BLE Presence Google Home Mini"
sensor:
- platform: ble_rssi
mac_address: AC:37:43:77:5F:4C
mac_address: XX:XX:XX:XX:XX:XX
name: "BLE Google Home Mini RSSI value"
- platform: xiaomi_hhccjcy01
mac_address: 94:2B:FF:5C:91:61
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "Xiaomi MiFlora Temperature"
moisture:
@ -46,7 +46,7 @@ the MAC address of a device and track it using ESPHome.
battery_level:
name: "Xiaomi MiFlora Battery Level"
- platform: xiaomi_lywsdcgq
mac_address: 7A:80:8E:19:36:BA
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "Xiaomi MiJia Temperature"
humidity:
@ -116,9 +116,9 @@ This automation will be triggered when a Bluetooth advertising is received. A va
esp32_ble_tracker:
on_ble_advertise:
- mac_address:
- 11:11:11:11:11:11
- 22:22:22:22:22:22
- mac_address:
- XX:XX:XX:XX:XX:XX
- XX:XX:XX:XX:XX:XX
then:
- lambda: |-
ESP_LOGD("ble_adv", "New BLE device");
@ -159,7 +159,7 @@ variable ``x`` of type ``std::vector<uint8_t>`` is passed to the automation for
esp32_ble_tracker:
on_ble_manufacturer_data_advertise:
- mac_address: 11:22:33:44:55:66
- mac_address: XX:XX:XX:XX:XX:XX
manufacturer_id: 0590
then:
- lambda: |-
@ -190,7 +190,7 @@ variable ``x`` of type ``std::vector<uint8_t>`` is passed to the automation for
esp32_ble_tracker:
on_ble_service_data_advertise:
- mac_address: 11:22:33:44:55:66
- mac_address: XX:XX:XX:XX:XX:XX
service_uuid: 181A
then:
- lambda: 'id(ble_sensor).publish_state(x[0]);'

10
components/http_request.rst
View File

@ -88,8 +88,8 @@ This :ref:`action <config-action>` sends a GET request.
- logger.log:
format: 'Response status: %d, Duration: %u ms'
args:
- status_code
- duration_ms
- response->status_code
- response->duration_ms
# Short form
- http_request.get: https://esphome.io
@ -159,7 +159,7 @@ This :ref:`action <config-action>` sends a request.
This automation will be triggered when the HTTP request is complete.
The following variables are available for use in :ref:`lambdas <config-lambda>`:
- ``response`` as a ``HttpContainer`` object which contains ``content_length``, ``status_code`` and ``duration_ms``.
- ``response`` as a pointer to ``HttpContainer`` object which contains ``content_length``, ``status_code`` and ``duration_ms``.
- ``body`` as ``std::string`` which contains the response body when ``capture_response``
(see :ref:`http_request-get_action`) is set to ``true``.
@ -174,8 +174,8 @@ The following variables are available for use in :ref:`lambdas <config-lambda>`:
- logger.log:
format: "Response status: %d, Duration: %u ms"
args:
- response.status_code
- response.duration_ms
- response->status_code
- response->duration_ms
.. _http_request-examples:

1
components/index.rst
View File

@ -6,6 +6,7 @@ Components
:glob:
binary_sensor/index
canbus/index
climate/index
cover/index
fan/index

6
components/output/ble_client.rst
View File

@ -12,7 +12,7 @@ For more information on BLE services and characteristics, see :doc:`/components/
.. warning::
The BLE software stack on the ESP32 consumes a significant amount of RAM on the device.
**Crashes are likely to occur** if you include too many additional components in your device's
configuration. Memory-intensive components such as :doc:`/components/voice_assistant` and other
audio components are most likely to cause issues.
@ -22,7 +22,7 @@ For more information on BLE services and characteristics, see :doc:`/components/
esp32_ble_tracker:
ble_client:
- mac_address: FF:FF:20:00:0F:15
- mac_address: XX:XX:XX:XX:XX:XX
id: itag_black
output:
@ -39,7 +39,7 @@ Configuration variables:
- **service_uuid** (**Required**, UUID): UUID of the service on the device.
- **characteristic_uuid** (**Required**, UUID): UUID of the service's characteristic to write to.
- **id** (*Optional*, :ref:`config-id`): The ID to use for code generation, and for reference by dependent components.
- **require_response** (*Optional*, boolean): Control whether to require a remote response from the device when writing.
- **require_response** (*Optional*, boolean): Control whether to require a remote response from the device when writing.
Whether or not this is required will vary by device. Defaults to ``false``
- All other options from :ref:`Output <config-output>`.

6
components/sensor/airthings_ble.rst
View File

@ -29,7 +29,7 @@ The device will then listen for nearby devices, and display a message like this
.. code-block:: text
[D][airthings_ble:019]:
Found AirThings device Serial: 123456789 (MAC: 01:02:03:04:05:06)
Found AirThings device Serial: 123456789 (MAC: XX:XX:XX:XX:XX:XX)
Once the device is found, remove the ``airthings_ble`` device tracker from your configuration and take note of the device MAC address, and use it when configuring a sensor below.
@ -75,7 +75,7 @@ Configuration example:
name: "WavePlus Battery Voltage"
ble_client:
- mac_address: 01:02:03:04:05:06
- mac_address: XX:XX:XX:XX:XX:XX
id: airthings01
esp32_ble_tracker:
@ -110,7 +110,7 @@ Configuration example:
name: "WaveMini Battery Voltage"
ble_client:
- mac_address: 01:02:03:04:05:06
- mac_address: XX:XX:XX:XX:XX:XX
id: airthingsmini
esp32_ble_tracker:

2
components/sensor/am43.rst
View File

@ -25,7 +25,7 @@ to the device over the ESP32's BLE peripheral.
esp32_ble_tracker:
ble_client:
- mac: AA:BB:CC:DD:EE:FF
- mac: XX:XX:XX:XX:XX:XX
id: am43_device
sensor:

2
components/sensor/b_parasite.rst
View File

@ -24,7 +24,7 @@ The ``b_parasite`` sensor platform tracks b-parasite's Bluetooth Low Energy (BLE
sensor:
- platform: b_parasite
mac_address: F0:CA:F0:CA:01:01
mac_address: XX:XX:XX:XX:XX:XX
humidity:
name: 'b-parasite Air Humidity'
temperature:

4
components/sensor/ble_client.rst
View File

@ -13,7 +13,7 @@ For more information on BLE services and characteristics, see :doc:`/components/
.. warning::
The BLE software stack on the ESP32 consumes a significant amount of RAM on the device.
**Crashes are likely to occur** if you include too many additional components in your device's
configuration. Memory-intensive components such as :doc:`/components/voice_assistant` and other
audio components are most likely to cause issues.
@ -23,7 +23,7 @@ For more information on BLE services and characteristics, see :doc:`/components/
esp32_ble_tracker:
ble_client:
- mac_address: FF:FF:20:00:0F:15
- mac_address: XX:XX:XX:XX:XX:XX
id: itag_black
sensor:

4
components/sensor/ble_rssi.rst
View File

@ -13,7 +13,7 @@ instructions for setting up this platform.
.. warning::
The BLE software stack on the ESP32 consumes a significant amount of RAM on the device.
**Crashes are likely to occur** if you include too many additional components in your device's
configuration. Memory-intensive components such as :doc:`/components/voice_assistant` and other
audio components are most likely to cause issues.
@ -26,7 +26,7 @@ instructions for setting up this platform.
sensor:
# RSSI based on MAC address
- platform: ble_rssi
mac_address: AC:37:43:77:5F:4C
mac_address: XX:XX:XX:XX:XX:XX
name: "BLE Google Home Mini RSSI value"
# RSSI based on Identity Resolving Key (IRK)
- platform: ble_rssi

10
components/sensor/inkbird_ibsth1_mini.rst
View File

@ -38,7 +38,7 @@ many IBS-TH1/TH2 devices at once as you want.
sensor:
- platform: inkbird_ibsth1_mini
mac_address: 38:81:D7:0A:9C:11
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "Inkbird IBS-TH1 Temperature"
external_temperature:
@ -88,21 +88,21 @@ like so:
esp32_ble_tracker:
After uploading the ESP32 will immediately try to scan for BLE devices such as the Inkbird IBS-TH1/TH2.
After uploading the ESP32 will immediately try to scan for BLE devices such as the Inkbird IBS-TH1/TH2.
When it detects these sensors, it will automatically parse the BLE message print a
message like this one:
.. code::
[13:36:43][D][esp32_ble_tracker:544]: Found device 38:81:D7:0A:9C:11 RSSI=-53
[13:36:43][D][esp32_ble_tracker:544]: Found device XX:XX:XX:XX:XX:XX RSSI=-53
[13:36:43][D][esp32_ble_tracker:565]: Address Type: PUBLIC
[13:36:43][D][esp32_ble_tracker:567]: Name: 'sps'
Note that it can sometimes take some time for the first BLE broadcast to be received. Please note that address type
should say 'PUBLIC' and the device name should be 'sps', this is how you find the Inkbird IBS-TH1/TH2 among all the
should say 'PUBLIC' and the device name should be 'sps', this is how you find the Inkbird IBS-TH1/TH2 among all the
other devices.
Then just copy the address (``38:81:D7:0A:9C:11``) into a new ``sensor.inkbird_ibsth1_mini`` platform
Then just copy the address (``XX:XX:XX:XX:XX:XX``) into a new ``sensor.inkbird_ibsth1_mini`` platform
entry like in the configuration example at the top.
.. note::

14
components/sensor/mopeka_pro_check.rst
View File

@ -9,7 +9,7 @@ Mopeka Pro Check BLE Sensor
The ``mopeka_pro_check`` sensor platform lets you track the output of Mopeka Pro
Check LP, Mopeka Pro Plus, Mopeka Pro Universal or Lippert Propane Tank Sensors, Bluetooth Low
Energy devices using the :doc:`/components/esp32_ble_tracker`. This component
will track the tank level, distance, temperature, and battery percentage of a
will track the tank level, distance, temperature, and battery percentage of a
device every time the sensor sends out a BLE broadcast.
.. warning::
@ -21,7 +21,7 @@ device every time the sensor sends out a BLE broadcast.
+ Lippert Propane Tank Sensor, part number 2021130655
Sensors are calibrated for propane only.
See :doc:`/components/sensor/mopeka_std_check` for original Mopeka Check sensors support.
.. figure:: images/mopeka_pro_check.jpg
@ -32,7 +32,7 @@ device every time the sensor sends out a BLE broadcast.
.. figure:: images/mopeka_pro_check_lippert.jpg
:align: center
Lippert™ Propane Tank Sensor
Lippert™ Propane Tank Sensor
The original Mopeka Check sensors are not supported.
@ -46,7 +46,7 @@ Mopeka Pro Check LP over BLE:
sensor:
# Example using 20lb vertical propane tank.
- platform: mopeka_pro_check
mac_address: D3:75:F2:DC:16:91
mac_address: XX:XX:XX:XX:XX:XX
tank_type: 20LB_V
temperature:
name: "Propane test temp"
@ -59,7 +59,7 @@ Mopeka Pro Check LP over BLE:
# Custom example - user defined empty / full points
- platform: mopeka_pro_check
mac_address: D3:75:F2:DC:16:91
mac_address: XX:XX:XX:XX:XX:XX
tank_type: CUSTOM
custom_distance_full: 40cm
custom_distance_empty: 10mm
@ -137,9 +137,9 @@ For all sensors found the ``mopeka_ble`` component will print a message like thi
.. code::
[20:43:26][I][mopeka_ble:074]: MOPEKA PRO (NRF52) SENSOR FOUND: D3:75:F2:DC:16:91
[20:43:26][I][mopeka_ble:074]: MOPEKA PRO (NRF52) SENSOR FOUND: XX:XX:XX:XX:XX:XX
Then just copy the address (``D3:75:F2:DC:16:91``) into a new
Then just copy the address (``XX:XX:XX:XX:XX:XX``) into a new
``sensor.mopeka_pro_check`` platform entry like in the configuration example at the top.
.. note::

16
components/sensor/mopeka_std_check.rst
View File

@ -7,9 +7,9 @@ Mopeka Standard Check BLE Sensor
:keywords: Mopeka, Mopeka Standard Check, Mopeka Std Check, BLE, Bluetooth
The ``mopeka_std_check`` sensor platform lets you track the output of Mopeka
Standard Check LP Bluetooth Low Energy devices using the
:doc:`/components/esp32_ble_tracker`. This component will track the tank level,
distance, temperature, and battery percentage of a Mopeka Standard Check LP BLE
Standard Check LP Bluetooth Low Energy devices using the
:doc:`/components/esp32_ble_tracker`. This component will track the tank level,
distance, temperature, and battery percentage of a Mopeka Standard Check LP BLE
device every time the sensor sends out a BLE broadcast.
.. warning::
@ -29,7 +29,7 @@ device every time the sensor sends out a BLE broadcast.
sensor:
# Example using 11kg 100% propane tank.
- platform: mopeka_std_check
mac_address: D3:75:F2:DC:16:91
mac_address: XX:XX:XX:XX:XX:XX
tank_type: Europe_11kg
temperature:
name: "Propane test temp"
@ -42,7 +42,7 @@ device every time the sensor sends out a BLE broadcast.
# Custom example - user defined empty / full points and 80% butane and 20% propane.
- platform: mopeka_std_check
mac_address: D3:75:F2:DC:16:91
mac_address: XX:XX:XX:XX:XX:XX
tank_type: CUSTOM
custom_distance_full: 40cm
custom_distance_empty: 32mm
@ -125,15 +125,15 @@ and the ``mopeka_ble`` component like so:
mopeka_ble:
After uploading, the ESP32 will immediately try to scan for BLE devices. For Mopeka Standard devices you must press and hold the green sync button for it to be identified.
After uploading, the ESP32 will immediately try to scan for BLE devices. For Mopeka Standard devices you must press and hold the green sync button for it to be identified.
Or alternativly set the configuration flag ``show_sensors_without_sync: true`` to see all devices.
For all sensors found the ``mopeka_ble`` component will print a message like this one:
.. code::
[20:43:26][I][mopeka_ble:056]: MOPEKA STD (CC2540) SENSOR FOUND: D3:75:F2:DC:16:91
[20:43:26][I][mopeka_ble:056]: MOPEKA STD (CC2540) SENSOR FOUND: XX:XX:XX:XX:XX:XX
Then just copy the address (``D3:75:F2:DC:16:91``) into a new
Then just copy the address (``XX:XX:XX:XX:XX:XX``) into a new
``sensor.mopeka_std_check`` platform entry like in the configuration example at the top.
.. note::

7
components/sensor/radon_eye_ble.rst
View File

@ -29,7 +29,7 @@ The device will then listen for nearby devices, and display a message like this
.. code-block:: text
[D][radon_eye_ble:017]:
Found Radon Eye RD200 device Name: FR:R20:SN1234 (MAC: 01:02:03:04:05:06)
Found Radon Eye RD200 device Name: FR:R20:SN1234 (MAC: XX:XX:XX:XX:XX:XX)
Once the device is found, remove the ``radon_eye_ble`` device tracker from your configuration and
take note of the device MAC address, and use it when configuring a sensor below.
@ -61,7 +61,7 @@ Configuration example:
esp32_ble_tracker:
ble_client:
- mac_address: 01:02:03:04:05:06
- mac_address: XX:XX:XX:XX:XX:XX
id: radon_eye_ble_id
sensor:
@ -80,7 +80,7 @@ Here is an example to use pCi/L (to match the value on the device display):
esp32_ble_tracker:
ble_client:
- mac_address: 01:02:03:04:05:06
- mac_address: XX:XX:XX:XX:XX:XX
id: radon_eye_ble_id
sensor:
@ -99,4 +99,3 @@ Here is an example to use pCi/L (to match the value on the device display):
accuracy_decimals: 2
filters:
- lambda: return x / 37;

6
components/sensor/ruuvitag.rst
View File

@ -30,7 +30,7 @@ movement count and measurement sequence number are also tracked.
sensor:
- platform: ruuvitag
mac_address: FF:56:D3:2F:7D:E8
mac_address: XX:XX:XX:XX:XX:XX
humidity:
name: "RuuviTag Humidity"
temperature:
@ -167,11 +167,11 @@ print a message like this one:
.. code::
Got ruuvi RuuviTag (FF:56:D3:2F:7D:E8): Humidity: 67.5%, Temperature: 22.97°C,
Got ruuvi RuuviTag (XX:XX:XX:XX:XX:XX): Humidity: 67.5%, Temperature: 22.97°C,
Pressure: 977.09hPa, Acceleration X: 0.005G, Acceleration Y: 0.017G, Acceleration Z: 1.066G,
Battery Voltage: 3.223V
Then just copy the address (``FF:56:D3:2F:7D:E8``) into a new
Then just copy the address (``XX:XX:XX:XX:XX:XX``) into a new
``sensor.ruuvitag`` platform entry like in the configuration example at the top.
.. note::

48
components/sensor/xiaomi_ble.rst
View File

@ -32,7 +32,7 @@ Configuration example:
sensor:
- platform: xiaomi_hhccjcy01
mac_address: '94:2B:FF:5C:91:61'
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "Xiaomi HHCCJCY01 Temperature"
moisture:
@ -64,7 +64,7 @@ Configuration example:
sensor:
- platform: xiaomi_gcls002
mac_address: "94:2B:FF:5C:91:61"
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "GCLS02 Temperature"
moisture:
@ -89,7 +89,7 @@ Configuration example:
sensor:
- platform: xiaomi_hhccpot002
mac_address: "94:2B:FF:5C:91:61"
mac_address: XX:XX:XX:XX:XX:XX
moisture:
name: "HHCCPOT002 Moisture"
conductivity:
@ -110,7 +110,7 @@ Configuration example:
sensor:
- platform: xiaomi_lywsdcgq
mac_address: "7A:80:8E:19:36:BA"
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "LYWSDCGQ Temperature"
humidity:
@ -135,7 +135,7 @@ Configuration example:
sensor:
- platform: xiaomi_lywsd02
mac_address: "3F:5B:7D:82:58:4E"
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "LYWSD02 Temperature"
humidity:
@ -160,7 +160,7 @@ Configuration example:
sensor:
- platform: xiaomi_cgg1
mac_address: "7A:80:8E:19:36:BA"
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "CGG1 Temperature"
humidity:
@ -168,7 +168,7 @@ Configuration example:
battery_level:
name: "CGG1 Battery Level"
- platform: xiaomi_cgg1
mac_address: "7A:80:8E:28:39:CD"
mac_address: XX:XX:XX:XX:XX:XX
bindkey: "00112233445566778899aabbccddeeff"
temperature:
name: "CGG1 (New) Temperature"
@ -200,7 +200,7 @@ Configuration example for Xiaomi stock firmware or ATC MiThermometer firmware se
sensor:
- platform: xiaomi_lywsd03mmc
mac_address: "A4:C1:38:B1:CD:7F"
mac_address: XX:XX:XX:XX:XX:XX
bindkey: "eef418daf699a0c188f3bfd17e4565d9"
temperature:
name: "LYWSD03MMC Temperature"
@ -215,7 +215,7 @@ Configuration example for PVVX MiThermometer firmware set to "Custom" advertisem
sensor:
- platform: pvvx_mithermometer
mac_address: "A4:C1:38:B1:CD:7F"
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "PVVX Temperature"
humidity:
@ -233,7 +233,7 @@ Configuration example for ATC MiThermometer firmware set to "Custom" advertiseme
sensor:
- platform: atc_mithermometer
mac_address: "A4:C1:38:B1:CD:7F"
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "ATC Temperature"
humidity:
@ -263,7 +263,7 @@ Configuration example:
sensor:
- platform: xiaomi_mhoc303
mac_address: "E7:50:59:32:A0:1C"
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "MHO-C303 Climate Temperature"
humidity:
@ -296,7 +296,7 @@ Configuration example for Xiaomi stock firmware:
sensor:
- platform: xiaomi_mhoc401
mac_address: "A4:C1:38:B1:CD:7F"
mac_address: XX:XX:XX:XX:XX:XX
bindkey: "eef418daf699a0c188f3bfd17e4565d9"
temperature:
name: "MHOC401 Temperature"
@ -311,7 +311,7 @@ Configuration example for PVVX MiThermometer firmware set to "Custom" advertisem
sensor:
- platform: pvvx_mithermometer
mac_address: "A4:C1:38:B1:CD:7F"
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "PVVX Temperature"
humidity:
@ -337,7 +337,7 @@ Configuration example:
sensor:
- platform: xiaomi_cgd1
mac_address: "A4:C1:38:8C:34:B7"
mac_address: XX:XX:XX:XX:XX:XX
bindkey: "fe39106baeedb7c801e3d63c4396f97e"
temperature:
name: "CGD1 Temperature"
@ -362,7 +362,7 @@ Configuration example:
sensor:
- platform: xiaomi_cgdk2
mac_address: "58:2D:34:11:34:B7"
mac_address: XX:XX:XX:XX:XX:XX
bindkey: "fe39106baeedb7c801e3d63c4396f97e"
temperature:
name: "CGDK2 Temperature"
@ -386,7 +386,7 @@ Configuration example:
sensor:
- platform: xiaomi_jqjcy01ym
mac_address: "7A:80:8E:19:36:BA"
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "JQJCY01YM Temperature"
humidity:
@ -413,7 +413,7 @@ Configuration example:
binary_sensor:
- platform: xiaomi_wx08zm
mac_address: "74:a3:4a:b5:07:34"
mac_address: XX:XX:XX:XX:XX:XX
tablet:
name: "WX08ZM Mosquito Tablet"
battery_level:
@ -437,7 +437,7 @@ Configuration example:
binary_sensor:
- platform: xiaomi_mue4094rt
name: "MUE4094RT Night Light"
mac_address: "7A:80:8E:19:36:BA"
mac_address: XX:XX:XX:XX:XX:XX
timeout: "5s"
MJYD02YL-A
@ -458,7 +458,7 @@ Configuration example:
binary_sensor:
- platform: xiaomi_mjyd02yla
name: "MJYD02YL-A Night Light"
mac_address: "50:EC:50:CD:32:02"
mac_address: XX:XX:XX:XX:XX:XX
bindkey: "48403ebe2d385db8d0c187f81e62cb64"
idle_time:
name: "MJYD02YL-A Idle Time"
@ -485,7 +485,7 @@ Configuration example:
binary_sensor:
- platform: xiaomi_cgpr1
name: "CGPR1 Motion detector"
mac_address: 58:2D:34:60:32:A2
mac_address: XX:XX:XX:XX:XX:XX
bindkey: "ff1ae526b23b4aebeadcaaad86f59055"
idle_time:
name: "CGPR1 Idle Time"
@ -510,7 +510,7 @@ Configuration example:
xiaomi_rtcgq02lm:
- id: motion_one
mac_address: 01:23:45:67:89:AB
mac_address: XX:XX:XX:XX:XX:XX
bindkey: fe39106baeedb7c801e3d63c4396f97e
binary_sensor:
@ -567,11 +567,11 @@ After uploading, the ESP32 will immediately try to scan for BLE devices. When it
.. code::
Found device A4:C1:38:4E:16:78 RSSI=-78
Found device XX:XX:XX:XX:XX:XX RSSI=-78
Address Type: PUBLIC
Name: 'LYWSD03MMC'
It can sometimes take some time for the first BLE broadcast to be received. Once the device has been found, copy the address ``A4:C1:38:4E:16:78`` into a new platform entry like shown in the example configurations.
It can sometimes take some time for the first BLE broadcast to be received. Once the device has been found, copy the address ``XX:XX:XX:XX:XX:XX`` into a new platform entry like shown in the example configurations.
.. _obtaining_the_bindkey:
@ -621,7 +621,7 @@ Another option is to use a SSL packet sniffer. It can be setup on either an Andr
packet: POST /app/device/bltbind
"data" = "{"did":"blt.3.129q4nasgeg00","token":"20c665a7ff82a5bfb5eefc36","props":[{"type":"prop","key":"bind_key","value":"cfc7cc892f4e32f7a733086cf3443cb0"}, {"type":"prop","key":"smac","value":"A4:C1:38:8C:34:B7"}]}"
"data" = "{"did":"blt.3.129q4nasgeg00","token":"20c665a7ff82a5bfb5eefc36","props":[{"type":"prop","key":"bind_key","value":"cfc7cc892f4e32f7a733086cf3443cb0"}, {"type":"prop","key":"smac","value":XX:XX:XX:XX:XX:XX}]}"
The ``bind_key`` is the 32 digits "value" item in the above output which needs to be inserted into the config file.

2
components/sensor/xiaomi_hhccjcy10.rst
View File

@ -16,7 +16,7 @@ MiFlora, tuya (pink) version, measures temperature, moisture, ambient light and
sensor:
- platform: xiaomi_hhccjcy10
mac_address: '94:2B:FF:5C:91:61'
mac_address: XX:XX:XX:XX:XX:XX
temperature:
name: "Xiaomi HHCCJCY10 Temperature"
moisture:

4
components/sensor/xiaomi_miscale.rst
View File

@ -26,7 +26,7 @@ Miscale (left) measures weight only. Miscale2 (right) measures weight and impeda
sensor:
- platform: xiaomi_miscale
mac_address: '5C:CA:D3:70:D4:A2'
mac_address: XX:XX:XX:XX:XX:XX
weight:
name: "Xiaomi Mi Scale Weight"
impedance:
@ -59,7 +59,7 @@ You have to replace the numbers in the lambdas to determine your weight which is
sensor:
- platform: xiaomi_miscale
mac_address: '5C:CA:D3:70:D4:A2'
mac_address: XX:XX:XX:XX:XX:XX
weight:
name: "Xiaomi Mi Scale Weight"
id: weight_miscale

4
components/switch/ble_client.rst
View File

@ -13,7 +13,7 @@ For more information on BLE services and characteristics, see :doc:`/components/
.. warning::
The BLE software stack on the ESP32 consumes a significant amount of RAM on the device.
**Crashes are likely to occur** if you include too many additional components in your device's
configuration. Memory-intensive components such as :doc:`/components/voice_assistant` and other
audio components are most likely to cause issues.
@ -23,7 +23,7 @@ For more information on BLE services and characteristics, see :doc:`/components/
esp32_ble_tracker:
ble_client:
- mac_address: FF:FF:20:00:0F:15
- mac_address: XX:XX:XX:XX:XX:XX
id: itag_black
switch:

2
components/text_sensor/ble_client.rst
View File

@ -16,7 +16,7 @@ For more information on BLE services and characteristics, see
esp32_ble_tracker:
ble_client:
- mac_address: FF:FF:20:00:0F:15
- mac_address: XX:XX:XX:XX:XX:XX
id: itag_black
text_sensor:

4
components/text_sensor/ble_scanner.rst
View File

@ -19,7 +19,7 @@ the data in JSON format.
.. warning::
The BLE software stack on the ESP32 consumes a significant amount of RAM on the device.
**Crashes are likely to occur** if you include too many additional components in your device's
configuration. Memory-intensive components such as :doc:`/components/voice_assistant` and other
audio components are most likely to cause issues.
@ -39,7 +39,7 @@ Example json log:
{
"timestamp":1578254525,
"address":"D7:E7:E7:66:DD:33",
"address": "XX:XX:XX:XX:XX:XX",
"rssi":"-80",
"name":"MI Band 2"
}

1
images/mcp2515.svg Normal file
View File

@ -0,0 +1 @@
<svg viewBox="0 0 132 25" id="svg5" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg"><defs id="defs9"/><path d="M5 0H127a5 5 0 015 5v15a5 5 0 01-5 5H5a5 5 0 01-5-5V5a5 5 0 015-5z" style="fill:#000" id="path2"/><g aria-label="MCP2515" id="component-text" style="font-weight:900;font-size:25px;font-family:Montserrat;letter-spacing:1.1px;fill:#fffffc"><path d="M6.425 21V3.5h4.85l7 11.425h-2.55L22.525 3.5h4.85L27.425 21H22.05L22 11.6h.85L18.2 19.425H15.6L10.75 11.6H11.8V21z" id="path11"/><path d="m40.425012 21.4q-2.1.0-3.9-.65-1.775-.675-3.1-1.9-1.3-1.225-2.025-2.9-.725-1.675-.725-3.7t.725-3.7q.725-1.675 2.025-2.9 1.325-1.225 3.1-1.875 1.8-.675 3.9-.675 2.575.0 4.55.9 2 .9 3.3 2.6l-3.725 3.325q-.775-.975-1.725-1.5-.925-.55-2.1-.55-.925.0-1.675.3t-1.3.875q-.525.575-.825 1.4-.3.8-.3 1.8t.3 1.825q.3.8.825 1.375.55.575 1.3.875t1.675.3q1.175.0 2.1-.525.95-.55 1.725-1.525l3.725 3.325q-1.3 1.675-3.3 2.6-1.975.9-4.55.9z" id="path13"/><path d="M51.074998 21V3.5h8.425q2.45.0 4.225.8 1.8.8 2.775 2.3.975 1.475.975 3.5t-.975 3.5-2.775 2.3q-1.775.8-4.225.8h-5.15l2.625-2.525V21zm5.9-6.175-2.625-2.675h4.775q1.225.0 1.8-.55.6-.55.6-1.5t-.6-1.5q-.575-.55-1.8-.55h-4.775l2.625-2.675z" id="path15"/><path d="m69.90002 21v-3.625l6.325-5.85q.6-.575.875-1 .3-.425.4-.75.1-.35.1-.65.0-.65-.425-1-.425-.375-1.275-.375-.775.0-1.475.425-.7.4-1.1 1.2l-4.45-2.225q.95-1.8 2.85-2.925 1.9-1.125 4.725-1.125 2.075.0 3.675.675t2.5 1.9q.9 1.225.9 2.9.0.85-.225 1.7-.2.85-.85 1.8-.65.925-1.925 2.075l-4.75 4.325-.925-2.05h9.075V21z" id="path17"/><path d="m92.525015 21.4q-1.8.0-3.65-.4-1.85-.4-3.25-1.175l2-4.35q1.125.65 2.35.975 1.225.3 2.325.3 1 0 1.65-.35t.65-1.025q0-.375-.225-.65-.225-.3-.8-.45-.55-.15-1.625-.15h-5.075l.875-10.625h11.625v4.45h-9.55l2.975-2.525-.525 6.775-2.975-2.525h4.075q2.6.0 4.15.75 1.575.75 2.275 2.025.725005 1.25.725005 2.8t-.850005 2.975q-.825 1.4-2.6 2.3-1.75.875-4.55.875z" id="path19"/><path d="M105.2 21V5.55l2.525 2.4H102.2V3.5h8.9V21z" id="path21"/><path d="m120.64998 21.4q-1.8.0-3.65-.4-1.85-.4-3.25-1.175l2-4.35q1.125.65 2.35.975 1.225.3 2.325.3 1 0 1.65-.35t.65-1.025q0-.375-.225-.65-.225-.3-.8-.45-.55-.15-1.625-.15h-5.075l.875-10.625h11.625v4.45h-9.55l2.975-2.525-.525 6.775-2.975-2.525h4.075q2.6.0 4.15.75 1.575.75 2.275 2.025.725 1.25.725 2.8t-.85 2.975q-.825 1.4-2.6 2.3-1.75.875-4.55.875z" id="path23"/></g></svg>
Side by Side

After

Width:  |  Height:  |  Size: 2.3 KiB

11
index.rst
View File

@ -243,7 +243,7 @@ Hardware Peripheral Interfaces/Busses
.. imgtable::
CAN Bus, components/canbus, canbus.svg
CAN Bus, components/canbus/index, canbus.svg
I²C Bus, components/i2c, i2c.svg
I²S Audio, components/i2s_audio, i2s_audio.svg
SPI Bus, components/spi, spi.svg
@ -268,6 +268,15 @@ I/O Expanders/Multiplexers
WeiKai SPI/I²C UART/IO Expander, components/weikai, wk2168.jpg
XL9535, components/xl9535, xl9535.svg
CAN Bus
-------
.. imgtable::
CAN Bus, components/canbus/index, canbus.svg
ESP32 CAN, components/canbus/esp32_can, esp32.svg
MCP2515, components/canbus/mcp2515, mcp2515.svg
Sensor Components
-----------------