@homebridge-plugins/homebridge-meross 10.19.2-beta.0 → 10.19.3-beta.0

package/CHANGELOG.md

@@ -2,7 +2,15 @@
 
 All notable changes to `@homebridge-plugins/homebridge-meross` will be documented in this file.
 
-## v10.19.2 (Pending Release)
+## v10.19.3 (Pending Release)
+
+### Changed
+
+- feat: recognise the MA151 smoke alarm that pairs with the MSH450 hub (#803)
+- fix: give the MS130 and MS130H a handler, so they stop appearing as an empty accessory (#803)
+- fix: read a hub sensor's temperature and humidity whatever the model names them (#803)
+
+## v10.19.2 (2026-08-11)
 
 ### Changed
 

package/lib/device/hub-main.js

@@ -6,6 +6,25 @@ import platformConsts from '../utils/constants.js'
 import { hasProperty, parseError } from '../utils/functions.js'
 import platformLang from '../utils/lang-en.js'
 
+/**
+ * Find the nested object in a hub sub-device entry that carries its sensor
+ * readings.
+ *
+ * Meross names that object after the model — `ms100` on an MS100, `ms130` on an
+ * MS130 — so keying on one name means every new sensor silently reports
+ * nothing. Match on the fields instead, which covers the models that exist and
+ * the ones that do not yet.
+ *
+ * @param {object} subdevice a `digest.hub.subdevice` entry
+ * @returns {object|undefined} the readings object, if there is one
+ */
+export function readingsFrom(subdevice) {
+  return Object.values(subdevice || {}).find(value => value
+    && typeof value === 'object'
+    && !Array.isArray(value)
+    && (hasProperty(value, 'latestTemperature') || hasProperty(value, 'latestHumidity')))
+}
+
 export default class {
   constructor(platform, accessory) {
     // Set up variables from the platform
@@ -139,6 +158,23 @@ export default class {
               } else if (subdevice.waterLeak) {
                 // Apply the update to the accessory
                 subAcc.control.applyUpdate(subdevice)
+              } else if (readingsFrom(subdevice)) {
+                // Newer sensors wrap their readings in an object named after the
+                // model (an MS130 reports under `ms130`, not `ms100`), so match
+                // on the fields rather than adding a branch per model — that is
+                // what left the MS130 with an accessory but no data.
+                const readings = readingsFrom(subdevice)
+                const update = {}
+                if (hasProperty(readings, 'latestTemperature')) {
+                  update.temperature = readings.latestTemperature
+                }
+                if (hasProperty(readings, 'latestHumidity')) {
+                  update.humidity = readings.latestHumidity
+                }
+                if (hasProperty(readings, 'voltage')) {
+                  update.voltage = readings.voltage
+                }
+                subAcc.control.applyUpdate(update)
               } else if (subdevice.status === 2) {
                 // If the status is 2 then has been reported offline - report a battery of 0
                 subAcc.control.applyUpdate({ voltage: 0 })

package/lib/platform.js

@@ -964,11 +964,25 @@ export default class {
 
             // Create the device type instance for this accessory
             switch (subdeviceObj.model) {
+              // MA151 pairs with the MSH450 hub. It is grouped with the GS559A
+              // because both are smoke alarms, but note what that currently
+              // buys: this handler exposes a battery only. Which field an MA151
+              // uses to report an alarm is not known yet (#803), so it appears
+              // in HomeKit and reports battery, and the smoke state still has
+              // to be mapped once a real payload has been seen.
               case 'GS559A':
+              case 'MA151':
                 subAcc.control = new deviceTypes.deviceHubSmoke(this, subAcc)
                 break
+              // MS130/MS130H are temperature + humidity sensors like the MS100,
+              // so they share its handler. They were already declared supported
+              // but had no case here, which meant the accessory was added and
+              // then silently dropped by `default` below - leaving an empty
+              // accessory and no explanation.
               case 'MS100':
               case 'MS100F':
+              case 'MS130':
+              case 'MS130H':
                 subAcc.control = new deviceTypes.deviceHubSensor(this, subAcc)
                 break
               case 'MS200':
@@ -988,6 +1002,16 @@ export default class {
                 subAcc.control = new deviceTypes.deviceHubValve(this, subAcc, accessory)
                 break
               default:
+                // Reached when a model is listed as supported but has no case
+                // above. The accessory has already been added at this point, so
+                // returning quietly leaves an empty one behind with nothing to
+                // explain it — which is exactly how the MS130 gap went unnoticed.
+                this.log.warn(
+                  '[%s] %s:\n%s',
+                  subdeviceObj.devName,
+                  platformLang.notSupp,
+                  JSON.stringify(subdeviceObj),
+                )
                 return
             }
 

package/lib/utils/constants.js

@@ -321,7 +321,7 @@ export default {
     thermostatMts215: ['MTS215', 'MTS215B'],
     sensorPresence: ['MS600'],
     hubMain: ['MSH300', 'MSH300HK', 'MSH400', 'MSH450'],
-    hubSub: ['GS559A', 'MS100', 'MS100F', 'MS130', 'MS130H', 'MS200', 'MS400', 'MST100', 'MST200', 'MTS100', 'MTS100V3', 'MTS150', 'MTS150P'],
+    hubSub: ['GS559A', 'MA151', 'MS100', 'MS100F', 'MS130', 'MS130H', 'MS200', 'MS400', 'MST100', 'MST200', 'MTS100', 'MTS100V3', 'MTS150', 'MTS150P'],
     template: [],
   },
 

package/package.json

@@ -2,7 +2,7 @@
   "name": "@homebridge-plugins/homebridge-meross",
   "alias": "Meross",
   "type": "module",
-  "version": "10.19.2-beta.0",
+  "version": "10.19.3-beta.0",
   "description": "Homebridge plugin to integrate Meross devices into HomeKit.",
   "author": {
     "name": "bwp91",