shelly-script-examples icon indicating copy to clipboard operation
shelly-script-examples copied to clipboard

ble-pasv-mqtt-gw overhaul

Open michalk-k opened this issue 5 months ago • 0 comments

ble pasv mqtt gw overhaul

This PR introduces several changes, including fixes, refactors, and new features. All are focused on Discovery while BLE code remains untouched (almost... support of multi-button devices has required some touches)

Major changes:

New features

  1. Added support for Shelly Door/Window BLE, Buttons BLE (H&T, RC Button 4 etc.)
    • Buttons are reported with the use of MQTT events
  2. Added MACs filtering (incl option to use KVS)
  3. Added (optional) Manufacturer/Model,
  4. Added connections, identifiers, and via_device to the MQTT discovered device
  5. Debug to the console, helping in adding a new device (enabled by default, with an option to disable it)

Improvements

  1. Fixed Celsius units
  2. Fixed sensors possibly changing their topic (see breaking changes)
  3. Fixed window state and tilt turned unknown when restarting HA
    • It's because BLE devices don't always report these attributes, so after HA restart, they are missing from the retained message
  4. Rotation state renamed to Tilt
  5. Window state renamed to Contact, and window class renamed to Opening. Both to allow better flexibility (ie for doors)
  6. optimizations
    • The device is rendered for a processed device only once
    • More abbreviations used within MQTT discovery
  7. More detailed documentation

image

Breaking changes:

The data are no longer stored in sensor, telemetry, and status topics. The new common topic is data.

It will not impact users who rely on discovery

Click for details There are multiple reasons for that:
  1. Reported values may belong to different classes, for example, temperature -> sensor, RSSI -> telemetry.
  2. The first message determines creation of MQTT discovery objects incl. data topic. A different set of sensors in subsequent messages might cause pointing to a different topic
  3. Sensors don't guarantee that all their values are reported at once. For example, RSSI might be reported with a button, or with temperature (case of Shelly H&T BLE)

It turns out that depending on the combination of values in the event, particular values might got their topic changed as time goes by.

Changed naming schema

  • Devices will be named with the format: mac-model or mac if the model is not provided
  • Names of discovered entities will be set to device class, ie temperature. Then HA will create entity_id based on mac-model devclass , for example (sensor.xxxxxxxxx_ht_temperature)
  • unique_id of entities is set to mac-type (xxxxxxxxx-window) or mac-type-index (xxxxxxxxxxx-button-2)
Click for details Change to the naming aligns final device and entity names with Home Assistant standards.

HA will name the entity to devicename name, for example: 1a2b3c4d5e6f-H&T BLU Temperature. Then, renaming the device gives an option to automatically rename entities in order to follow the device name change. For example, changing the name of the device to PCROOM HT will (after confirmation) turn the entity name into PCROOM HT Temperature.

On top of that, some HA pages (ie, device view) can strip the device name out of the entity name, making them shorter and less cluttered.

michalk-k avatar Jun 22 '25 11:06 michalk-k