Ruuvi sensors -> Ruuvi Gateway -> Home Assistant (Easy!)

peltsippi · October 28, 2020, 1:11pm

Can ruuvi gateway run influxdb database? If yes, all you need is to have homeassistant running in same network and configuring influxdb sensor to homeassistant.

I am not sure how the user experience is with hassio. But some kind of auto-discover implementation for ruuvi gateway might make configuration at least almost plug and play: https://www.home-assistant.io/integrations/discovery/

balda · October 28, 2020, 1:28pm

Home Assistant auto discovery works with MQTT. So, if Ruuvi Gateway implement a MQTT broker, it should be possible to use it

I explained here how HA use “Devices” (Ruuvi Tags) and “Entities” (measures of tags):

github.com

balda/ruuvitag-discovery/blob/master/DOCS.md#home-assistant-mqtt-discovery

# Home Assistant Add-on: RuuviTag Discovery

## Installation

In the sidebar menu, click on **Supervisor** page.

<img src="https://raw.githubusercontent.com/balda/ruuvitag-discovery/master/doc/homeassistant-install-supervisor.png" width="248"><br>

Navigate to **Add-on store** panel and click on **Repositories** menu on the right.

<img src="https://raw.githubusercontent.com/balda/ruuvitag-discovery/master/doc/homeassistant-install-addon-store.png" width="1170"><br>

Copy and paste this repository url `https://github.com/balda/ruuvitag-discovery` and click on **Add**.

<img src="https://raw.githubusercontent.com/balda/ruuvitag-discovery/master/doc/homeassistant-install-addon-repositories.png" width="414"><br>

On the bottom of the Add-on store page, click on **RuuviTag Discovery**.

<img src="https://raw.githubusercontent.com/balda/ruuvitag-discovery/master/doc/homeassistant-install-ruuvitag-discovery.png" width="347"><br>

This file has been truncated. show original

And here is my implementation of the auto discovery (presentation of the “Device” on /config topic and broadcast measures on /state and /attributes topics):

github.com

balda/ruuvitag-discovery/blob/master/lib/broadcast/ha_mqtt.js

'use strict'

const mqtt = require(':lib/mqtt')
const presentInterval = require(`#ha_mqtt.present`)
const measures = require(':dict/measures')
const measuresIndex = {}
for (const measure of measures) {
    measuresIndex[`${measure.field}`] = measure
}

const broadcasterFactory = (target) => {

    const broadcaster = {}

    broadcaster.stoping = false
    broadcaster.presented = {}

    const topic = (tag, measure) => {
        return `${target.topic}/sensor/${tag.id}/${measure}`
    }

This file has been truncated. show original

io53 · October 28, 2020, 1:29pm

This will be great! Even for us that already have ruuvitag data in homeassistant, this will give far better range than a normal bluetooth dongle/rpi and take a way the hassle that bluetooth dongles can bring

I guess the easiest way to get this going would be to have the gateway expose and API from where a Ruuvi integration could be polling data, or even better, subscribe to data to get it in real-time

Scrin · October 28, 2020, 6:38pm

There is actually already a /metrics http endpoint for monitoring the gateway health and status programmatically. This same metrics endpoint could perhaps include the tag readings as well for a simple “pull based” integration. This would also allow Prometheus to scrape the tag readings at the same time, offering yet another way to get Ruuvitag data to Grafana.

On the other hand, a more “real-time” integration would be a “push based” integration, easiest probably being with MQTT, which the gateway already uses/supports.

Perhaps this “official ruuvi integration” could even support both modes; the pull-based for the most simple setup, only configuration needed would be giving the gateway address (or perhaps even some sort of auto discovery could work?), and the push-based for more advanced users who already have a MQTT broker or specifically need faster “response times”.

io53 · October 28, 2020, 9:43pm

That sounds like a good way to go about it. With the way home assistant store data it does not even make sense to store all sensor data, so polling at n interval will be preferred in most cases anyway.

I agree that for real time data MQTT is probably the best way to go. That would not even need any special ruuvi integration or setup (at least not if the gateway supports mqtt auto discovery). If we where to push data via HA’s rest or websocket api there would have to be extra setup so might as well spin up a mqtt broker at that point.

Hotzilla · January 23, 2021, 10:13pm

I implemented a merge between few MQTT projects that had not been implemented to support Ruuvi -> raspberry -> MQTT -> Homeassistant with autodiscovery:

architecture

The installation instructions and code available here:
https://github.com/Hotzilla/ruuvicollector-to-homeassistant-mqtt

So if you are running Homeassistant at server that doesn’t have bluetooth, it means that you need to push it to another format through network. MQTT works very nicely, as it is very efficient packet format. Also autodiscovery means that you don’t need to configure the sensor at homeassistant at all after installation.

BaTTman · February 15, 2021, 8:18am

Is there away to name tags? Now they show up in HA by their mac-addresses.

BaTTman · February 17, 2021, 5:49am

Found it! It was in config.json.

sergioisidoro · March 27, 2021, 10:49am

Hey there,

Small update here, that the Ruuvi home assistant custom component for HASS.io is now also on the official HACS store:

A major step to also make this component available as an official component of Home Assistant

io53 · March 28, 2021, 7:43pm

Really neat project!
I’ve been playing around a bit with home-assistant for the gateway and in the end it would be quite similar to your component. Just instead of getting data from BT it gets it from the gateway API.

I’ve been using HA for years, but only made my own “integration” done via MQTT so I’m not too familiar with native integrations
Do you think it would make sense to have the gateway a separate integration or do you think it could be added into yours?

The gateway api (http://history?time=<time-since-last-poll (optional)> returns data like this:

{
	"data":	{
		"coordinates":	"",
		"timestamp":	"<timestamp>",
		"gw_mac":	"<mac>",
		"tags":	{
			"<mac>":	{
				"rssi":	<rssi>,
				"timestamp":	"<timestamp>",
				"data":	"0201061BFF990405..."
			},
		}
	}
}

So all it would have to do is poll the gateway api at some defined interval, parse the data and publish the new states to HA.
As the gateway dns is RuuviGateway<2-last-bytes-of-mac> I think it would be possible to have HA auto-discover it, that’d be very cool and user friendly

sergioisidoro · March 28, 2021, 10:07pm

Good question. I don’t know. The component I’ve been working on uses the domain “ruuvi” which would be nice to use for the GW as well. But on the other hand, there’s no point loading ble dependencies if the GW is purely network based. If that’s not a problem, it’s totally doable to keep them in the same integration

Making a component for HA is easy at first, but then I experienced a slowdown in the learning curve when it comes to testing and the details of some of the internals I could try to share the knowledge I’ve gathered so far.

Btw, I’ve created that Ruuvi Friends organisation in Github to be able to move faster with the Ruuvi related projects. In a lot of cases maintainers get busy and projects grind to a complete halt because PRs don’t get reviewed or merged. In an organisation other people can help and collaborate to get things forward.

If you’d like I could invite you to the org, and we could setup something together there for the GW, and go the same “route” as the previous component:

Start with a “manual” custom component
Set it up in HACS store
Move towards a full official integration

However I don’t have a GW, so I can’t test things myself.

io53 · March 30, 2021, 6:17pm

I don’t see a problem with having the bluetooth dependencies there unless they cause problems for installs that does not need them. So I suggest we try to keep it as one component and see how it goes, we can always split it up later if needed :).
Sure throw in an invite :). I think that we would be cool to eventually have the project under http://github.com/ruuvi/ . Thoughts on the repo and combined integration @otso @lauri ?

So basically we need to just make a scheduled http get call, looks fairly simple https://developers.home-assistant.io/docs/integration_fetching_data . The parsing could be done with the decoder in the simple-ruuvitag library.

Do you have any suggesting how to cleanly being able choose between using bluetooth/gateway as data source? (in the yaml config)

We can throw together a script that simulates the gateway until you get your hands on one, should be easy.

lauri · March 31, 2021, 2:57am

Thanks @sergioisidoro for your contribution so far! If you haven’t already, you should receive your Gateway today.

All this sounds good to me. Like @io53 suggested, a combined integration could be a good way to start with and if needed, that can be split later. Development can be under the Ruuvi Friends repo for sure and we can discuss later if it’d make sense for all the parties to have it under the official Ruuvi organisation later.

io53 · March 31, 2021, 5:34am

Here is a small snippet that polls and parses the data from the gateway, using simple_ruuvitag Fetch and parse data from Ruuvi Gateway · GitHub

So there is not much extra stuff needed over what already exists in your integration

co12294 · September 14, 2021, 5:14pm

I just received my gateway yesterday, and configured it to send sensor data to my local HA MQTT broker. There’s another thread here about using the pyscript add-on to process the events and feed them back into MQTT to take advantage of HA auto-discovery.

Question: since the gateway already has the code to send MQTT messages with the encoded data, would it be a reasonable approach to just add a configuration button for “Homeassistant (Auto-Discovery)” under the MQTT section in the web UI on the gateway, then use this flag to set the topic and message format, e.g.:

homeassistant/sensor/f33c5fc10393/humidity/config {"stat_t":"homeassistant/sensor/f33c5fc10393/humidity/state",
"json_attr_t":"homeassistant/sensor/f33c5fc10393/humidity/attributes",
"name":"Living Room Humidity","unit_of_meas":"%","dev_cla":"humidity",
"uniq_id":"ruuvitag_f33c5fc10393_humidity","device":{"ids":"ruuvitag-f33c5fc10393",
"mf":"Ruuvi Innovations Ltd","mdl":"RuuviTag","name":"Living Room"}}

homeassistant/sensor/f33c5fc10393/humidity/state 40

homeassistant/sensor/f33c5fc10393/humidity/attributes
{"RuuviTag":"f33c5fc10393","Measure":"Humidity","Unit":"%"}

co12294 · September 18, 2021, 10:08am

I posted a link to my Github repo with a working pyscript script to process the raw MQTT events and feed it back into the MQTT broker for Home Assistant. If you’re interested in checking it out, it’s in this thread, along with some great discussion and the original script that got me started.

miraakkeli81 · November 21, 2021, 3:58pm

I´m also eagerly waiting for official add-on for Home assistant My coding skills are pretty limited, so easy to use add-on would be really welcome. Hoping to see it some day

oiv · November 30, 2021, 1:09pm

Hi

I could not wait anymore so I built a node-red function to parse and push config, status and state messages to home-assistant. Code is in Github. The part for parsing tag is taken from ruuvi lab RuuviLab | Node-RED Node

The function has a throtling which lets through ,essages 1/minute/tag. Config messages are resent every 10 minutes. Not sure that is ok, but looking other devices using mqtt discovery that should be ok…

Worst part was to get the gateway config set to send mqtt. The gateway config tries to be too easy ending up being hard to setup.

brgds, oiv

ttu · January 30, 2022, 2:35pm

Hi, I created an extended fetch data script with authentication, types etc. Thanks to @io53 for a good snippet to get me started fast.

Authentication logic is ported from Ruuvi Gateway’s web interface.

I added the script to GitHub - ruuvi-friends/ruuvi-gateway-fetch-data-script: Python script for fetching and parsing sensor data from Ruuvi Gateway.

It is pretty complex for a simple script, as it is also a test code for decoder types and for a Python package code.

gcshum · April 2, 2022, 4:19pm

Hi oiv,

Would you please show me what to do to get the Ruuvi Gateway discovered by the MQTT integration? I followed your instructions in your Github and made the Ruuvitag MAC changes in “parsetag” function node and set up the MQTT broker information. But the Gateway does not show up under the MQTT integration. I have enabled auto-discovery in the MQTT broker. Oh, the “Ruuvi” and “send to ha” nodes show connected.

BTW, The MQTT broker is receiving messages from the Ruuvi Gateway when I listen to the ruuvi/# topic.

Please help. Thanks!