I have the firebase SDK integrated in my system and is taking live traffic now.
I`m basically using FCM for sending simple DataMessages to the app.
We are seeing inconsistency in the time taken for the ping to reach the device, for instance 3 pings are sent for 3 consecutive update actions out of which 2 pings were received immediately, but the third one took around 5 minutes to reach the device.
Do we have a control on the SLA of a firebase ping, can we fine tune and reduce the delay in recieving the Firebase pings on the app?
Related
I'm trying to send data from multiple ESP-8266 to feeds on my Adafruit IO account.
The problem is that when I try to send new values, I'm faced with a ban from publishing because the 2 seconds time limit is violated when two or more of my MCUs happen to send data at the same time (I can't synchronize them to avoid this).
is there any possible solution to this problem?
I suggest to consider those three options:
A sending token which is send from one ESp to the next. So basically all ESPs are mot allowed to send. If the token is received its allowed to send - waits the appropriate time limit hands the token to the next ESP. This solution has all Arduinos connected via an AP/router and would use client to client communication. It can be setup fail safe, so if the next ESP is not available (reset/out of battery etc) you take the next on the list and issue an additional warning to the server
The second solution could be (more flexible and dynamic BUT SPO - single point of failure) to set up one ESP as data collector to do the sending.
If the ESps are in different locations you have to set them up that they meet the following requirement:
If you have a free Adafruit IO Account, the rate limit is 30 data
points per minute.
If you exceed this limit, a notice will be sent to the
{username}/throttle MQTT topic. You can subscribe to the topic if you
wish to know when the Adafruit IO rate limit has been exceeded for
your user account. This limit applies to all Data record modification
actions over the HTTP and MQTT APIs, so if you have multiple devices
or clients publishing data, be sure to delay their updates enough that
the total rate is below your account limit.
so its not 2 sec limit but 30/min (60/min if pro) so you limit sending each ESP to the formula:
30 / Number of ESPs sending to I/O -> 30 / 5 = 6 ==> 5 incl. saftey margin
means each ESP is within a minute only allowed to send 5 times. Important if the 5 times send limit is up it HAS to wait a minute before the next send.
The answer is simple, just don't send that frequent.
In the IoT world
If data need frequent update (such as motor/servo, accelerometer, etc.), it is often that you'd want to keep it local and won't want/need to send it to the cloud.
If the data need to be in the cloud, it is often not necessary need to be updated so frequently (such as temperature/humidity).
Alternatively, if you still think that your data is so critical that need to be updated so frequently, dedicate one ESP as your Edge Gateway to collect the data from sensor nodes, and send it to the cloud at once, that actually the proper way of an IoT network design with multiple sensor nodes.
If that still doesn't work for you, you still have the choice of pay for the premium service to raise the rate limit, or build your own cloud service and integrate it with your Edge Gateway.
We have an already running MQTT setup for communication between smart home devices and remote server, for remotely controlling the devices. Now we want to integrate our devices with Google Home and Alexa. These two use HTTP for communication with third party device clouds.
I have implemented this for Google Home and after receiving the request to device cloud, the request is converted to MQTT. This MQTT request is then sent to smart home device. The device cloud waits for few seconds to receive reply from smart home device. If no reply is received within predefined time, it then sends failure HTTP response to Google Home else it sends the received reply.
Is there a better way to handle this? Since this is a commercial project I want to get this implemented in the correct way.
Any help will be appreciated.
Thanks
We're using AWS IoT and I think it's a good way to handle IoT issues, below are some features of it:
Certification, each device is a thing and attached its own policy, it's security
Shadow, it's device's current state JSON document, The Device Shadow service acts as an intermediary, allowing devices and
applications to retrieve and update a device's shadow
Serverless, we use lambda to build skill and servers, it's flexible
Rule, we use it to intercept MQTT messages so that we can report device's state changing to Google and Alexa. BTW, to Google, Report State implementation has become mandatory for all partners launch & certify.
You can choose either MQTT or HTTP
It’s time-consuming but totally worth it! We've sold 8k+ products, so far so good.
At least Google Home doesn't really require synchronous operation there. Once you get the EXECUTE-intent via their API, you just need to sent that to your device (but it doesn't necessarily has to report its state back).
Once its state changes, you either store it for further QUERY-intents or provide this data to the Google Homegraph server using the "Report State" interface.
I'm developing gBridge.io as a project providing quite similar functionality (but for another target group). There, it is strictly split as described: A HTTP endpoint listener reacts to commands from Google Home and sends it to a cache, where it is eventually sent to the matching MQTT topic. Another worker is listening to MQTT topics from the users and storing there information in the cache, so it can be sent back to Google once required.
I am practicing a group chat app using django channels and nginx. The problem is if I do a stress test like 300 users will send messages between 2-4 seconds within 2 minutes. The tab that has our web app will hang. How can I prevent this? Will nginx's gzip help?
So from my understanding you send around 100 messages per sec during 2 mins.
The main 2 things here that can lead to CPU overload are:
Very intense network traffic
Heavy JavaScript code that renders all these messages
So you need to check both of them
For example, you can start by checking JavaScript part. Try to disable a code that shows all incoming messages in UI, so only network part will be active. See how it works. If it works good now, then you need to optimize this JavaScript part, maybe collect incoming messages in memory and show messages in UI each 3 seconds instead of each 100/1 seconds. This will save your rendering power.
Regarding network part - you can try to optimize a message payload - make it smaller.
We have an app (Ruby on Rails) that sends push notifications to an android app and we're facing an issue with GCM where some of these notifications are either delayed or never received. Considering the fact that these notifications are being sent to employees and not end-users my questions is:
What the best way to send these push notifications without any delay or drop and is there a way to send push notifications independently from the available services such as GCM and SNS?
Please keep in mind that we're looking for a solutions that can send these notifications without any delay as for the app to perform well the notification must be received within 1 to 20 seconds from the time it was sent.
Thanks in advance for anyone that will reply to this question...
Have a look at "Pushy":
They state the following on their website:
The most reliable push notification gateway, perfect for real-time
applications.
Google Cloud Messaging simply doesn't cut it for time-sensitive,
real-time apps, due to its instability and push notification
throttling.
Pushy works by maintaining a dedicated background socket connection
using the MQTT protocol, an extremely light-weight pub/sub protocol
that consumes very little network bandwidth and battery, which makes
it perfect for mobile.
You can use it for free with up to 100 devices, so you could just give it a try to see, if it fits your needs. I didn't try it.
I'm testing my Android app in dev environment with UrbanAirship as push notifications provider. Sometimes after sending several pushes (let's say I receive 3 or 4), they just stop arriving I don't know what happens with the other pushes I sent (5 or 6 more).
I send all pushes via console, not using Urban Airship web forms for testing pushes.
I've tried closing the app and reopening it and nothing happens. Just when I restart my device then all the pending messages arrive at once.
Could you please tell me how to avoid this?