First accessory recognized as a bridge and doesn't show up.

[delingren]

I am working on a project that has 11 contact sensors for doors or windows. So, I wrote a class for these contact sensors, and in setup(), I added them one by one. But when I add it from Home app, it only appears as 10 sensors and the first accessory is recognized as a bridge and it doesn't show up in the room view.

I have read from the docs that if the first accessory doesn't have any service, it'll be shown as a bridge. However, that's not the case here. Here's my setup().

void setup() {
  Serial.begin(115200);

  homeSpan.begin(Category::Doors, "Door");

  new SpanAccessory();
    new Service::AccessoryInformation(); 
      new Characteristic::Identify();
      new Characteristic::Name("Front Door");
    new DEV_DOORWINDOW(13);

  new SpanAccessory();
    new Service::AccessoryInformation(); 
      new Characteristic::Identify();
      new Characteristic::Name("Garage Door");
    new DEV_DOORWINDOW(14);

  ... Repeat 9 more times ...

The constructor of DEV_DOORWINDOW news up a Characteristic::ContactSensorState():

DEV_DOORWINDOW(uint8_t pin): Service::ContactSensor() {
  state = new Characteristic::ContactSensorState();
  this->pin = pin;
  pinMode(pin, INPUT_PULLUP);

Any idea what's going on here? Thanks.

PS here's the full code for DEV_DOORWINDOW

struct DEV_DOORWINDOW: Service::ContactSensor {
  const unsigned long millis_debounce = 50;

  static std::map<int, DEV_DOORWINDOW*> all_sensors;

  static int pin_value_to_state (int val) {
    return val == LOW ? 
      Characteristic::ContactSensorState::DETECTED : 
      Characteristic::ContactSensorState::NOT_DETECTED;
  }

  static void isr() {
    for (auto it = all_sensors.begin(); it != all_sensors.end(); it ++) {
      int new_value = digitalRead(it->first);
      if (it->second->value != new_value) {
        it->second->value = new_value;
        it->second->need_to_update = true;
        it->second->millis_last = millis();
      }
    }
  }

  uint8_t pin;
  SpanCharacteristic *state;
  volatile int value;
  volatile unsigned long millis_last;
  volatile bool need_to_update;

  DEV_DOORWINDOW(uint8_t pin): Service::ContactSensor() {
    state = new Characteristic::ContactSensorState();
    this->pin = pin;
    pinMode(pin, INPUT_PULLUP);

    // Report initial state
    value = digitalRead(pin);
    need_to_update = true;
    millis_last = millis();

    all_sensors.insert(std::pair<uint8_t, DEV_DOORWINDOW*>(pin, this));
    attachInterrupt(pin, isr, CHANGE);
  }

  void loop() {
    if (need_to_update && millis() - millis_last > millis_debounce) {
      // We only update if 
      //   * An interrupt has occured since the last update, or we have never updated since booting, reflected by need_to_update.
      //   * Enough time has passed since the last interrupt, for debouncing.
      need_to_update = false;
      Serial.printf("---- Updating pin %d's value to %d\n", pin, value);
      state->setVal(pin_value_to_state(value));
    }
  }
};

std::map<int, DEV_DOORWINDOW*> DEV_DOORWINDOW::all_sensors;

[HomeSpan]

When I run your script, the Serial Monitor reports that there is no bridge, as expected. Note that a bridge accessory never shows up in the Home App itself, so you would not see it anywhere. If you are only seeing 10 Contact Sensors instead of 11 in your Room View, this suggests that one of the Sensors may have been allocated to another room, or (more typically) to the "Default Room". Please check to see if the 11th Contact Switch is in some other room. Devices do not control the room assignments - this is done all within the Home App. And based on my experience, it is a little buggy (regardless of whether using HomeSpan or a commercial device). Sometimes I find that right after pairing a new device, it shows up in the room I assigned, but then it moves to "Default Room" for no apparent reason. This doesn't happen often, maybe 5% of the time, but it is strange when it does.

[delingren]

Thanks for your response. I looked at the log in the serial monitor too and it looked completely normal: 11 contact sensors and no bridge:

Service                             UUID         AID  IID  Update  Loop  Button  Linked Services
------------------------------  --------  ----------  ---  ------  ----  ------  ---------------
AccessoryInformation                  3E           1    1      NO    NO      NO  -
ContactSensor                         80           1    4      NO   YES      NO  -
AccessoryInformation                  3E           2    1      NO    NO      NO  -
ContactSensor                         80           2    4      NO   YES      NO  -
AccessoryInformation                  3E           3    1      NO    NO      NO  -
ContactSensor                         80           3    4      NO   YES      NO  -
AccessoryInformation                  3E           4    1      NO    NO      NO  -
ContactSensor                         80           4    4      NO   YES      NO  -
AccessoryInformation                  3E           5    1      NO    NO      NO  -
ContactSensor                         80           5    4      NO   YES      NO  -
AccessoryInformation                  3E           6    1      NO    NO      NO  -
ContactSensor                         80           6    4      NO   YES      NO  -
AccessoryInformation                  3E           7    1      NO    NO      NO  -
ContactSensor                         80           7    4      NO   YES      NO  -
AccessoryInformation                  3E           8    1      NO    NO      NO  -
ContactSensor                         80           8    4      NO   YES      NO  -
AccessoryInformation                  3E           9    1      NO    NO      NO  -
ContactSensor                         80           9    4      NO   YES      NO  -
AccessoryInformation                  3E          10    1      NO    NO      NO  -
ContactSensor                         80          10    4      NO   YES      NO  -
AccessoryInformation                  3E          11    1      NO    NO      NO  -
ContactSensor                         80          11    4      NO   YES      NO  -

Configured as Bridge: NO

No, the missing contact sensor was not assigned to another room. The Home App indeed thinks it's a bridge. After I tap on "add accessory", it asks me to choose a "Bridge Location". See the screenshot

[delingren]

And, after adding them, I went to the contact sensor's property sheet and clicked on "Bridge", this is what I saw. The first accessory "Front Door" is shown as a bridge.

[HomeSpan]

Can you unpair the device from the Home App, type 'H' into the Serial Monitor, which causes HomeSpan to generate a new Device ID, and try re-pairing? If the issue still persists, can you try running Example 1 (though also make sure to type 'H' into the Serial Monitor to refresh the Device ID before changing to Example 1).

Regarding your last screenshot, this is common even if you don't have a bridge accessory - starting around iOS 16 the HomeApp often creates an implicit bridge for a device that does not otherwise have a bridge. Also, even if you add a bridge from HomeSpan itself, there is no icon that itself identifies as a bridge. In fact, if you try to add a device that contains nothing but a bridge Accessory (no functional Services), it will fail during pairing.

Where I have seen this type of issue before is when developing a sketch and changing it from bridge to non-bridge, or vice-versa. When a device is initially paired, the device ID (which is supposed to be unique across all HomeKit devices) is saved by the Home App and information is distributed to your Home Hubs. Certain changes to device in the future, such as adding a new Accessory, do not typically cause a problem. But fundamental changes, such a bridge->non-bridge, or vice-versa, can create some havoc since the latest state of the Device conflicts with what the Home App previously knew.

Hence, the solution is to ensure the Home App thinks you are pairing a new, never-before-seen, device, by having HomeSpan generate a new device ID (using the 'H' CLI command).

[delingren]

I have always generated a new device ID using the "H" command, each time after changing the sketch. Example 1 (SimpleLightBulb) works completely fine. The light bulb is recognized as an un-bridged light bulb.

And the minimum repro I've come up with so far is 4 accessories. If I add only 3 in setup(), everything works as expected. Once it reaches 4, it goes haywire. Out of desperation, I have tried 2 iPhones and an iPad and 3 ESP32 boards, all with the same result.

[frankonski]

Interesting, I have never seen this “Choose accessory to setup” screen. I am also using HomeSpan for the same reason as you.

What I do is this:

  homeSpan.begin(Category::Bridges,"Alarm System", “alarm”); 
 
  // Accessory identification
  new SpanAccessory();  
    new homeSpanIdentify("Alarm System", "Some model", NULL, "Some name", “some version”);

Ss you can see, that first accessory has no service. Then the next accessory is my “partition” accessory which implements the SecuritySystem service where I have all the logic to look at state of sensors, etc.

And the bridge always shows up in the settings of all following accessories added.

[delingren]

In Home app, after you add the bridge, if you don't configure the accessories (name, room, icon), you'll get that popup saying "Accessories added to home". When you tap on "Set Up Accessories", you'll see that sheet.
Thanks for your sample code, yeah, I think that'll be the route I'll be taking.

[HomeSpan]

It may be that there is an undocumented HomeKit limit on the number of Accessories that can be in a single device without having a bridge. I don't think any of the HomeSpan examples have more than 3 Accessories without implementing a bridge as well, so this limit could have been present for quite some time, or it may be a recent addition by Apple. I'll do some experimenting and see why I can find.

In any case @delingren, the solution for your sketch is to implement the first Accessory as a bridge, so all 11 sensors will show up correctly. Note that even if you implement as a bridge, you don't need to use the Bridge Category - you can choose any category you'd like.

[delingren]

Thanks. Yeah, I think that's a reasonable workaround. For future reference, here's the updated code that works:

void setup() {
  Serial.begin(115200);

  homeSpan.begin(Category::Bridges, "Doors and Windows");
  new SpanAccessory();
    new Service::AccessoryInformation(); 
      new Characteristic::Identify();

  new SpanAccessory();
    new Service::AccessoryInformation(); 
      new Characteristic::Identify();
      new Characteristic::Name("Front Door");
    new DEV_DOORWINDOW(13);

  new SpanAccessory();
    new Service::AccessoryInformation(); 
      new Characteristic::Identify();
      new Characteristic::Name("Garage Door");
    new DEV_DOORWINDOW(14);

... repeat 9 more times ...

[HomeSpan]

Update: I have been able to reproduce using Lightbulb Accessories and can confirm that if you have 4 or more Accessories defined, HomeKit is going to interpret the first one as a bridge even if it has functional Services. I do not know if this is a new "feature" Apple introduced recently or if this has always been the case. I'll add a note about this in the HomeSpan documentation for reference.

[delingren]

Thanks for looking into this. This is really bizarre.