The new library version 1.40 is now published and available for download from the usual place https://chipchop.io/downloads/ChipChop_Arduino_Library.zip
This was not just a minor update to the library but also an update to the main engine that has been propagated last night across all servers (I was almost considering releasing it as vs 2.0)
You can still use it with your existing code, everything is cross compatible but I will give you examples where you can modify your code to benefit from the new engine.
Major changes: Quick IntroThe main focus was to improve the chances of delivery when using fast events like triggerEvent(). With the introduction of Notifications some users have started firing triggerEvents more often and it has become noticeable that in some cases network conditions (your ISP and various other networks & servers that the data packets have to travel) were causing important events to be refused by the ChipChop engine if their timing was wrong.
So the new engine will be a lot more forgiving and instead of issuing penalties and closing connections it will try to work with you and to help you. A new routine called "Connection Watch" is now constantly monitoring every device connection and will inform you if it detects irregularities and even send instructions to the library to attempt reconnections and other things.
This doesn't mean that you can be reckless and not care how you handle your events. It is understandable that we all make mistakes and a small error in the code logic can produce big problems so I don't want anyone to be penalised for that, but also the Connection Watch is not there for only you ! ;-)
-
ChipChop.requestRate(int milliseconds) (default 510)
The biggest change is how the library handles events, it runs a constant "pulse" that keeps the space between events as accurate as possible. This completely removes the need for using any timers trying to keep triggerEvents going too fast.
You can simply call a triggerEvent() from anywhere in your code even multiple times one after another and the library will still send them in a correct time.
The only thing you need to watch is that you don't runout of available event in the allocated 60sec slot.
Technically you don't have to use this functionality but there are tricks where it can be extremely useful and I will be happy to give you examples, just ask if you are interested.
-
ChipChop.keepAlive(int mode, int timeout) This simple looking function does a lot of things in the background for you. Its job is to fight to death to keep your connection with ChipChop going. Again, it's completely optional but has already proven in some of my tests that could get you out of a sticky situation .
It takes two parameters "mode" and "timeout":
-
Mode (0,1,2)
0 - simply disables the keepAlive if it's being activated
1 - if a loss of connection is detected and can not be re-established (the re-connect routine runs every 15 seconds) the keepAlive will attempt at ditching the entire WebSockets from the chip's memory, reloading them and trying to reconnect
2 - this is only available on ESP chips - if a loss of connection is detected and can not be re-established, keepAlive will restart the ESP. It is an aggressive mode but can help in poor or unstable WiFi signal areas where on the restart the ESPs modem gets a bit of power boost and may catch a better channel.
-
Timeout in milliseconds, default 120000 (2 minutes)
This is the timeout after which you think that the re-connects have become pointless and will kickstart the keepAlive routine. I don't know if 2 minutes is a bit too low, let me know and I can increase the default in the next library update.
-
heartBeatInterval() - after a very observant user has spotted a typo, this is now correctly named as it used to be
hearBeatInterval() (missing a "t" in the "heart" ;-) . You really only need to use it if you want to maybe save a little bit of power by sending heartbeats less frequently. For example an ESP will use around 200ma when sending but around half of that if just receiving.
-
ChipChop.restart() - manual way of triggering the keepAlive() routine, the keepAlive has to be active.
Here is an example how you can structure your code to take advantage of the new library:
1. Always start by telling the library the starting state of all your components
void setup(){
ChipChop.updateStatus("led",led_status);
}
2. if you've done the above in the setup(), then instead of doing this:
//don't need to do it this way
void loop(){
ChipChop.run();
if ((millis() - loopCycle) > 10000){
if(WiFi.status() == WL_CONNECTED){
ChipChop.updateStatus("led",led_status);
}
loopCycle = millis();
}
}
just do this:
// do it like this
void setup(){
ChipChop.updateStatus("led",led_status);
}
void loop(){
ChipChop.run();
}
Notifications This is how you can handle triggerEvents to control notifications
void loop(){
ChipChop.run();
if(something_happened == true){
ChipChop.triggerEvent("notification","trigger word");
ChipChop.updateStatus("notification","non-trigger word");
}
}
Multiple Trigger Events You can now safely do stuff like this
void loop(){
ChipChop.run();
if(motion_detected == true){
ChipChop.triggerEvent("motion_sensor","DETECTED");
ChipChop.triggerEvent("motion_sensor","DETECTED");
ChipChop.triggerEvent("motion_sensor","DETECTED");
ChipChop.triggerEvent("motion_sensor","DETECTED");
...
}
}
I will post more examples or if you have something specific just ask
Enjoy 😃🤟