Meteor and the Internet of Things (IoT) - whats best to use? Collection, Meteor-Streams, Streamy

If I’m not mistaken Streamy is built on top of meteor streams, but should look at the source to confirm. Either way Meteor Streams will probably be more performant as it has less overhead calculations. In other words with Meteor streams you’ll have to write all the code yourself but it’ll be adjusted to your exact needs, so you’ll be able to optimize.

Also if you need very fast database performance you should look into redis as a database.

If these solutions don’t fit your needs you’ll probably have to write your own solution, which wouldn’t be a surprise if you’re building a realtime mmo.

1 Like

Hi @nlammertyn, @nikke

First of Streamy and MeteorStreams are independently solutions with different architectures.

We are working very successful with local meteor collection and own publisher methods. For our solutions it is also absolutely nice feature, that we have access to previous documents on local collection as well.

@nikke what you are looking for should be realizable by observe methods as well. Have a look at this timer demo which will update every 0.1 second.

Maybe you get a hint out of that.




Meteor Streams works fine for now, it’s just an outdated and dead project. It’s bound to cause problems later on as Meteor improves over time. We actually did build our own solution before Meteor came out using, but now we’d like to stick with Meteor as that’s a managed solution and has caused us far less headaches than in the days of node.js, grunt, etc. Integrating a solution like that runs simultaneously with Meteor is not an option as a server would require an extra port, breaking SSL. Also having two websocket servers is just absurd I guess.


Thanks for the example. I was not aware that one could publish on the server like that. Is the server still creating a mongodb collection behind the scenes? E.g. is the Ticker counter being persisted somewhere? I guess it doesn’t matter as long as it doesn’t impact performance, but I’m still curious to know.

The main problem we’re facing is that we mostly need to send single events to users. Consider a player that has attacked a monster. We’d need to send an attack event using the monster ID and the weapon ID they’re carrying.'combat:attackEntity', {
    victimEntityUuid: victimEntity.uuid,
    itemUuid: item.uuid

Note that we don’t care about saving this event, or having access to previous documents. It’s just fire and forget. Using a local collection for this becomes hard unless we use an ‘events’ collection and publish it to each user, that acts as a message bus. I believe this is exactly what Meteor Streams is doing, except that it is outdated so we might take a closer look at your example. Thanks again!

@nikke - I am pretty sure you easily can switch to local collections because MeteorStreams is exactly that. See: and as relevant source parts. So timing isn’t different from that.

Also there is no mongo Collection created at database level, only the mini-mongo on client side has its data driven collection. On server side it is just through flown value.

I will create an example for your usecase later on tonight.


1 Like

Hi Tom,
Do you have any more information/a repository for your meteor/arduino/mqtt/streaming configuration? We are just beginning our application requirements in an effort to create a ‘smart town’ and open-source the app to ‘engage it.’

We would like to tie in a LoRa gateway JSON data and map publications and lat/lng in ‘real-time’.
Any help will be much appreciated. I’d welcome a brief consultation too!
Thanks, much.

Hi @artsandideas - I may not yet use information about our projects in public but if you write me a PM with your needs, I can give some advises from our experiences.


How would you use that:

var Ticker = 0;

Meteor.publish('streaming', function(){
  // safe reference to this session
  var self = this;
  // insert a record for the first time
  self.added("streamer", "timer", { ticker: Ticker });
  // from now only update that record continously every second
  var handleInterval = Meteor.setInterval(function() {
    self.changed("streamer", "timer", { ticker: ++Ticker });
  }, 1000);
    handleInterval && Meteor.clearInterval(handleInterval);

to broadcast a certain message to all connected clients? I’d like to call a function from the client on a certain event to publish on all subscribers.

I’m currently having trouble to change the Ticker var from the client.

Any hints are greatly appreciated.

Hi @atez

You do not need to do that in a timed publishing method. You may send out to all / filtered subscribers on that method

Got luck

See also my question and first / alternate approach on StackOveflow:

and my answer later here in thread with a functional MeteorPad example

Hi @atez

I checked my own written down infos and got some erratas. Here you find a functional meteorpad where you may connect with a number of browser windows and push messages to all subscribed.

When starting a new window / subscription every one gets a warm welcome message. After that you may press the button and see how the buddy sends messages to others. You always see the last 5 messages.

Hope that makes it clear for anbody.

MeteorPad Example for Publish and Subscribe and Broadcast messages


1 Like

@mkarliner what is your thought on the new pizero ? a $5 raspberry pi ?

Very simply, I think this is a genuinely sesmic event.
There are a variety of very cheap linux boards planned, but the Pi Foundation has
trounced everyone. I’ve been touting the Raspberry Pi as the ideal platform for IoT local hubs for a while, but with the advent of the Pi Zero, full linux machines as IoT edge devices are not only possible, but very likely to be the default platform. The exceptions are for very low power, battery powered applications, or those with extreme real-time requirements.

I think this was a red letter day.

1 Like

I tried all of the Meteor packages for IoT related data transfer protocols and gave up on all of them. In the end I used the node package net and it worked well. My guess is I had to write more lines of code than if I used a Meteor package but it really wasn’t that bad. Details on the net package are here:

In terms of IoT hardware, I agree with @mkarliner. I am working on an IoT project for plant floor data collection and we are very interested in Pi Zero and C.H.I.P. I think Pi Zero with networking adapter comes to $11 plus setup time where C.H.I.P. comes with networking libraries and hardware built in for $9. Pi has better ecosystem obviously. I would post the publications,etc. but the IP is owned privately so here is the pseudo-code similar to what @tomfreudenberg was discussing, with some additions.

  1. Client logs in and adds device using device master including information on host and port
  2. Client selects which device to connect to; app saves the host and port in Session variables.
  3. A Meteor.publish function exists on the server which basically runs a Meteor.setInterval every 500ms to see if the host and port information are valid before opening a socket, reading the output, and closing the socket using net.
  4. A client collection is created to save the output in and an observe function waits for changes and then updates the local collection and saves the new value to another Session variable that can be used in template helpers

@atez if you create a field somewhere to change the ticker manually, have your client code save that value in a Session variable. Meteor subscribe can pass variables to Meteor publish, so inside your this.autorun on the client you should save the Session variable as a local variable and then pass it to the subscribe function. Then use it.

I have a feeling that the Pi Zero will lead to boosted sales of the model B and B2, as people do the same calculation as you and opt for the ‘large fries’ version. OTOH, I’m interested in Pi Zero and LoRa, so I’m not automatically putting a wifi dongle on.

Off topic, but you might want to look at our platform ThingStudio, which is a meteor based IDE for making IoT user interfaces. I realise that its not quite what we’re discussing here, but just saying…


Hi Roger, how do you handle security and authorization when using the net package? Do you have established some kind of key-exchange or something else?

The system runs on private networks so the firewall is the first layer. And then the connection times out if you poll too slowly or quickly so you have to know how fast to open and close connections. And finally you have to send the device a certain letter before it will tell you what the read-out is and you can’t read more than once in a connection. The device I am connecting to doesn’t support authentication so this is what we worked out. In general I assume I will need to develop some kind of character exchange for other similar devices or where we build the one we are thinking of building.

@mkarliner (or anyone), hi I watched your DevShop talk in London (that was you right?) on using Meteor for IoT. One of the things I have been investigating is whether it is worth it in the long run to use MQTT to communicate with IoT devices instead of DDP, given the uncertainty of the future of DDP with the coming of Apollo, which has yet to be discussed in the Transmission podcast.

That said, are there any significant advantages of using MQTT than DDP for IoT communication?

Hi Richard ( @lai )

Not sure what is the important reason for Mike ( @mkarliner ) but for us it was a decision on infrastructure. In case that we had really good experiences with rabbitMQ servers, we choosed MQTT as transport service for the IoT devices. That allows us to write down very easy IoT clients (just pushing there messages via MQTT) and could believe in delivering and monitoring the infrastructure without the need to invest into development there. So we just take out the IoT messages on our server side and put them into the main meteor app.

For senders like camera, gps, temperature, barometer … it really works fine. Also you we found MQTT libs for a number of devices we tried out (Raspi Zero, Onion, etc.)

Have a nice weekend

The upgrade did not even complete:

I tested it with and every aspect of local collection streaming to the client seems to work.

Just in case anybody would be interested, I have just recently published some packages related more or less to problems/ideas described here. Here is of them -> meteor-custom-protocol.
Basically it allows to transmit anything else along the DDP on the same websocket connection without interfering with Meteor. You can create any encoding/decoding mechanism you like. The only limitation is that it must boil down to strings, as the underlying SockJS supports only strings.
I am already using this in production for more than a year improving the scalability of pub/sub. I have also used it for implementation of WebRTC signaling over default Meteors connection and it works pretty well.