Ruuvi Gateway

[ssahlender]

Hello Community,

thanks for all the cool theengs tools, they are really great work.

I'm using right now OpenMQTTGateway and TheengsGateway and I'm I little bit unsure where to post my question.

Well let's start: As mentioned I play around with the OpenMQTTGateway and TheengsGateway, both are great when the sensor are locate nearby. But I have some sensors which are 30 meters away and the aren't seen with either of them.

I also own a Ruuvi Gateway which has kind of weird looking antenna. But that one receives the signals from the sensor 30 meters away.

Also the software allows it to publish all ble messages the gateway receives in mqtt.

Here my idea / question starts:

How to decode it the best way?

• Take the decoder library and write some python around it, to read (raw) from and publish (decoded) message to mqtt
• Add a parameter to theengs gateway or openmqttgetway to connect to specific mqtt topic and decode / republish the messages
• Any other ideas? ( Just by that specific esp32 model, because it has a great antenne )
• OpenMQTTGateway firmware for Ruuvi Gateway

If need, I can post how the published topics from ruuvi gateway look like.

Thanks + Regards Stefan

[DigiH]

Hi @ssahlender,

interesting condition with your set-up. As Theengs Gateway is already able to receive undecoded MQTT messages from one or more OpenMQTTGateways, it would be possible to add the topic the Ruuvi Gateway publishes it's MQTT messages on to then have Theengs Gateway decode them.

If the undecoded messages are similar to the direct Ruuvi Tag messages it might already work with the existing Ruuvi decoders, if not possible some new decoders would need to be implemented.

A good start would be if you could get your sensors close to OpenMQTTGateway, turn on Publishing advertisement and advanced data and then post some messages directly from OMG plus MQTT messages for the same sensor from the Ruuvi Gateway for comparison.

Any other ideas? ( Just by that specific esp32 model, because it has a great antenne )

Personally I like to use ESP32-WROOM-32D as they have a sticking out built in antenna or even the ESP32-WROOM-32U which allows for an external antenna with different gain to be attached. For my set-up these two models improve the reception over other ESP32 models, but I couldn't say if they would also cover your 30 meter distance.

OpenMQTTGateway firmware for Ruuvi Gateway

Reading the specs of the Ruuvi Gateway, it is based on an ESP32, possibly connected and accessible via the USB-C port. But the feasibility of installing OpenMQTTGateway on it would need further investigation :)

[koenvervloesem]

These are BLE advertising data structures in Length/Type/Value (LTV) format:

02-01-06: Length 2, Type 1 (Flags), Data: 06 (with length 2 - 1 for the Type byte)
1B-FF-DATA: Length 27, Type FF (Manufacturer Specific Data), Data (with length 26)
13-16-DATA: Length 19, Type 16 (Service Data - 16-bit UUID), Data (with length 18)

So if you want to correctly decode the value of the data key from your Ruuvi Gateway's output, you need to cut this data into its advertising data structures and then convert the structure for type FF to a manufacturerdata key to send to Theengs Gateway, and convert the structure for type 16 to servicedatauuid and servicedata keys. See section 2.3 of the Assigned Numbers Document for the full list.

We can probably add support for this in Theengs Gateway, but maybe try this first in Node-RED and see whether this approach works.

Edit: You already figured this out partly while I was writing this :-)

[ssahlender]

@koenvervloesem Thanks for feedback, well let's say i kind of did the hardcoded implementation ;-). Thanks for your feedback.

So in case to skip the complete node-red stuff in between, ruuvi gateway output looks like this before it's processed by node-red:

For xiaomi from MQTT Explorer:

For ruuvitags from MQTT Explorer:

As also said to @DigiH the ruuvi gateway antenna is really great. I live in a house from the 1930s with very thick walls but the gateway catches it all. The xiaomi sensors are distributed over 4 floors, as the ruuvi tags are. Two of the are outside a little bit away from the building.

Just don't know how many of the Theengs / OpenMQTTGateway users own one of this gateways since it's kind of expensive when you didn't get it during the kickstartet campaign. It's around 200 Euro.

Regards Stefan

[DigiH]

@ssahlender Thanks for all the info and trying out the node-red conversion implementation which looks like it's working really nicely for you!

While it's true that possibly not many other users own the Ruuvi Gateway, as Theengs Gateway already implements decoding undecoded messages from OpenMQTTGateways, it could well be worth looking into adding the additional Ruuvi Gateway decoding to Theengs Gateway, if @koenvervloesem and the others in the team agree.

Are you planning to publish your node-red implementation for others to use the same?

[ssahlender]

@DigiH

Well I could put my flow on github and publish it to the node red website ... also with the info, that it's WIP and the algorithm has lot of room for improvement.
Will write here when it's finished. Just give me some days have to learn markdown a little bit ;-).

Regards

Stefan

[DigiH]

Hi @ssahlender

So, looks like theengs gateway even decodes this: {"id":"58:2D:34:3B:8B:17","mac_type":1,"servicedata":"5020aa0194178b3b342d58061002f901","servicedatauuid":"95FE","ruuvi_raw":"020106131695FE5020AA0194178B3B342D58061002F901","rssi":-73}

95FE insted of 0xfe95

This is being decoded because this particular LYWSDCGQ decoder does not actually use the serviceuuid in it's model condition. If it would have, or any other decoders using the actual serviceuuid, of which there are many, it will fail if not in reversed little endian order. The 0x prefixing should not matter that much AFAIK, without having looked at it more closely right now.

Just FYI for a correct serviceuuid recognition of your node-red implementation.