As promised, yaml below. More sample data and observations.
Observations:
- there is no
newline
or carriage return
in the datastream. This makes the sample .h provided in the Custom UART Text Sensor not a copy/paste affair.
- the Target Data (TDAT) provided by the radar varies in length. I believe this means that the returned length response will need to be read as it comes in and then adjust the number of bytes read for the payload.
- I have been reading the Serial Input Basics - updated thread in order to learn how to leverage the cpp lambda options to extract the data but all examples provided are fixed start/end deliminators which sadly does not align with radar TX behavior.
ESPHome yaml below (have skipped all the normal api/wifi things…)
esphome:
name: tinypico-kld7
platform: ESP32
board: esp32dev
includes:
- kld7_uart_sensor.h
on_boot:
priority: -100
then:
- uart.write: [0x49,0x4E,0x49,0x54,0x04,0x00,0x00,0x00,0x00,0x00,0x00,0x00] # perform kld7 INIT
# Enable logging
logger:
uart:
id: uart_bus
tx_pin: GPIO19
rx_pin: GPIO18
baud_rate: 115200
parity: even
debug:
direction: BOTH
# direction: RX
dummy_receiver: false
after:
delimiter: "RESP\x01\x00\x00\x00\x00"
bytes: 25
timeout: 80ms
sequence:
# - lambda: UARTDebug::log_hex(direction, bytes, ':');
- lambda: UARTDebug::log_string(direction, bytes);
# - lambda: UARTDebug::log_int(direction, bytes, ',');
# - lambda: UARTDebug::log_binary(direction, bytes, ';');
binary_sensor:
- platform: gpio
name: kld7_detection
id: kld7_detection
pin:
number: GPIO23
mode: INPUT_PULLDOWN
on_state:
then:
while:
condition:
- binary_sensor.is_on: kld7_detection
then:
- uart.write: [0x47,0x4E,0x46,0x44,0x04,0x00,0x00,0x00,0x08,0x00,0x00,0x00] # Get TDAT
- delay: 100ms
text_sensor:
- platform: custom
lambda: |-
auto my_custom_sensor = new UartReadLineSensor(id(uart_bus));
App.register_component(my_custom_sensor);
return {my_custom_sensor};
text_sensors:
id: "uart_hex"
Here is sample data returned from the radar
[12:50:24][D][uart_debug:158]: >>> "GNFD\x04\x00\x00\x00\b\x00\x00\x00"
[12:50:24][D][uart_debug:158]: <<< "RESP\x01\x00\x00\x00\x00"
[12:50:24][D][uart_debug:158]: <<< "TDAT\b\x00\x00\x00u\x00\xDC\xFF\t\xFB\x16"
[12:50:24][D][uart_debug:158]: >>> "GNFD\x04\x00\x00\x00\b\x00\x00\x00"
[12:50:24][D][uart_debug:158]: <<< "RESP\x01\x00\x00\x00\x00"
[12:50:24][D][uart_debug:158]: <<< "TDAT\b\x00\x00\x00s\x00\xD1\xFF\xB1\xF9\x1F\x16"
[12:50:24][D][uart_debug:158]: >>> "GNFD\x04\x00\x00\x00\b\x00\x00\x00"
[12:50:24][D][uart_debug:158]: <<< "RESP\x01\x00\x00\x00\x00"
[12:50:24][D][uart_debug:158]: <<< "TDAT\b\x00\x00\x00q\x00\xCE\xFF\xC0\xF8\x91\x15"
[12:50:24][D][uart_debug:158]: >>> "GNFD\x04\x00\x00\x00\b\x00\x00\x00"
[12:50:24][D][uart_debug:158]: <<< "RESP\x01\x00\x00\x00\x00"
[12:50:24][D][uart_debug:158]: <<< "TDAT\b\x00\x00\x00p\x00\xEA\xFFY\xF84\x16"
[12:50:24][D][uart_debug:158]: >>> "GNFD\x04\x00\x00\x00\b\x00\x00\x00"
[12:50:24][D][uart_debug:158]: <<< "RESP\x01\x00\x00\x00\x00"
[12:50:25][D][uart_debug:158]: <<< "TDAT\b\x00\x00\x00r\x00\x12\x00\xC2\xF6%\x15"
[12:50:25][D][uart_debug:158]: >>> "GNFD\x04\x00\x00\x00\b\x00\x00\x00"
[12:50:25][D][uart_debug:158]: <<< "RESP\x01\x00\x00\x00\x00"
[12:50:25][D][uart_debug:158]: <<< "TDAT\b\x00\x00\x00q\x00\x06\x00\x1E\xF7\xC1\x13"
[12:50:25][D][uart_debug:158]: >>> "GNFD\x04\x00\x00\x00\b\x00\x00\x00"
[12:50:25][D][uart_debug:158]: <<< "RESP\x01\x00\x00\x00\x00"
[12:50:25][D][uart_debug:158]: <<< "TDAT\b\x00\x00\x00n\x00\xD5\xFF\x14\xF8\x94\x14"
What I think I have to do it is try and incorporate the following steps in cpp functions
- use the
"RESP\x01\x00\x00\x00\x00"
as a StartMarker
- read the next eight bytes and byte eight should be the length that gets read for the payload
- do payload parsing things (this scares me)
– splits every two bytes
– convert little endian to big endian (I assume)
– convert to decimal
– return an array of the three decimal values