Version regression resolved nearly all problems - 2.14.0 #763
Comments
|
Update to this comment: after removing features not available in 2.14 in the config files, and reversing changes in the .service file, room-assistant seems to be working again. Old version of .services file for reference: original content: My service file looks like this: |
|
Thanks for this issue - I've been getting lots of Unavailables and flaky behaviour and was trying to troubleshoot but not getting anywhere. I also have quit a large collection of RA instances, (not quite as a many, only 10 :D ) so I wonder if that comes into play. Downgrading to 2.14 and I'm stable again now. Cheers! |
|
2.15.0 introduced the instance beacons for the iOS app auto-toggle feature. It's possible that the library used for this has some faults (or the Raspberry chips just can't deal with it anymore). It'd be awesome if someone of you could test if you see the same instability issues on newer versions of room-assistant when you add the following to your config: bluetoothLowEnergy:
instanceBeaconEnabled: falseIf you observe that this makes it better I'll think about where to go from here - maybe I'll remove that functionality then (or at least disable it by default), but I'll have to figure out how to change the app functionality in that case. @Scott8586 The watchdog functionality for the systemd service was only added quite recently, for the older versions you should remove the |
|
Thanks for the clues @mKeRix. Yes, I figured out the watchdog stuff along the way yesterday, trying the configuration change on a pi 3B+ and a pi zero at 2.18.4 now. |
|
I had seen the instanceBeaconEnabled: option in another message and disabled it. (I was seeing pairing requests as well) Unfortunately, it did not make a difference for me. If I recall, it did not solve that user's issue either. I have spent countless hours trying different config options without success. It feels like the largest recurring issue was getting all 12 instances to form a single cluster and play nice for any length of time. Within 24 hrs it would fragment into two or three clusters with a least one instance failing. 2.14.0 has been stable for over a week now. Also, I currently have the HA add-on disabled as I don't know how to roll the version back. Some guidance on how to do that would be great. Of course, I'm willing to spin everything back up to 2.18.4. If there is some specific troubleshooting or log information I can offer. It's important to say how much all of the development time put into this is appreciated. I loved the new features, especially the instance browser. Let me know how I can assist. |
|
Reloaded 2.18.4 using the config from my original post. I deleted all the MQTT devices in HA to make sure they populated with the correct topic details for the current version. The only config change is instanceBeaconEnabled: false. The Foyer instance ran a couple of minutes before problems started at 22/06/2021, 01:34:11 in the attached. It does appear that using the instance browser aggravates things. As soon as the errors began, instances and devices went unavailable, and all devices reestablished the leader with all the associated odd behavior. Foyer instance didn't report any BLE distance updates after. Initially, I started with HA add-on enabled but it could not establish a leader among the 12 instances, even after multiple restarts of the add-on. There were always a couple of instances that would not join. As soon as I stopped the add-on all instances clustered up. There might be a separate issue here but let's tackle one variable at a time. |
|
Part 1: |
|
Part 2: If I go back to isolating the BLE instance. It works again immediately, I will watch it for 24hrs and update if there is a change. The other members of the cluster are a group of three running bluetoothClassic, and a mixture of the gpio, and Xiaomi integrations, all instances run the homeAssistant integration. two are pi zeros, one is a pi 3B, Im using the integrated bluetooth on all machines. The cluster of three seems to continue to operate correctly on 2.18.4. The BLE instance is a pi zero running 2.18.4. Log file for non-working, clustered version of BLE instance: |
|
Part 3: |
|
@Scott8586 Your help is super appreciated, but I'm just not sure where to go from here. I'm hoping @mKeRix can weigh in with some things we might have overlooked. I keep coming back to clusters. If they can't form reliably, nothing good will follow. For me, cluster problems appear immediately on the newer versions, yet clusters lock in solidly on 2.14.0. It seems like a logical point to start hunting. |
|
@CobraDunn - yes clustering is clearly part of the problem. I was hoping to get this down to a small test case. It seems that ClassicBluetooth only based clusters are/can be stable (I'm back to 24hrs of stability), but even joining a single BLE based node to the cluster causes failures of both the BLE node and the Classic nodes. The process seems stochastic - the failures are not always immediate - this might suggest a race condition, or deadlock, or some other kind of timing issue. I get your point about going back to 2.14.0, this is an extremely important clue - we have to know when to look, but also what to look for. |
|
Hey all, sorry for the sparse responses from my side, my last weeks have all been very busy and I haven't found much time for this project unfortunately.
Only way to rollback atm is to restore the add-on from an old snapshot, see home-assistant/supervisor#1843 for more info. Alternatively, you could try pulling the add-on config from that version off the git repository and set that up as a local repository.
Hm, there is nothing specific that jumps out at me from a first review of the logs, but something is definitely off. :/ If you'd be down I'd try to provide you a custom room-assistant package here in the coming days, with some stuff that was added between 2.14.0 and the current version taken out. Hopefully that could bring us closer to the problem. I'll also take another look at your log file (thanks for providing it!) with a fresh set of eyes then.
Am I understanding it correctly that you have 3 instances running BT Classic alongside some other stuff and then only that one Pi Zero with BLE? room-assistant actually has a limitation currently, where distributed integrations that need a leader (both the Bluetooth ones) need to all be enabled on the leader instance so that things can work. This would essentially mean that you'd have to turn BLE on in at least one of the BT Classic instances, which should then be configured to be a preferred leader. Alternatively you can do what you already tried and just run the BLE only instance outside your main cluster.
Did this instance report any errors for Bluetooth Classic at that time or was it just a case of the Bluetooth adapter not connecting (as if the device was simply not nearby)? |
Thanks for your response. Understood. The HA instance is the least important... although it is at the bar :)... plus, there's one less variable to deal with. Hopefully I end up running the latest version across all devices :)
Absolutely! Just let me know when you have something. Thanks again. |
|
@CobraDunn I've compiled a package that contains room-assistant 2.18.4, but without any of the instance beacon code. Could you give this a shot on your setup and observe the behavior? See the iCloud link below to download the package. https://www.icloud.com/iclouddrive/0jEylhPkpGvGAZ_RB5tQgKN4w#room-assistant-2.18 You can install it by uploading it to your Pis and running |
|
@mKeRix - Awesome! I'm on it. |
|
@mKeRix - This looks really promising. Hopefully, it helps isolate the issue. All (11) instances clustered up immediately and all logs look clean. Let me know if there are any debug details you want to see. I'll monitor over the next 24 hours and keep you posted. What features are impacted by the removed code? Thanks for the responsiveness! |
|
Only the auto-toggling feature in the iOS companion app, if you don't have that turned on it shouldn't make a difference. That's something that could be replaced by some other mechanic as well, I'd just have to think about the best way to do it. I'm not really looking for any specific details atm, just general feedback - so I appreciate you keeping me posted! :) |
|
@mKeRix - 24 Hour Update - All instances were completely stable and the cluster leader remained solid the entire period. I think you've nailed it. I'll keep monitoring and advise of any changes. |
|
@mKeRix I tested out as well, with the custom 2.18.4 performs with no errors for the last 2 day. |
|
@mKeRix - Update - It's been rock solid since initial install. Tracking is working well, as is the Instance Browser. I was hoping a couple more people would jump in to comment on the behavior of the test version. Being curious as I am, I have to ask the question. While the instanceBeaconEnabled: switch did take care of the BT pairing concern, it didn't seem to do anything for the overall instabilities. Did you find any clues to this behavior in the removed code? |
@nagydavid - I appreciate you validating the test version. I've been struggling with this for months! Thank you! |
|
i'm having the same issues -- looking forward to getting the fix! |
@tuday2 - If you have the time to try it, I'm sure your feedback on the on test version above would be appreciated by all |
|
please also create a docker version of this test version so I can roll it out too and report back. edit: wow reverted back to 1.14 with docker and damn no more errors or warnings! this is great! instant improvement. |
|
As an outlook: I will publish the changes from above as an official version this weekend. Since it's a breaking change it will trigger the 3.0.0 release - I want to throw a few more breaking changes in this version bump, which is why I'll make this a beta release. The other changes will follow in future beta releases, but this way the Docker images and Home Assistant add-on can also be used again already. |
|
Update : that package fixed 2 out of 3 of my Pi's ... I am going to try a reinstall on the one that isn't working |
The instance beacons broadcasted via bleno seem to cause trouble for many users, so they were removed from the software again. BREAKING CHANGE: instance beacons along with their configuration options and the companion app auto toggling feature are not available anymore Closes #763
|
There is now a beta release with this fix available on npm (Docker image and Home Assistant add-on are building atm, will be available in ~30min). The version is 3.0.0-beta.2, since something mysteriously went wrong during the upload of 3.0.0-beta.1. As noted above, I'll leave this beta track open for a while as I plan to fit some more breaking changes into that release. |
|
@mKeRix - All Pi Zeros are running well, like the test version. However, this is something up with HA add-on version. It will not register a Cluster Leader or take the Leader role as specified in the config below. The Elected Leader messages normally seen in other logs also do not appear. It appears it's not realizing a quorum exits. HA Entity pics and log are below. [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
Config: global: |
|
@mKeRix - Update: HA add-on eventually picked up the active Cluster Leader although it still would not assume the Leader role. Something doesn't seem quite right with the cluster negotiation in the add-on. One item of note if it helps. This is a Pi4B and the only instance connected via ethernet - networkInterface: eth0 is in the cofig. More critically, after a short period (<24hrs) the log begins repeating with the below, and no allowlist: BLE devices are reported. This is one of the failure modes I was encountering in V2.18.4. HA add-on log: 7/5/2021, 10:27:27 AM - info - BluetoothService: Detected unusually long lock on Bluetooth adapter 0, force unlocking |
|
@mKeRix - Update #2 - Approx. 20 hours after restarting the add-on, it appeared to have taken the Leader role. Unfortunately, when BLE devices began returning home, (3) of the Pi Zero instances immediately stopped responding and went "unavailable". The add-on instance also didn't report any devices. I have disabled the add-on until we can identify the issue. |
|
I seem to have run into an stability issue with mosquitto mqtt on. Every night at 4 am my server makes a backup of all my dockers and auto updates the applications that have newer versions ready. This turns out to be bad because once mqtt server is rebooted the devices dont reconnect to mqtt again and I have to restart room assistant on the rpi running as a docker and then it works again. (now I will set a auto reboot every day at 5 am to resolve this. why typ this well I also have exactly the issue as described above with no cluster leader being chosen. when I add a docker room assistant instance that is running on my server with an asus bt5 dongle. it fails to assign clusterleader at times. other then that it seems to be working ok. |
|
@mKeRix - Can you provide an update on the path of the Beta. It has been some time since its release. Separate from the ad-on concerns, there are still random stability issues that I've found difficult to pin down. Let me know how I can help. |
|
To add another Beta test voice to this discussion, I've been using the Beta since release in the hope it would address some stability issues with my simple config;
On 2.18.4 I also have experienced all of the issues as CobraDunn has - nodes going unavailable after reintroducing BLE mobile app, Nodes randomly stop responding, HA add-on won't stay up for more than 24 hours without some type of failure, constant BLE service restarting, clusters won't maintain a leader, and random entities unavailable. All devices are fully up-to-date and with the latest firmware. I've set the cluster leader as the RPi 2 with LAN connection and that has resulted in a much more stable cluster configuration with no cluster leader switching. However, I still could not get a stable set of RPi Zero devices where they would drop from the cluster or temporarily disappear from the instance browser. I did suspect WiFi connectivity but have ensured their WiFi connections are stable through my Ubiquiti Unifi WiFi configuration. The single biggest successful change so far for the RPi Zeros (apart from increasing the update frequency to 2) has been to disable on-board bluetooth and use a TP-Link bluetooth dongle with USB extension. This has eliminated node dropouts and general Instance browser weirdness. However, I am still plagued by the problem of a node ignoring a BLE iOS device a random time after successfully tracking it before going out of range. Restarting the RA service will always resolve the issue and the node then starts to track again. I'd love to help if additional testing is required. local.yml global: - bluetoothClassiccluster: |
|
Hey all - I haven't forgotten about this issue, I just haven't had the time/energy to continue the work on this. Some unsorted quick thoughts on your last few messages:
Overall, this stuff touches on some topics that I meant to improve for a long time: clustering and inter-instance communication was supposed to be re-done and for the Bluetooth stuff I wanted to try going through BlueZ APIs and dropping the current library due to quite a few issues we've been facing. Unfortunately, all of that touches pretty fundamental things in RA that have impact on the many moving parts, so switching isn't super easy. |
|
Many thanks for the reply @mKeRix - I fully understand time and energy constraints and thank you for your efforts thus far; RA really is awesome! This time, the RA instance that ignored my iOS devices was the RPi 2 with Bluetooth dongle and LAN connection in the lounge. This is also the cluster leader, although other RA instances on the RPi Zero W are still tracking the two iOS devices successfully. Just to note, it is random which device will start ignoring iOS devices but this time it happened to be the one in the lounge. It started ignoring my iOS device first based on the last timestamp: And the RA log: This was yesterday morning. The lounge is directly below the bedroom and both iOS devices are usually seen during the night by the lounge and the RPi Zero W in the bedroom. We also spent several hours last night watching TV in the lounge so the lounge RA instance should have tracked the iOS devices during the evening. This is my wife's iOS device: And the log: Finally, the :6415/status as of now:
I had thought that RA would start to ignore all iOS devices at the same time. However, the time stamps above suggest that this is not the case. Hope this helps with the diagnosis. |
|
I have made what appears to be a significant change to Home Assistant over the last day or so in terms of my issues discussed in this thread. This has sort of coincided with what I've observed when attempting to troubleshoot the issues with RA nodes ignoring my iOS devices after a while. Specifically, when restarting Zigbee2MQTT, the troublesome nodes start to work again without restarting RA. The change has been to upgrade Zigbee2MQTT from 1.18.1-1 to 1.21.0-1. On my system, this wasn't an automatic upgrade as the repository changed. So I had to add the new repository, backup the configuration, install the new Zigbee2MQTT version, stop the old one and copy the configuration, then start the new version. I followed this post. I didn't set out to try upgrading Zigbee2MQTT as a fix - this was to solve another issue with RGBW bulbs - but initial results are looking promising; I have not had any node stop tracking my iOS devices for over 48 hours now. I wonder what versions of Zigbee2MQTT others are using? |
|
@mKeRix - The cluster election behaving weirdly on your add-on instance is strange, since it has no special code tied to the add-on. Does it change anything if you let room-assistant auto-detect the network interface by dropping that configuration line? Thanks for follow-up. I commented out the "networkInterface: eth0", deleted the device in MQTT, rebooted the HA server, and started the add-on instance. After 1 Hr of the uptime, the add-on reports a leader of "none". All instances, including the add-on, correctly report the Cluster Size of 12. Room-Assistant App: FYI, I have been able to keep things working for weeks now by using crontab to auto-reboot all devices at 2:00 am. I delay the reboot of the leader by 5 min to make sure all other instances have completed the restart. Without the delay, the leader will not be stable and consistent. Update... |
|
I spoke too soon it seems. Back to nodes randomly ignoring iOS devices after successfully tracking them for while. I am going to schedule a reboot every evening as a workaround. |
@RutgerDiehard - I still have a few instance crashes, but they are significantly reduced by nightly reboots. Typically the instance goes dark and stops providing distance updates after the reintroduction of an iPhone. Sometimes the instance shows "unavailable", but typically the clustering routine continues running while offering no clue to the BLE failure. This often takes down (2) to (3) of my (11) instances simultaneously. It's commonly accompanied by the impacted instance(s) responding slowly, or not at all, to SSH logins. Even when the instance is partially crashed as described, it does auto-reboot via crontab schedule. Hope this helps until we get things sorted. I'm not aware of any alternatives products that provide the functionality of room-assistant. |
|
So I'm confused. Did beta2 remove the ability for iPhone to automatically be tracked via companion app (not having to be open in foreground)? My only use case for RA is to track position of 2 iPhones between 2 nodes I got in a cluster. Trying to figure out the (new?) trajectory of this project. Or do I just not need the app whatsoever for this specific task? |
|
@Hukuma1 - The Home tracking functionality of the Companion App tracking did not change. The Auto-Toggle Visibility feature, however, no longer works. |
|
@mKeRix - Looking to understand the path forward. There are many unresolved issues and I keep encountering new failure modes. I and other monetary contributors are becoming frustrated. This project has so much potential. Please provide an update. |
Thanks @CobraDunn, I scheduled nightly reboots and, while it helped improve stability slightly, I still had no confidence devices were where room-assistant thought they were. I've stumbled across another room-based presence detection solution based on ESP32 devices; website, repository and Reddit. I'm in no way associated with this but have purchased 8 ATOM Lite ESP32 Development Kit and replaced the RPi Zeros running RA. Espresense is architected differently and has less "tweakability" than RA however, they are stable and update as expected. Worth a look in my opinion. |
|
I've also been playing with ESP32 based solutions, both ESPresense and ESPHome's esp32_ble_tracker: component. |
|
If you have are interested, you could try out room-assistant PR #887 as that seeks to improve on ble stability. Happy to assist as I would be interested in any feedback. |
|
@PeteBa - I will give it a try. |
|
@Scott8586 , best to create a stand-alone version to test so you dont disturb the existing copy. If you have already installed room-assistant on the pi - and therefore have the main dependencies loaded - then you can create a version to test with the following from your home directory: stop the current room-assistant service: If you are doing this on a pi zero w then the build step may run out of memory. If that is the case then you can run an interpreted version which is a bit slow to start but should work. run in interpreter mode: |
|
Any option for those of us using the Docker container? Currently latest build seems to be Preliminary tests by the way have been good for my RPi4 running that |
|
@PeteBa - thanks for the detailed notes on testing your branch/pull. You were right the pi zero ran out of heap on the compile, but I have it running as the interpreted version, on a host which is only looking for a handful of iBeacons. I've turned off the nightly reboot, but I do have it alert me when the host goes offline. I'll keep track. |
|
I ran @PeteBa 's branch for a couple of days - it seemed to go well on an isolated machine where I was only running the LowEnergy integration, so I've moved on to room-assistant 2.19.0 (and npm 7) on my Pi Zeros. On the zeros where I need to run bluetoothClassic, I'm trying a configuration where I turn off inquiries when I know no one is around (when we are both away and/or the house in Vacation mode), to see if that keeps those machine more stable - I'm finding that the Pis struggle the most and are most likely to drop offline when none of the devices I'm pinging are in the local area. FWTW, I'm finding ESPresense just isn't going to work for me in place of bluetoothClassic because the fingerprints are not unique - the two main devices that I want to track, iPhones are showing up as the same identifier. Perhaps I can use it for additional beacon tracking at some point... |
|
@CobraDunn I understand your frustration. Unfortunately I'm still having a really hard time to find the time and energy for this spare time project, even though I still have lots of personal wishes for what to improve and add on top of the project. I appreciate the people that sponsor me/the project lots, but if you feel frustrated with the current situation I would ask you to cancel the sponsorship. Everything surrounding this project is open source and free to use either way. Apart from that, I'd be open for new maintainers to join - in case someone wants to work more actively on the project. @Scott8586 That probably has to do with the Pis using the whole interval length when the device isn't around, which blocks up the adapter for a long time. It might be cool to have a dynamic interval length per device that will leave longer gaps between queries if a device is away. That would mean a slower detection on re-entry, but hopefully much better stability of the instances. |
I hope @mKeRix doesn't mind me posting this on here but ESPresense has had considerable development over the last few weeks. The device IDs are now created based on a query to the BLE iOS device which helps increase uniqueness. It has resolved my issue with an iPhone 8 Plus and and XS Max appearing the same. ESPresense can even integrate with the Room-Assistant iOS helper application and use its UUID to define the device ID. I'm successfully using Bluetooth presence in automations to keep a light on after being triggered by a PIR. |
|
Hi All, just 2 noob questions. First of all, thank you @mKeRix for RA, I just love it :) But... :) I'm on 2.20.0 now, but I would try 3.0.0 beta on all my instances. Also how can I downgrade to eralier versions? TIA, Peter Edit, beta: |
Describe the bug
Versions later than 2.14.0 unstable in my environment - downgraded from 2.18.4 one version at a time until I found stability
I have encountered nearly every open issue on this forum. Nodes going unavailable after reintroducing BLE mobile app, Nodes randomly stop responding, HA add-on won't stay up for more than 24 hours without some type of failure, constant BLE service restarting, clusters won't maintain a leader, and random entities unavailable.
To reproduce
11 PIW0's and HA add-on on Pi4B with config shown
Relevant logs
Multiple service errors as documented in other posts. Will happily assist in troubleshooting with some direction.
Relevant configuration
*** HA add-on - local.yml
global:
instanceName: bar
integrations:
- bluetoothLowEnergy
- homeAssistant
cluster:
networkInterface: eth0
port: 6425
autoDiscovery: true
weight: 50
quorum: 7
peerAddresses:
- 192.168.7.211:6425 #Living Room
- 192.168.7.92:6425 #Cave
- 192.168.7.240:6425 #Garage
- 192.168.7.118:6425 #Bar
- 192.168.7.219:6425 #Kitchen
- 192.168.7.113:6425 #Foyer
- 192.168.7.242:6425 #Master Bedroom
- 192.168.7.247:6425 #Caden Room
- 192.168.7.213:6425 #Josh Room
- 192.168.7.212:6425 #Dining Room
- 192.168.7.218:6425 #Family Room
- 192.168.7.56:6425 #Spare Bedroom
bluetoothLowEnergy:
allowlist:
- XXXXXXXX-A8CB-4EBA-B223-2D3383395BA7 #Josh iPhone
- XXXXXXXX-D629-46F8-BE28-EAFE057ADA17 # Mindy iPhone
- XXXXXXXX-6E58-4007-A04C-74724C879BD4 # Eric iPhone
- XXXXXXXX-DC06-47EC-B351-94407CDD99A7 # Caden iPhone
- XXXXXXXX-D233-4AD9-8344-45560EBADD38 # Kena iPhone
tagOverrides:
XXXXXXXX-A8CB-4EBA-B223-2D3383395BA7:
name: Josh's BLE iPhone
XXXXXXXX-D629-46F8-BE28-EAFE057ADA17:
name: Mindy's BLE iPhone
XXXXXXXX-6E58-4007-A04C-74724C879BD4:
name: Eric's BLE iPhone
XXXXXXXX-DC06-47EC-B351-94407CDD99A7:
name: Caden's BLE iPhone
XXXXXXXX-D233-4AD9-8344-45560EBADD38:
name: Kena's BLE iPhone
timeout: 60
maxDistance: 2
updateFrequency: 1.5
instanceBeaconEnabled: true
*** Ansible hosts.yml **
all:
hosts:
#Caden's Room
'192.168.7.247':
ansible_user: blabla
ansible_password: blablapassword
room_assistant_config:
bluetoothLowEnergy:
maxDistance: 1.3
cluster:
weight: 1
#Master Bedroom
'192.168.7.242':
ansible_user: blabla
ansible_password: blablapassword
room_assistant_config:
global:
integrations:
- homeAssistant
- bluetoothLowEnergy
- gridEye
gridEye:
deltaThreshold: 2
heatmap:
enabled: false
minTemperature: 16
maxTemperature: 30
rotation: 180
bluetoothLowEnergy:
maxDistance: 2.3
cluster:
weight: 2
#Cave
'192.168.7.92':
ansible_user: blabla
ansible_password: blablapassword
room_assistant_config:
bluetoothLowEnergy:
maxDistance: 2
cluster:
weight: 3
#Dining Room
'192.168.7.212':
ansible_user: blabla
ansible_password: blablapassword
room_assistant_config:
bluetoothLowEnergy:
maxDistance: 2
cluster:
weight: 4
#Family Room
'192.168.7.218':
ansible_user: blabla
ansible_password: blablapassword
room_assistant_config:
bluetoothLowEnergy:
maxDistance: 1.2
cluster:
weight: 5
#Foyer
'192.168.7.113':
ansible_user: blabla
ansible_password: blablapassword
room_assistant_config:
bluetoothLowEnergy:
maxDistance: 1.5
cluster:
weight: 6
#Garage
'192.168.7.240':
ansible_user: blabla
ansible_password: blablapassword
room_assistant_config:
bluetoothLowEnergy:
maxDistance: 2.2
cluster:
weight: 7
#Josh's Room
'192.168.7.213':
ansible_user: blabla
ansible_password: blablapassword
room_assistant_config:
bluetoothLowEnergy:
maxDistance: 1.6
cluster:
weight: 8
#Kitchen
'192.168.7.219':
ansible_user: blabla
ansible_password: blablapassword
room_assistant_config:
bluetoothLowEnergy:
maxDistance: 1.8
cluster:
weight: 9
#Living Room
'192.168.7.211':
ansible_user: blabla
ansible_password: blablapassword
room_assistant_config:
global:
instanceName: livingroom
bluetoothLowEnergy:
maxDistance: 1.4
cluster:
weight: 10
#Spare Bedroom
'192.168.7.56':
ansible_user: blabla
ansible_password: blablapassword
room_assistant_config:
bluetoothLowEnergy:
maxDistance: 2.5
cluster:
weight: 11
vars:
room_assistant_version: latest
room_assistant_global_config:
global:
integrations:
- homeAssistant
- bluetoothLowEnergy
homeAssistant:
mqttUrl: 'mqtt://homeassistant.local:1883'
mqttOptions:
username: blabla
password: blablapassword
cluster:
networkInterface: wlan0
port: 6425
autoDiscovery: true
timeout: 60
quorum: 7
peerAddresses:
- 192.168.7.211:6425 #Living Room
- 192.168.7.118:6425 #Bar
- 192.168.7.92:6425 #Cave
- 192.168.7.240:6425 #Garage
- 192.168.7.219:6425 #Kitchen
- 192.168.7.113:6425 #Foyer
- 192.168.7.247:6425 #Caden Room
- 192.168.7.213:6425 #Josh Room
- 192.168.7.242:6425 #Master Bedroom
- 192.168.7.212:6425 #Dining Room
- 192.168.7.218:6425 #Family Room
- 192.168.7.56:6425 #Spare Bedroom
bluetoothLowEnergy:
allowlist:
- XXXXXXXX-6E58-4007-A04C-74724C879BD4 #Eric's iPhone
- XXXXXXXX-D629-46F8-BE28-EAFE057ADA17 #Mindy's iPhone
- XXXXXXXX-A8CB-4EBA-B223-2D3383395BA7 #Josh's iPhone
- XXXXXXXX-DC06-47EC-B351-94407CDD99A7 #Caden's iPhone
- XXXXXXXX-D233-4AD9-8344-45560EBADD38 #Kena iPhone
tagOverrides:
XXXXXXXX-A8CB-4EBA-B223-2D3383395BA7:
name: Josh's BLE iPhone
XXXXXXXX-D629-46F8-BE28-EAFE057ADA17:
name: Mindy's BLE iPhone
XXXXXXXX-6E58-4007-A04C-74724C879BD4:
name: Eric's BLE iPhone
XXXXXXXX-DC06-47EC-B351-94407CDD99A7:
name: Caden's BLE iPhone
XXXXXXXX-D233-4AD9-8344-45560EBADD38:
name: Kena's BLE iPhone
updateFrequency: 2
timeout: 60
instanceBeaconEnabled: true
Expected behavior
Service reliability - Need to isolate what instability was introduced.
Environment
Additional context
The text was updated successfully, but these errors were encountered: