cluster leader sensor reports none

Describe the bug One of my instance mostly reports none in its cluster leader sensor. However, it “seems” to work well and reports values. I can also see my monitored devices in the location of this instance. Not sure this instance would take over if one of the other instance fails. It is supposed the be the one with the higher weight (50 vs. 10 and 20), but is not currently the leader because it was started last.

To reproduce Not sure

Relevant logs Nothing relevant in the logs I think… This is the startup, a leader (office) is already elected and quorum is already reached (office has weight: 20, bedroom has weight: 10)

Living Room:

room-assistant_1  | 5/10/2020, 12:40:34 AM - debug - HomeAssistantService: Sending new state 1 for room-assistant-living-room-status-cluster-size
room-assistant_1  | 5/10/2020, 12:40:34 AM - debug - HomeAssistantService: Sending new state none for room-assistant-living-room-status-cluster-leader
room-assistant_1  | 5/10/2020, 12:40:34 AM - info - NestApplication: Nest application successfully started
room-assistant_1  | 5/10/2020, 12:40:34 AM - debug - HomeAssistantService: Sending new attributes {"nodes":["living-room"]} for room-assistant-living-room-status-cluster-size
room-assistant_1  | 5/10/2020, 12:40:34 AM - debug - HomeAssistantService: Sending new attributes {"quorumReached":false} for room-assistant-living-room-status-cluster-leader
room-assistant_1  | 5/10/2020, 12:40:34 AM - info - ClusterService: Added x.y.z.t:6425 to the cluster with id office
room-assistant_1  | 5/10/2020, 12:40:34 AM - debug - HomeAssistantService: Sending new state 2 for room-assistant-living-room-status-cluster-size
room-assistant_1  | 5/10/2020, 12:40:34 AM - debug - HomeAssistantService: Sending new attributes {"nodes":["office","living-room"]} for room-assistant-living-room-status-cluster-size
room-assistant_1  | 5/10/2020, 12:40:34 AM - debug - BluetoothClassicService: Received RSSI of -10.6 for XX:XX:XX:XX:XX from Bedroom
room-assistant_1  | 5/10/2020, 12:40:34 AM - debug - EntitiesService: Adding new entity bluetooth-classic-xx-xx-xx-xx-xx-xx-tracker
room-assistant_1  | 5/10/2020, 12:40:34 AM - info - HomeAssistantService: Device tracker requires manual setup in Home Assistant with topic: room-assistant/device_tracker/bluetooth-classic-xx-xx-xx-xx-xx-xx-tracker/state
room-assistant_1  | 5/10/2020, 12:40:34 AM - debug - EntitiesService: Adding new entity bluetooth-classic-xx-xx-xx-xx-xx-xx
room-assistant_1  | 5/10/2020, 12:40:34 AM - debug - HomeAssistantService: Registering entity room-assistant-bluetooth-classic-xx-xx-xx-xx-xx-xx under homeassistant/sensor/room-assistant/bluetooth-classic-xx-xx-xx-xx-xx-xx/config
room-assistant_1  | 5/10/2020, 12:40:35 AM - info - ClusterService: Added x.y.z.t:6425 to the cluster with id bedroom
room-assistant_1  | 5/10/2020, 12:40:35 AM - debug - HomeAssistantService: Sending new state 3 for room-assistant-living-room-status-cluster-size
room-assistant_1  | 5/10/2020, 12:40:35 AM - debug - HomeAssistantService: Sending new attributes {"nodes":["office","bedroom","living-room"]} for room-assistant-living-room-status-cluster-size
room-assistant_1  | 5/10/2020, 12:40:39 AM - debug - BluetoothClassicService: Querying for RSSI of XX:XX:XX:XX:XX using hcitool
room-assistant_1  | 5/10/2020, 12:40:39 AM - debug - BluetoothClassicService: Received RSSI of -21 for XX:XX:XX:XX:XX from Living Room
room-assistant_1  | 5/10/2020, 12:40:46 AM - debug - BluetoothClassicService: Received RSSI of -0.1 for XX:XX:XX:XX:XX from Office
room-assistant_1  | 5/10/2020, 12:40:52 AM - debug - BluetoothClassicService: Received RSSI of -8.2 for XX:XX:XX:XX:XX from Bedroom

Relevant configuration

cluster:
  networkInterface: '{{ room_assistant_interface }}'
  port: 6425
  peerAddresses: {{ room_assistant_cluster_members }}
  autoDiscovery: false
  weight: {{ room_assistant_weight | default(10) }}
  quorum: 2
global:
  instanceName: '{{ room_assistant_name }}'
  integrations:
    - homeAssistant
    - bluetoothClassic
homeAssistant:
  mqttUrl: '{{ mqtt_server }}'
  mqttOptions:
    username: '{{ mqtt_room_assistant_username }}'
    password: '{{ mqtt_room_assistant_password }}'
bluetoothClassic:
  hciDeviceId: 0
  minRssi: -30
  interval: 6
  addresses: {{ room_assistant_bluetooth_devices }}

Expected behavior It seems like it should report the actual cluster leader or say something in the logs if it’s not working.

Environment

• room-assistant version: 2.6.0
• installation type: Docker
• hardware: Pi 3B (+ 2 Zero W)
• OS: Linux

Additional context Add any other context about the problem here.

[RomRider]

That would make sense, also another though I had was that based on how https://github.com/goldfire/democracy.js/blob/master/lib/democracy.js#L432 works:

• it could have not received all the hello from the other members of the cluster
• thus the _nodes property would be empty or partially complete straight after init (because the _nodes property of the class is not based on the peer list as far as I understand how the code is built. The _nodes contains nodes from which we received a hello, and the peer list is statically defined / or discovered through MDNS in the case of room-assistant)
• This would lead the node to elect itself (or the one with the highest weight from the partial list it knows about) as the leader because https://github.com/goldfire/democracy.js/blob/master/lib/democracy.js#L439 only contains itself (or a partial list)

Maybe increasing the timeout here https://github.com/goldfire/democracy.js/blob/master/lib/democracy.js#L81-L93 might help.

[mKeRix]

@danpowell88 What you’re seeing is a mixture of “some nodes not appearing” from the cluster troubleshooting section and #196. If you configure the peer addresses (at least the address from the leader, as the others seem to successfully find each other through MDNS) and then restart all instances at the same time you should see the wanted outcome.