Bring the Elecrow's GT911 out of reset through the V3.0's PCA9557 (0.2.95, firmware 0.2.81)

A unit's touch never answered: "touchscreen is marked FAILED: Calibration error" at setup, the GT911 still in reset
behind the PCA9557 (I2C 0x18) of the V3.0 board. The board file declares the expander as ESPHome's pca9554 (the same
register map) and hands the GT911 driver its reset (IO0) and interrupt (IO1) pins on it, so the driver runs Elecrow's
own sequence: reset low with the interrupt line low, reset high, 56 ms, address 0x5D. A V2.0 without the expander boots
its GT911 by the pull-up as before. The bus is scanned at boot for the log.

packages/boards/elecrow-crowpanel7.yaml

@@ -488,16 +488,27 @@ text_sensor:
     lambda: 'return {"elecrow"};'
 
 # Pinout of the CrowPanel 7.0" (DIS08070H, V2.0 and V3.0): Elecrow's wiki and the ESPHome devices page. The V3.0 has a
-# PCA9557 I/O expander at I2C 0x18 on the GT911's reset and interrupt lines; it is left alone on purpose: it powers up
-# with every pin as an input, a pull-up brings the GT911 out of reset before the firmware starts, and writing it during
-# boot is what breaks the touch. No interrupt pin either: the GT911 is polled.
+# PCA9557 I/O expander at I2C 0x18 on the GT911's reset (IO0) and interrupt (IO1) lines, and the GT911 stays in reset
+# until something drives them (firmware 0.2.81: a unit whose touch never answered, "Calibration error" at setup). The
+# expander gets the same register map as the PCA9554 ESPHome knows, and the GT911 driver does Elecrow's own reset
+# through it: reset low with the interrupt line low (that picks address 0x5D), reset high, 56 ms. On a V2.0 without
+# the expander its setup fails, the GT911 boots by its pull-up as before, and the driver still finds it (it tries 0x14
+# by itself when 0x5D does not answer).
 i2c:
   id: touch_bus
   sda: GPIO19
   scl: GPIO20
   frequency: 400kHz
-  # A bus scan at boot upsets the GT911; the touchscreen names its address instead.
-  scan: false
+  # The scan logs what answers on the bus (0x18 the expander, 0x5D or 0x14 the GT911), with `logger: level: DEBUG` in
+  # a screen's Override YAML: which revision a screen is, and whether the bus is alive at all. It runs before the
+  # GT911's reset, so it upsets nothing.
+  scan: true
+
+pca9554:
+  - id: touch_expander
+    i2c_id: touch_bus
+    address: 0x18
+    pin_count: 8
 
 output:
   - platform: ledc
@@ -520,9 +531,14 @@ touchscreen:
   platform: gt911
   id: ts_touch
   i2c_id: touch_bus
-  # The GT911 takes 0x5D when GPIO38 reads low at power-on, 0x14 when high; on this board it is 0x5D on most units.
-  # A unit that never reports a touch may be a 0x14: the Override YAML of that screen changes it (docs/ELECROW.md).
+  # The reset through the expander picks 0x5D; the driver tries 0x14 by itself when that does not answer.
   address: 0x5D
+  reset_pin:
+    pca9554: touch_expander
+    number: 0
+  interrupt_pin:
+    pca9554: touch_expander
+    number: 1
   display: my_display
   update_interval: 20ms
   transform:

packages/core.yaml

@@ -14,7 +14,7 @@
 # fonts/materialdesignicons-webfont.ttf (Apache 2.0, github.com/Templarian/MaterialDesign-Webfont).
 ############################################################
 substitutions:
-  SCREEN_FIRMWARE_VERSION: "0.2.80"
+  SCREEN_FIRMWARE_VERSION: "0.2.81"
   DASHBOARD_INBOX_INTERNAL: "false"
   CALIBRATION_ON_BOOT: "false"                     # a bench build: start on the touch test page
   ROOM_NAME: ""                                    # top left until ESP Screens sends the screen name