Hass.io Add-on: room-assistant

Tags: #<Tag:0x00007f739c3cb308>

@mKeRix Hi, I’d like to get this working with thermal cameras. I’m thinking of using 2x RPI Zero W (one per room), but haven’t done any DIY with GPIO in the past.

I’m a bit confused regarding the hardware I will need to do this. I read here that D6T and Grid-Eye are supported, I’m thinking of going with Grid-Eye as I can still find those for sale on some shops (as compared to the D6T which is sold out everywhere), would any of the AMG8833 products from Adafruit work with the RPI Zero W? (i see 3 variations for sale, all of them include a Panasonic Grid-Eye as far as i can tell, but other then that I can’t really understand the difference between these 3 products)

Also, would only one PI and Grid-Eye be enough per room? I can’t seem to find relevant info regarding their supported range and field of view.

Thanks in advance.

Edit: To be more specific, the products I’ve found for sale are:

  • AMG8833 Grid-EYE 8x8 Infrared Array Breakout
  • AMG8833 IR Thermal Camera FeatherWing
  • AMG8833 IR Thermal Camera, 5V

A recommendation of which of these would be better to buy would also be greatly appreciated.

Most ones that specifically mention that they advertise as iBeacons should work fine. I have had good experiences with the portable beacons from Radius Networks, like their RadBeacon Dot. Good battery life and excellent possibilities for fine tuning the beacon settings via their app.

I think you need the first one from your list, or to link to it more specifically this one: https://www.sparkfun.com/products/14607. I soldered some header pins to my Grid-EYE module and attached it to the Pi like this, but I guess the SparkFun Qwiic connectors should work too if you prefer those.

The range is a bit finicky, since it depends on a bunch of factors: usual room heat, are there any direct sources of heat in the room, are there any windows where sun could shine through… in optimal conditions (maybe with some debouncing in place) you could achieve a detection range of 5-6 meters I think. The angle of the sensors can be taken from the spec sheet. The closer you are the more reliable the detections will be though. I use the Omron D6Ts by specifically pointing them to spots in the room that one would sit/lay in without much movement. The rest is covered by a PIR motion sensor. I suppose the best way to figure this out for your own place is just trying!

@mKeRix Thanks you, everything is much clearer now. :slight_smile:

Hi, I’m the following error message in the Room Assistant logs, ‘error - HomeAssistantService: Error: connect ECONNREFUSED…’ seems it’s refusing to connect to my mqtt setup, the cluster entity appears, but nothing else is shown. I’ve also posted this on git:

Any help would be appreciated, thanks

Config:

global:
  instanceName: livingroom
  integrations:
    - homeAssistant
    - bluetoothClassic
homeAssistant:
  mqttUrl: 'mqtt://192.168.x.xx:188'
  mqttOptions:
    username: xxxx
    password: xxxx
bluetoothClassic:
  minRssi: -20
  hciDeviceId: 0
  addresses:
    - 'xx:xx:xx:xx:xx:xex'

Logs:

[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[16:48:12] INFO: Setting up Home Assistant configuration
[16:48:12] INFO: Starting room-assistant
*** WARNING *** The program 'node' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
*** WARNING *** The program 'node' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
7/7/2020, 4:48:18 PM - info - IntegrationsModule: Loading integrations: home-assistant, bluetooth-classic
7/7/2020, 4:48:19 PM - info - NestFactory: Starting Nest application...
7/7/2020, 4:48:20 PM - info - InstanceLoader: AppModule dependencies initialized
7/7/2020, 4:48:20 PM - info - InstanceLoader: ConfigModule dependencies initialized
7/7/2020, 4:48:20 PM - info - InstanceLoader: NestEmitterModule dependencies initialized
7/7/2020, 4:48:20 PM - info - InstanceLoader: IntegrationsModule dependencies initialized
7/7/2020, 4:48:20 PM - info - InstanceLoader: HttpModule dependencies initialized
7/7/2020, 4:48:20 PM - info - InstanceLoader: DiscoveryModule dependencies initialized
7/7/2020, 4:48:20 PM - info - InstanceLoader: HomeAssistantModule dependencies initialized
7/7/2020, 4:48:20 PM - info - InstanceLoader: ClusterModule dependencies initialized
7/7/2020, 4:48:20 PM - info - InstanceLoader: TerminusModule dependencies initialized
7/7/2020, 4:48:20 PM - info - InstanceLoader: ScheduleModule dependencies initialized
7/7/2020, 4:48:20 PM - info - InstanceLoader: EntitiesModule dependencies initialized
7/7/2020, 4:48:20 PM - info - InstanceLoader: BluetoothClassicModule dependencies initialized
7/7/2020, 4:48:20 PM - info - InstanceLoader: StatusModule dependencies initialized
7/7/2020, 4:48:21 PM - info - RoutesResolver: EntitiesController {/entities}:
7/7/2020, 4:48:21 PM - info - RouterExplorer: Mapped {/entities, GET} route
7/7/2020, 4:48:21 PM - info - RoutesResolver: StatusController {/status}:
7/7/2020, 4:48:21 PM - info - RouterExplorer: Mapped {/status, GET} route
7/7/2020, 4:48:21 PM - error - HomeAssistantService: Error: connect ECONNREFUSED 192.168.x.xx:188
7/7/2020, 4:48:21 PM - info - ConfigService: Loading configuration from /usr/lib/node_modules/room-assistant/dist/config/definitions/default.js, config/default.json, config/local.json
7/7/2020, 4:48:21 PM - info - ClusterService: Starting mDNS advertisements and discovery
7/7/2020, 4:48:21 PM - info - NestApplication: Nest application successfully started
7/7/2020, 4:48:22 PM - info - ClusterService: livingroom has been elected as leader
7/7/2020, 4:48:22 PM - info - EntitiesService: Refreshing entity states```

In case you didn’t see my reply on GitHub: check if your MQTT port is really correct. The default is 1883. Connection refused is an error that you’d usually see because either the port is wrong or a firewall is blocking the connection.

1 Like

Oh wow, you’re right apologies, I didn’t realise I made a typo.

Many thanks!

Cool project. I tried using the HASSIO addon, and the Bluetooth Low Energy option, seems more effective than Bluetooth Classic for me (I was getting HCI0 errors). That said, it appears my setup is unable to produce stable results. I am running Linux Mint VM, with Home Assistant with Supervisor installed. I am using a Plugable BLE USB dongle - which truthfully hasn’t been that stable so maybe that’s the cause of the problem. On my phone, I’m running Beacon Scope to mimic an iBeacon. The MQTT state will alternate between Home and Not Home every 30 seconds. Any idea what is causing this behavior even though I haven’t left the room? If it’s the USB dongle, does anyone have any recommendations? Thanks.

Have you tried increasing the advertisement rate in Beacon Scope (if that’s possible) or increasing the timeout of the BLE integration in room-assistant? The latter should even help if your dongle is just acting up a bit, provided that you can live with a slight delay in the switch to not_home. Maybe try 30s or 60s.

To debug this you could also run hcitool lescan on the machine to see what it receives on the system level.

Thank you for your thoughtful suggestions @mKeRix. I think the issue is, if I get a false capture in MQTT (not_home) even though the device is home, then it may trigger automations (eg security system).

I think the adapter is problematic in linux though. I couldn’t run “hcitool lescan” - as I was getting “Set scan parameters failed”. However, Google pointed me to sudo hciconfig hci0 reset. Then I ran sudo hcitool lescan, and I can see a bunch of MAC addresses of different devices. Many of the mac addresses are repeated. Conversely, the scan seemed to be hung after 20 secs.

image

Cheers,

J

I used hciconfig command in SSh addon, but command not found.

I’m excited to try this out. I’m planning on using raspberry pi zero w’s for the bluetooth hubs. Can I use any motor sensor I have in HA, or does it have have to be a sensor hooked up to a linux board like the pi?

Is there a way to force a manual scan?

Use Case:
room-assistant shows a not_home and it has been in said state for 5 minutes. An automation is triggered to turn off a light but before doing so it would be nice to be able to force a manual scan. If the manual scan still says not_home then turn off the light. Otherwise, do not turn off the light.

It would also be nice if a tracker (e.g. rpi0w) can force another tracker to do a manual scan. That way if the bedroom rpi says not_home (not in the bedroom) then force the other rpis to scan. If the kitchen rpi says home (in the kitchen) then that is the current location of the bluetooth device. If all trackers says not_home then the bluetooth device is currently out of range and thus not_home.

I am trying to use our Letscom smart watches to turn on lights as we come into rooms after dark. I have made a lot of progress, however I am having some issues as well. Could anyone please review my setup and tell me why the state of the watches is true/false instead of home/not_home? Thanks in advance!

Home Assistant config.yaml

device_tracker:
  - platform: mqtt
    devices:
      smart_watch: 'room-assistant/device_tracker/ble-MACADDRESS-tracker/state'
      id107_ble: 'room-assistant/device_tracker/ble-MACADDRESS-tracker/state'
    payload_home: 'home'
    payload_not_home: 'not home'  
    source_type: bluetooth_le

This is my Room Assistant configuration

global:
  instanceName: basement
  integrations:
    - homeAssistant
    - bluetoothLowEnergy
homeAssistant:
  mqttUrl: 'mqtt://xxx.xxx.xxx.xxx:1883'
  mqttOptions:
    username: XXXXXXXXX
    password: XXXXXXXXX
bluetoothLowEnergy:
  processIBeacon: true
  maxDistance: 4
  timeout: 5
  updateFrequency: 0
  whitelist:
    - MACADDRESS1
    - MACADDRESS2
  tagOverrides:
    MACADDRESS1:
      name: Smart Watch
    MACADDRESS2:
      name: ID107

Could you elaborate what you mean by motor sensor or more specifically, what you’re trying to achieve?

It’s not currently possible, but I’m open for adding something like this. Would be great if you could open a feature request on GitHub for this. One thing to keep in mind is that for Bluetooth Classic only one instance of room-assistant should query a device at a time, as the readings are unreliable otherwise. Alternatively you could do a “power scan” sorted by previously closest distance maybe, which just cycles through the instances quickly.

Your room-assistant config looks good, for the device trackers in Home Assistant could you adjust the payload settings to 'true' and 'false' as shown in the docs? These values tell Home Assistant what it should convert to the corresponding device tracker state.

1 Like

Yes, I will submit a feature request on GitHub. Thank you.

I’m wondering why I’m getting state changes in HA with room-assistant when the state hasn’t changed. From my understanding this shouldn’t really be happening, right? A state change should onyl occur when old_state != new_state, but this is what I see in the logbook and NodeRed triggers every time there is an update. I can work around it by actually checking old against new state, but I think it would be better to only have state changes, when, you know, the state actually changes.

image

I searched on github for this issue, but couldn’t find anything. Any ideas why this is happening?

For the most part room-assistant will only send messages to MQTT when something changes, it also sends the current state of all entities to MQTT whenever the leader changes though (to make sure the state is up-to-date). I believe that this is what you might be seeing here. I thought that Home Assistant also filters these state updates, but I guess I misunderstood that part. For Node-RED I usually check the “output only on state change” box of the events: state node, which may be why I never noticed this before.

Maybe check your leader sensors In Home Assistant to see if there are a lot of changes happening. If that’s the case you could play around with some of the cluster options to stabilize that a bit more.