All in one Firmware for sensors

[Gifford47]

To reduce the different binarys and compilation options, we could integrate all external sensors (bme, sr501 ...) into one firmware without the need of the different pio build envs. The needed memory size fits into the esp. The user could choose the connected sensor in the ui. a simple check in the loop could enable or disable the sensor data.

What do you think about it @14yannick @Tysonpower @kfroeschl ?

[Tysonpower]

Was already thinking about that as well :) Just adding toggles to the webui to enable them.

[kfroeschl]

Depends on the target audience and how most are using the Project

The once with technical affinity won't see the compile options as a problem.

The Noob once may have but for them you properly won't have too many variations

Though the single compilation could be generated with github-actions and enable people to use the firmware without having to setup platform-io

Also restructuring the code so each sensor/feature gets it's own source file(s) and using interfaces/inheritance would increase the maintenance regardless of compilation

[Gifford47]

we only have to replace the compiler defines (f.e. use_bme) with simple if conditions. in the ui we only have to add toggles. and the maintenance is the same, because now you have to check each build if it passes. and now we dont have every combination of sensor/boards :)

[14yannick]

Do you already work on it. If not I will put all sensor related tasks in to a separate file.

[Gifford47]

I've only migrated the bme and PIR sensor yet. You can work on it, I will integrate my changes after that.

[Tysonpower]

@14yannick did you work on this already? Otherwise i would start with it.

[Gifford47]

14yannick and i already talked about it and we want to create a new branch with this mqtt lib. the sensor part should also moved to a new file. in case of this rewrite we should write the firmware as the suggested all-in-one fw.

[14yannick]

I will push a new branch to work on it. My idea is to put the mqtt and sensor related staff outside the main. Then based on the preference this elements get initialized or not.

[14yannick]

Push done yesterday there is more code for the mqtt stuff that for the whole rest of the app.

[Tysonpower]

Push done yesterday there is more code for the mqtt stuff that for the whole rest of the app.

is this the mqtt_rewrite branch? Want to test the new stuff :)

[Gifford47]

Push done yesterday there is more code for the mqtt stuff that for the whole rest of the app.

is this the mqtt_rewrite branch? Want to test the new stuff :)

Yes, it's the right branch :)

[14yannick]

See also my last commit with an URL to flash the build by webserial. I'm also evaluating this esphome port. Adding a sensor there is done by adding three line in the yaml file. Without the hasl of creating variable, setup the sensor, read, expose in mqtt, update, add config settings in the web ui,... But first need to check how reliable it's in esphome.

[kfroeschl]

I've also flashed my garage door with the espHome version. So far it's working well without issues.

At some point i should analyze it though.

Upside of espHome is definitely the ability for low-code adaption/extension and easy updates.

[Tysonpower]

We should add a config for setting the I2S address for the sensor, my BME sensor i just tested used 0x77 instead of the 0x76 that are currently hardcoded

[14yannick]

It would help but it'a never ending story for example I use the env iv who use two addresses. But it's not where I see the main issue. The mqtt part take more then the half of the code. The library is not actively maintained,... Adding a new feature is complicated if you don't now all places to need to adjust. The esphome port is missing some features (door status, vent switch instead of button) but works quite well and run on a framework who is under active maintenance even with some paid devs

[jkaberg]

See also my last commit with an URL to flash the build by webserial. I'm also evaluating this esphome port. Adding a sensor there is done by adding three line in the yaml file. Without the hasl of creating variable, setup the sensor, read, expose in mqtt, update, add config settings in the web ui,... But first need to check how reliable it's in esphome.

I can confirm that the Esphome port is working as intended, I actually have an board from @Tysonpower (with an added DHT22 sensor) running with this Esphome config:

esphome:
  name: garageport
  friendly_name: Garage port
  libraries:
    - emelianov/modbus-esp8266
  platformio_options:
    board_build.f_cpu: 240000000L
    board_build.flash_mode: qio
    monitor_speed: 9600
    monitor_filters: esp32_exception_decoder
    lib_ldf_mode: deep+

external_components:
    source: github://mapero/esphome-hcpbridge
    refresh: 0s

esp32:
  board: adafruit_feather_esp32s3
  framework:
    type: arduino

hcpbridge:
  is_connected:
    name: "HCPBridge Connected"
  rx_pin: 18
  tx_pin: 17

cover:
  - platform: hcpbridge
    name: "Cover"
    id: garageport_cover

switch:
  - platform: hcpbridge
    name: "Light"

button:
  platform: template
  name: "Ventilation"
  on_press:
    - lambda: |-
        id(garageport_cover).on_go_to_vent();

sensor:
  - platform: wifi_signal
    name: "Wifi Signal Strength"
  - platform: uptime
    name: "Uptime"
  - platform: dht
    pin: 4
    temperature:
      name: "Temperature"
      accuracy_decimals: 1
    humidity:
      name: "Humidity"
      accuracy_decimals: 1

esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true

bluetooth_proxy:
  active: true

api:
  encryption:
    key: !secret encryption_key

ota:
  password: !secret ota_password

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  ap:
    ssid: "Garage Port Fallback Hotspot"
    password: !secret ap_fallback_password

Works great!