I’m using RuuviTags in an industrial (factory) setting, and for me PoE would be the optimal form of connectively/power. If that’s not possible because of the extra cost, what about an unpowered ethernet port?
The concern with wi-fi is it’s unreliability when compared with a hard-wired network connection. With an unpowered ethernet port I would probably use an external PoE splitter/adapter (to 5V) to power the gateway from the existing PoE infrastructure.
Actually, just a few days ago we decided to add one 
See #ruuvigateway on slack.ruuvi.com for more info.
Merry Christmas! 
Oh yes! Great decision!! 
I just contacted all the approved beta testers and sharing a part of the email in here to keep everyone posted about the project status:
“After the blog post about Ruuvi Gateway, I have received an enormous amount of messages and interest about the project. And that’s good! We have received some really valuable feedback too.
In the beginning of the project, we were planning to keep everything as simple as possible but without making any compromises with the quality of the antennas. However, soon after the initial pre-launch (the blog post), we decided to reconsider the decision of having only wireless internet connectivity on board. The main reason for this was that WiFi networks are not always reliable enough for business customers and may also cause headaches for some consumer users.
So, we decided to take the gateway to the next level by including an Ethernet connectivity (RJ45 port) 
Unfortunately, this new feature forced me to start designing the PCB pretty much from scratch and this has caused some delay on the PCB prototyping. The design is progressing well and currently we’re aiming to finally start producing the prototype boards right after our Chinese friends are returning from their long New Year’s holidays.
However, even the PCB layout is delayed a bit, it won’t actually have too much impact on the schedule of the end product because firmware work has progressed well. In addition to the basic functionality, Ethernet firmware support is in the making and next week or the week after you will most probably start to see some progress in the repo.
Note that the WiFi gateway firmware (both ESP32 and nRF52 parts) are already functional and can be tested by flashing them on ESP32/nRF52 dev boards. The hotspot web-UI currently looks not pretty and may have some hidden bugs, but that’s why we’re here to test it and make it better.”
Great update, we walked away using wifi last year and are now only deploying Ethernet based GW’s
Oooh! Pretty.
Trying to think of size, and scaling from the ports, it looks a little bigger than 2 RPis side by side. Is that right? Can you give some dimensions?
The PCB is about 10 x 6cm 
Nice that ethernet made its way to the gateway. PoE would be a nice improvement for maybe a next revision.
Is there a further roadmap of this project available?
PoE can be supported with an external splitter, we do not have plans of supporting internal PoE at least yet.
Hey everyone! It’s time for a Gateway update.
Lately, we’ve been working with mechanics, firmware, configuration user interface, backend, antenna simulations, custom antenna manufacturing and other tasks that have to be taken care of in prior the mass production. Selected beta testers will get their hardware pieces starting from next week. Everything is moving forward nicely.
Here is the latest mechanics design for your comments:
And the circuit board:
The Gateway will be easy to use and quick to set up, but we’ve also designed the the mechanics (and software) to be hacker friendly. Ruuvi Connector flex cables are supported and a large sized expansion board will fit nicely inside the enclosure. More in-depth info and expansion board template KiCad project(s) will be shared later.
Questions, comments? Yes, please!
Looks terrific. Does the firmware currently limit ‘harvesting’ to only Ruuvi tags?
The current firmware listens in to all Bluetooth transmissions, so you can use it with iBeacons, Eddystone beacons and even to check e.g. Windows PC beaconing messages. Currently only limitation is that data has to be in advertisement and at 1 MBit / s, BLE 5.0 features such as long range or extended payload secondary advertisements are being worked on.
Any ETA when this will be out?
What options there are to connect this to the mobile network?
ETA to start mass production is currently not later than Q1 2021. We work hard to get everything ready asap, and more early access devices will be available earlier than that.
This is the Rev.A1 circuit board prototype:
and this is the mechanics status:
You can use pretty much any internet access point that offers WiFi or Ethernet connectivity. We have also reserved room for internal expansion shields and wireless connectivity circuit boards (for example LoRaWAN and NB-IoT) are planned for the future.
Does this mean that Ruuvi Node is dead? Are there any plans for a device with direct mobile network connection?
Not dead but postponed. We do have plans, yes. And we’re continuously prototyping with direct mobile connectivity, too. But currently, I cannot give you promises about exact production schedules. You can find some open source code here:
Thanks for the update and clarifications.
We are working on a project where we would send an alarm message to a mobile phone a) whenever a reading (e.g. temperature) from a monitored Ruuvi tag is out of the allowed range and b) whenever too long time has passed since data has been received from a monitored Ruuvi tag (tag dead or out of range).
We think that the coming Ruuvi Gateway would be a good starting point, but how to implement the rest? It would be nice to find something as compact as a Raspberry Pi but with much better support for a mobile network connection and messaging such as SMS or Telegram.
I think here’s two different problems, a gateway with mobile connection and alerting. There are routers with mobile connectivity options, and the alerting can be done with e.g. server on the cloud, InfluxDB and Grafana.
We’re also working on our own backend for tag data, https://github.com/ruuvi/ruuvi-network-serverless
Thanks for your input. Are you saying that there are no devices that could handle both the mobile network connection and the alerting directly to a mobile phone?
