As it stands in master, i2cscanrequest handles both i2c port initialization and scanning. This approach requires re-initialization and/or transmitting additional information about the bus. We should only be setting up I2C once (per port), not every scan.
This pull request breaks out i2c initialization parameters from an I2CScanRequest into an I2CInitRequest.
In the new, modified, workflow:
If the i2c port has been initialized (@lorennorman the contents of I2CInitRequest should be stored in the DB), we skip this step and go directly to performing an I2CScanRequest
If device's i2c port(s) have not been configured, we show a new "Initialize I2C Port" screen which allows the user to select the SCL/SDA lines from the hardware definition.
An I2CInitRequest msg is sent to the device over the I2C MQTT topic. Broker waits for an I2CInitResponse message to be sent from the device, indicating the bus is configured properly.
Notes: Marked OK if this PR is failing, there are breaking API changes (not integrated yet into application-level code)
As it stands in
master, i2cscanrequest handles both i2c port initialization and scanning. This approach requires re-initialization and/or transmitting additional information about the bus. We should only be setting up I2C once (per port), not every scan.This pull request breaks out i2c initialization parameters from an
I2CScanRequestinto anI2CInitRequest.In the new, modified, workflow:
I2CInitRequestshould be stored in the DB), we skip this step and go directly to performing anI2CScanRequestI2CInitRequestmsg is sent to the device over the I2C MQTT topic. Broker waits for anI2CInitResponsemessage to be sent from the device, indicating the bus is configured properly.Notes: Marked OK if this PR is failing, there are breaking API changes (not integrated yet into application-level code)