Hi out there.
We are using meteorjs for long time now as our framework for building applications around these IoTs. Our current project is on SkippersBestFriend and this is running on a UDOO ARM board.
We are controlling and taking data from a lot of sensors and re-publish those data to our own application as well as being a router and gateway for NMEA data to IP-Stream.
To interact with the hardware elements like GPS module, GYRO and so on, we are currentlty using I2C, CanBus, Serial and IP. With Meteor-Streams we are pushing the data to the client-app like in function Live-Charts App Screenshot.
I had a look on Michael Karliner’s DevShop where he propagates usage of Meteors low-level publish API in conjunction with client collections.
On one other side there is YukanOO Streamy as I found in a discussion here on forum which is using its own sockets.
My question is, what might the best decision to publish data gotten from hardware-sensors by server-app to the clients?
Any suggestions?
Thanks,
Tom
3 Likes
The advantage with local client collections is that you have the full might of mini Mongo to select, sort and otherwise manipulate the data. Also, I have the more vague feeling that it keeps within the spirit of Meteor, while incorporating pub/sub paradigms. Also, if you choose to persist your data, you are not suddenly changing API in mid stream. So, say, if I and using a local client collection, and then decide to take it server side, nothing needs to change in my client code.
Oh, I should point out that I’ve released mkarliner:mqtt on atmosphere, which is a wrapper for the npm module MQTT.js. This will give you both server and client side MQTT connections. It’s my first package, so please be gentle. Also, I’ve only managed to make for OSX and 64 bit linux.
2 Likes
Hi Mike ( @mkarliner ), hi all,
Just a discussion to you. I use by now both Meteor-Streams and Meteor Client Collections. I considered to drop Meteor-Streams completly but did not find an elegant solution.
Just as an easy example:
I wish to push the server time each 15 seconds to the client.
When using Meteor-Streams I just use a setInterval and emit a notification to the clients.
I can do the same when setting up the setInval function inside Meteor.publish
For that both is function equal
BUT
while on Meteor-Streams just the data is posted ONCE to the client,
using the collection, the collection ON CLIENT side is raising by element each 15 seconds.
When working with data from MQTT or IoT this behaviour, that the client has a collection with data, is fine
BUT when just posting updates of ONE data package this wasting memory on client.
Do you have a suggestion to NOT EXTEND the client collection than ONE RECORD?
Cheers,
Tom
Hi @arunoda
just a short question for your personal opinion: would you still suggest to use meteor-streams in general or should I switch to another technique? If yes, what technique would you suggest?
Thanks for your note
Tom
1 Like
Meteor Streams is a dead project. So better to use something like Streamy or so on.
1 Like
Use upsert on the local collection, with a key of the topic. Then you will have a collection with one record for each distinct topic, including wildcards, with the last message in it. That’s what I use.
Tom, have you looked at our project ThingStudio http://www.thingstud.io? This is, of course, a Meteor app.
1 Like
Hi Mike, yes I already looked weeks ago on the ThingStudio but have to do it again to see your improvements. Btw. looks overall very nice!
Tom
Hi @arunoda, thanks for your feedback.
Do you mean it is dead in case that you do not support it any more or is it dead in your eyes while you wouldn’t build it again (that way) with your todays knowledge?
Cheers, Tom
Hi Mike ( @mkarliner )
do you use a Mongo.Collection with upsert() or do you access (upsert) the local collection only within the client app?
I gave an example how I do it by now. This still works fine but I am not sure if as nice as yours.
In the next post you find just small examples for a server based ticker updating a client local (volatile) collection
Hi Tom,
What are some advantages and/or disadvantages of each approach you used for the meteorpad examples?
Updated meteorpads at post 11
Hi Donald,
to be honest I don’t know this by now. I just created some tests to get suitable and working options.
To know what appears to be best practise, I created this thread on Stack Exchange
Hopefully someone will help to point out.
Hi tom,
i’m working on something similar, with a lot connected devices. My suggestions:
-
Websockets are your friends. Also webrtc is a good tool. Operational transformations are another excellent tool. Each cover a slightly different scenario, with websockets focusing on compatibility and performance, webrtc on bandwidth efficiency and OT on consistency. Especially the OT are useful in the industrial sector, I suggest you give them a look before finding down the line that a race condition is breaking your software. Trust. Me. On. This.
-
If you have problem with performance I strongly suggest aggregating the data.
-
I suggest you drop the polling pattern, for a pub/sub pattern.
Hi @muaddib
thanks for your reply and your suggestions.
R1.) We do not have practical experiences with WebRTC but Sockets and OT are already used on our projects. My Cons to them in conjuction with meteor is just that we have a “different/another” channel between client and server and we have to control and audit that in addition. So I am trying to check if there is a (best) “meteor” friendly / aligned way.
R2.) Performance is not an issue yet
R3.) What do you mean by “drop the polling pattern” in my case? Did I wrote something about that? We are running the current project on a UDOO board which combines an ARM Cortex and an Arduino CPU on one board. There is no “networking” just serial line communication between the two devices. The Arduino part runs some self written real time software which handles the hardware independly and send ready records to the server process. On that we just have a SerialLine listener. For other “remote” devices we are very happy with MQTT (RabbitMQ) as transport mechanism also for latency and on/off situations.
I am assured by your note “each cover a slight different scenario” that for our use-case the local meteor collection shown in the meteorpads might a good and meteor friendly solution.
If you are interested Muaddib, I would really like to get more from your project and to exchange some knowledge with you.
Cheers
Tom
1 Like
first of all I’m dictating this to my phone on the train. I apologize in advance for all the mistakes I will make. But this topic really interest me.
second, i warn you that my advice are really general and might not be suited for your use case. take my advice with a grain of salt.
at first I didn’t click on the app link. now I think I got it better. basically you have several clients feeding data To the server, and a few clients consuming data from the server.
why you not use DDP client libraries? It’s native, redundant and fast.
IoT is really cool, but hardware adds a LOT of complexity. Why not use raspberry pi? It makes much more sense industrially speaking. It’s more stable, and libraries are much more optimized (which means that they are faster despite your weaker CPU). Plus in 10 years what do you think you will still be able to buy?
Pro tip: hardware producer are bound by the GPS License Agreement not to increase the precision of the system. you are not bound by such agreement. you can use 2 receivers to greatly increase the precision of the system
Feel free to drop me any question you have.
first of all I’m dictating this to my phone on the train. I apologize in advance for all the mistakes I will make. But this topic really interest me.
Great voice or voice recognition or both 
not much mistakes at your post.
second, i warn you that my advice are really general and might not be suited for your use case. take my advice with a grain of salt.
Yeah, for sure but thanks to remind that
why you not use DDP client libraries
At least that is my question, If you are looking at YukanOO Streamy package this is DDP. I am asking for pros and cons to use this instead of pub/sub with a local colllection.
One cons (as implemented by Yukan and MDG by now) are nasty debugging messages from meteor: see issue-4 and issue-5
IoT is really cool, but hardware adds a LOT of complexity.
Fully agree, especially in germany. We have much work to fullfill norms like CE, TĂśV and so on to be able to bring our product to market. This is something totally unknown for us in case that we just delivered software previously without those long terms.
But in the end you could create great complex but easy to handle products.
Why not use raspberry pi?
Why should I rely on Raspberry today? The UDOO and ODROID pieces are much more performant than a RasPi. At least we do not depend to any of them all. Wherever we got running our Linux Core image - we are on the scene.
you can use 2 receivers to greatly increase
Nice idea and tip, but this will raise our puchase price too much because we already have choosing a very good but expensive GPS module.
The solutions I proposed you are not DDP based. It boils down to how much data are you sending. If performance is not an issue, a collection should be fine. On the polar opposite you have websockets. You could write a C++ wrapper (many already exists) that simply pipe output to websocket, allowing you to use much less CPU. If you format the output correctly it shouldn’t be hard to debug either.
About TuV, since I’m Italian I know what you mean. Pro tip:
If you use already certified hardware and USB connections, then simply print a 3d case to encolose everything, you can get away just with a self-declaration of conformity, saving HUGE bucks.
About raspberry pi vs Udoo:
Let’s you need to get a full low voltage directive certification. It should cost AT LEAST 40k $ (but I bet it will easily double) if you use a german company.
Now you get a platform built on top of UDOO certfied. UDOO changes 2 years down the road. You just wasted a lot of money.
Instead the raspberry pi guys promise you that they will ship the SAME PCB 10 years down the road. It’s a nice plus.
About being faster: It’s not always better, it’s not always true. Optimization means a lot.
About Gps accuracy: If you have 4 cheap gps receivers on your boat you can use Desargues’ theorem and greatly increase the precision of your location.
Check this paper
http://2012.sensorapps.org/sites/default/files/uploads/1569519559.pdf
with 3 receiver you get an order of magnitude more precision (6 m to 0.6m). I think that if you put 4 receiver on a big boat, plus you use differential equations you can get down to 1 cm.
I think I found a new toy project 
