2.0.0-beta.1 - some quick feedback

So just been playing around with the beta version and looks like a major refresh. I stumbled across this as I have been looking at adding json_attribute_topic and discovery to mqtt_room but you have saved me the effort!

A few things that jumped out during initial setup - I only have iBeacons - that might be of interest:

• BLE whitelist: Suggest this defaults to off. This was fine in the previous version as you had to manually add the beacons to HA so no harm in having room-assistant publish everything to mqtt. But I ended up with a dozen new entities in HA when I first started the new version before I realised the consequence. It took manual editing of the .storage files to strip out the new additions
• UOM on Distributed State: Looks like the discovery message adds a unit_of_measure to the distributed ble entity state. So you end up with “not_home m”. Looks like a small typo.
• Entity Naming: The default names that get set in HA for the sensors are quite unwieldy and I wonder if things could be streamlined. Would it be worth allowing beacons names to be configured in local.yml so that you get a better initial entity_id/name in HA
• Device Identifier: I notice that the Identifier field in the Device Info structure is empty and so cannot be used by HA to differentiate two “distance” / room-assistant servers. This resulted in two RPiZero servers being consolidated as a single device in HA
• MQTT Topic: Not sure if it is a standard or just general practice, but I have noticed most mqtt discovery only uses the “homeassistant” topic for the config messages and uses a separate topic (i.e. “room_assistant”) for the state/tele messages. I think that would make things more generic as only the config messages are specific to Home Assistant whereas the other messages could be subscribed by any number of applications
• MQTT Sub-Topic: I think the mqtt subtopic names could be simplified without losing any uniqueness. I think you could drop “sensor” from the subtopic as it is already in the topic tree. You could removing the “-” characters from within the uuid but keep them as separators for major/minor. You could also remove the “-room-presence” at the end of the distributed subtopic as that is already differentiated. This could also hold true for the default entity names as well.
• Online Status: Should this be a retained message. I had a situation where I restarted HA and the beacon entities showed as unavailable. I had to restart room-assistant to generate a new “online” message to get things going.

I’m still trying to get my head around the “distributed” model so this next point may be a bit misconceived. In essence, I had thought that each Beacon would come up as a single device in HA rather than an entity within all of the Hub and Room Servers. I am curious why this model has been adopted. I admit my use-cases are simple so it may be that I’m missing something. But it looks like the intent is to have multiple entities in HA for the same beacon corresponding to all of the room-assistant server that can detect it. Given that you have the distributed capability in place, I wonder, if it would make sense to have only one device per beacon in HA regardless of where the beacon is being detected. You could move the room name to the state and have, perhaps, an array of distances from each room-assistant server in the attributes. I think that would be more intuitive for me but as I say my use-case is pretty simple.

Anyway, the above are just thoughts and can be ignored at will 8) obviously it is accompanied by a big thanks for a great HA component !

[PeteBa]

@gmalbert , I think you have already installed 2.0.0-beta-1 so the following should pull down the latest:

peter@LivingRoom:~ $ sudo systemctl stop room-assistant
peter@LivingRoom:~ $ sudo npm i --global --unsafe-perm room-assistant@2.0.0-beta.2
peter@LivingRoom:~ $ sudo systemctl start room-assistant

[mKeRix]

I’ve been wondering why Bluetooth classic solutions like this one in 2.0 and monitor.sh don’t make use of pairing? I don’t understand how but somehow the speaker in my car connects more or less instantaneously to a paired phone.

Afaik speakers/headphones/… usually just try to connect to the last device they know when you turn them on - i.e. they send out a connection request when starting (much like room-assistant does it on an interval). If my understanding is correct that would take away any advantages that pairing has over this solution and just make the setup process more annoying as you would need to pair all the Raspberries to all phones. Some smart watches may not even allow you to pair more than just your phone. And since we can’t maintain so many Bluetooth connections at once anyway we would have to re-connect each time as well.