Avoid MAC Address in MQTT Topic #433
Comments
|
Fair point! Since the ID is the actual permanent part of the configuration (names can change) I'm a bit wary of changing this. Plus, changing it for everyone would also be a breaking change. As a counter suggestion: what if you could override the ID of the entity in the room-assistant config? That way you could set an alias in your room-assistant config (which always needs to contain the MAC anyway) and your shared Home Assistant or NodeRED configs only contain the alias. Would that solve your problem as well? |
|
Well I was actually doing that for 1 device: But it didn't work, so yes, if I can set a name per-MAC I'm satisfied. A |
|
Sorry to hijack this, but @SeLLeRoNe, I'm very curious, is "Andrea Flex 2" a Fitbit Flex 2 that you are successfully using as a BLE beacon? I'm very curious how you got it working if so, I've been trying without success. |
|
That was indeed a test for a Fitbit Flex 2, but it did never work :) |
# [2.14.0](v2.13.1...v2.14.0) (2021-02-28) ### Bug Fixes * **bluetooth:** respect connecting state during retry ([8f36d87](8f36d87)) * **entities:** prevent dates from being proxied ([d861486](d861486)) ### Features * add generic MQTT integration ([848a25b](848a25b)), closes [#434](#434) * **bluetooth-classic:** allow id overrides ([f5fc88d](f5fc88d)) * **bluetooth-low-energy:** allow id overrides ([e41034e](e41034e)), closes [#433](#433) * **entities:** bunch entity updates together ([52f0197](52f0197)) * **home-assistant:** add discoveryPrefix option ([#546](#546)) ([1056bb5](1056bb5))
|
🎉 This issue has been resolved in version 2.14.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
Hi @mKeRix , I see this has been implemented only for BLE, could this be also implemented for normal BT devices? |
|
The BT Classic part for this was implemented in f5fc88d - does that not work? Note that the option name is slightly different. I’ve reopened the issue so that we can track this problem :) |
|
To be fair, I cannot test because I can't get Room Assistant to start anymore on 3 devices since the update. RPi 3: I have the feeling that this is due to the NodeJS update suggested on the release page (using the commands provided). Thanks |
|
Wrong button press sorry :) |
|
Still subscribed to this because of my earlier off-topic inquiry, but I recently had a lot of trouble upgrading after 2.12, and the solution for me was to nuke /opt/nodejs and use Heiko's Ansible playbooks to start from scratch, with the added benefit of not having to manually fiddle around with every new node I add. |
|
If you don't want to get into ansible you should also be able to just run the commands mentioned in the release notes to upgrade your NodeJS version, e.g. for Pi Zeros: wget -O - https://gist.githubusercontent.com/mKeRix/88b7b81e9bca044f74de1dc51696efb2/raw/799a20bca44cc61d8f8ae93878f2f28af8365a69/getNodeLTS.sh | bashIt's a modified version of the previous install script, which will replace old versions with the current LTS (14.x). |
|
I do have NodeJS 14 correctly installed as far as I can see. |
|
Ok, doesn't seems to help unfrotunately, same error as above on RPi Zero |
|
@SeLLeRoNe What does For the Pi 3 I think the other commands from the release notes should work, since those can use the official distributions. If you just add the repository for the 14.x versions I think it will offer the package upgrade on the next |
|
They are actually using nodejs 14 and I did reinstall room assistant after updating nodejs. I will post the exact versions tomorrow. |
|
Raspberry Pi 3:
Starting up manually, this is the log: Raspberry Pi Zero:
And if I try to start it: |
|
For the Pi 3: possibly try un- and re-installing the nodejs package. Maybe also run the usual For the Pi Zero: I just re-installed NodeJS and room-assistant using the script as I provided it in the release notes on one of my Pi Zero Ws and couldn't reproduce the issue that you are having. I'm a bit clueless as to what is the cause of your issue here, as I'm also not finding anything usable about that for NodeJS. I'd suggest to try an |
|
I did actually already tried to uninstall and reinstall. I'll try to reflash the Pi zero tomorrow and possibly also the 3 I'll update one I've done so possibly we can go back on the issue topic :) |
|
Hi there, One thing that I noticed is that it doesn't look like it is connecting to MQTT, full startup log: Hopefully I'll find the time today to re-build also the Pi 3 |
|
Hi @mKeRix do you have any idea? I am not sure why no one is having this issuenor why you can't replicate... I didn't do anything "specific" |
|
It seems like it just doesn't load any integrations at all (see the top of the logs), which means there wouldn't even be an attempt at connecting to your MQTT. Double-check that your config(s) are well formatted - I can at least see that it's picking up your local.yml. Do you have this issue on both the Zero W and the Pi 3 now, or just on one of them? I can't really speak to the x2js issue, that of course shouldn't be the case. I also didn't find any recent issues regarding that on the node-config repo. Maybe it was just a temporary failure during the room-assistant installation via npm? |
|
That's odd because the config is the same I have been using before the update.. What I can do is to share the config, maybe I missed something very obious: |
|
I think I also managed to clean nodejs on the RPi3 now.. I've made a clean installa nd I got: I've tried to install it using: But this time didn't fix... it's becoming a quest to fix this mess :D |
|
Ok.. I am an IDIOT! I was wondering why the file was an xml but the code inside did look more like YAML... That fixed all the issues........ I am so sorry for the waste of time |
|
Now the question would be.. how the hell was it working before? But I really do not care XD |
|
Side note, with latest version I got an error for invalid "cluster" config The config is the one I posted earlier today |
|
Oh wow - yeah, that makes sense. It's always the tiniest issues that cause the most trouble. 😄 Thanks for posting the solution in this thread. The cluster issue you mentioned is just a friendly warning that your config is formatted slightly wrong - room-assistant will still work like before (by ignoring the wrong options), but this lovely feature by @PeteBa makes the issues more transparent. Try to make your config look more like this (cluster & entities on top-level): global:
instanceName: "Master Bedroom"
integrations:
- bluetoothClassic
- bluetoothLowEnergy
- homeAssistant
cluster:
autoDiscovery: false
networkInterface: eth0
port: 6425
peerAddresses:
- redacted:6425 # Living Room
- redacted:6425 # Studio
- redacted:6425 # Master Bedroom
- redacted:6425 # Luca's Bedroom
entities:
behaviors:
d6t_occupancy_count:
debounce:
wait: 0.75
maxWait: 2 |
|
I see, I tought those 2 elements were part of glonal |
|
I've tried to test the BLE one but that doesn't work with my phone (not really sure it should). |
|
If I set it that way (I did actually try this yesterday but didn't work, that's why I thought it was part of global), I get: |
|
The As for the location detection, that is hard to say without more details. I'd recommend to look at the API to determine why exactly this issue appears - is it because there are no recent readings from the closer node or because the RSSI strength is just better on that one? It could also be that this is because of different antennas on your two Pis, which could make one report less signal strength even though it is closer. If that is the case I could add a scaling setting, which would let you manually adjust this. I just quickly scanned through where the |
|
Hi, The "networkInterface" was the cause of the reported error indeed, you might want to remove it from the sample in the docs maybe?: For what concern the "id", it was quite hard to find the Bluetooth Classic documentation (maybe direct link in the left-menu would be helpful for many), but once I found it I can confirm it works. I use also the "availability" to know when Room Assistant is offline (in order to exclude those sensors from the automations and/or person location), but there is a problem with that in my opinion, right now the system is creating a sensor for each "instance", but not a "general" sensor whic is false when all Room Assistant are offline rather than having only a per--room/per-instance value. For what concern the device "positioning" and specs, my current setup is: The one in my office is the Intel NUC, now even understanding your logic about antennas and such, I really find hard to believe that 10/15cm can get a worse signal than 2/3mt. I will investigate the API as suggeted to see what are reporting. Thanks |
|
For what concern the NUC, this is likely to be the cause: As menthioned, this is on the same instance of HA, I think this might be caused by HA getting MiFlora informations. I've now disabled the MiFlora sensor from HA but the problem (HA and RA restarted) seems to be the same. |
It's only meant to be an advanced option and might cause confusion, as discussed in #433.
|
Yeah, The availability thing is an issue indeed, it's a tricky one to solve as you cannot really trust that you are the last instance (there might be split cluster issues for example), which is why there is no availability on the shared sensors yet. #181 is an open request to implement this in a nice way. Until then I suppose you could workaround the issues by looking at the instance sensors (e.g. cluster size of each instance), because those will be marked as unavailable on shutdown. While multiple applications using the same Bluetooth adapter might cause weird behavior, the locking message you posted is actually a room-assistant internal tool. Essentially room-assistant marks an adapter as "locked" internally whenever it starts active requests on it (e.g. BT Classic scan, companion app discovery), which will cause BLE scanning and advertising to be stopped. This is done because most adapters cannot handle doing those both at the same time. In addition to that a locked adapter will refuse to take on another active command, so the system doesn't launch multiple requests. In your case it could be that the Bluetooth adapter is somehow stuck and doesn't provide responses anymore. Did you already try to reboot the NUC completely? Since we're now discussing tangential stuff I'll go ahead and close this issue in favor of the other one I linked above to improve the override behavior even further. |
|
Sure, thanks! |
Is your feature request related to a problem? Please describe.
I usually share my config, and I would prefer not to share my MAC Addresses
Describe the solution you'd like
Use the "name" value for MQTT Topic instead of the MAC Address
Describe alternatives you've considered
Haven't think on alternative solution TBH
Additional context
N/A
The text was updated successfully, but these errors were encountered: