Hi Bruck,
I'll try to explain this as simple as I can but apologies if I end up writing a whole book 😇
Heartbeat
It's pretty much as the name implies the "pulse" of your device and it serves multiple purposes.
- It should be at a regular and known interval
- It enables you to see the state of your device and its components within the last 10 seconds
- Can be slower, for example if you have a battery powered device to save power juice you may want to send a heartbeat once per hour or day or week
- It's monitored by the ChipChop Connection Watch and if it becomes irregular it can inform you that your connection is not stable
- It's used to trigger Actions
- It's used to send the state of your device to Alexa when you are interacting with the device through the Alexa app
Request Rate
This one is a bit trickier to explain and it's to do with trigger events. Trigger events can be sent at any time and they don't have to be regular. You can send quick bursts at up to 500ms between the events but the limit is as you know a maximum of 10 events per minute so if you start sending at 500ms you will run out of allocated events in 5 seconds.
This was a bit of a problem for many users to code the logic that will allow this quick burst but at the same time to try and "spread" somehow those events across a minute so they don't run out (there is one post here about the issue with the postman keeping the doorbell pressed like a lunatic :-)
And also it was a problem ensuring that you don't go faster than 500ms to avoid getting system violations and sometimes getting your device temporarily banned by ChipChop.
Before the library 1.41 there was only a built in mechanism to stop you exceeding the 10 events per minute but people were still getting system violations.
From vs 1.41 I have introduced the requestRate(ms) that ensures that the events are evenly spread apart at the specified rate regardless ow quickly you try to send them. This was an adventure to code but it's extremely useful and helps with many things.
For example, if you set the requestRate(6000) then if your postman keeps their finger on the doorbell permanently you will still get all events (1 every 6 seconds) and never run out of them per minute and never exceed the speed.
Send Rate
From the introduction of the Code Builder there were some additional improvements to the ChipChop server side of things so internally the library (currently vs 1.4x) now creates a "pulse", it's a regular beat that coordinates both the triggerEvents and the heartbeat automatically and that's why I've renamed it to Send Rate as that's what it actually is.
All that can still be tweaked manually by modifying the library code even if it's from Code Builder but I wouldn't recommend it as it's all finely tuned based on real life usage experience.
Finally, as I've been asked this many times here is the explanation on why is the maximum sending rate set at 500ms.
This is purely based on real life observations, there are two factors that affect the quality of your IoT device communication and they are latency and network congestion
1. Latency
Depending how far your device is physically from your ChipChop API server it takes time for the data packets to reach it, if we ignore the time it takes ChipChop to process the request (it's usually sub millisecond) it still takes the same amount of time to send a confirmation back {status:"ok", timestamp:xxxx}. That for some users can be even 200-300 milliseconds round trip.
2. Network
Now if we add into the mix the quality of the network which is not just your connections with your ISP but all the wires and servers the data has to travel through, the requests don't arrive spaced at the same interval as you have sent them.
Often you will have 2-3 requests coming very close or almost simultaneously and then some empty space and so on, in some instances I have noticed heartbeats that I know were sent at 10sec apart arrive 3 in 15 seconds then 20 seconds gap then at 10 sec ...basically all over the place.
ChipChop is trying to make sense out of all that chaos and coordinate things as best as possible and 500ms is probably the minimum that provides some sense of stability and continuity.
So the 500ms is not just some arbitrary number picked at random but rather the optimum that works for most cases.
Hope I didn't bore you to death reading this , shout if you need more details 🙃