I am using an imp006 (600a0c2a69e60474) in a remote spot with variable cellular signal for no other purpose than to upload, as reliably and consistently as possible, 117 byte minutely UART binary packets from my sensor interface MCU to the internet. Power is not an issue and cellular data is not an issue. We don’t need minimalist efficiency; we just need maximum uptime and, most of all, NEVER needing to visit the site (hours away) for the sole purpose of a hardware reset.
I am very excited about the imp006 and the imp platform as I believe it may be able to serve this need better than my current Particle implementation of my sensor network (I am looking for a more stable solution).
I got excited about @hugo 's response to my other thread indicating the ConnectionManager library that has an exciting “stayConnected” parameter - looked like exactly what I needed. I need it to aggressively reconnect and use all the power and data it needs to have maximal uptime.
I am nervous that failure to properly comprehend all the documentation on ConnectionManager and server.setsendtimeoutpolicy has permanently disconnected my Imp006 until a manual power reset, by using "“errorPolicy”: RETURN_ON_ERROR "
The device went offline at 2am (8 hours ago) and hasn’t reconnected since, whereas my Particle Boron in the same spot (with however a much better cell antenna) has reconnected.
Here is my code:
#require “Serializer.class.nut:1.0.0”
#require “SPIFlashLogger.device.lib.nut:2.2.0”
#require “ConnectionManager.lib.nut:3.1.1”
#require “Messenger.lib.nut:0.2.0”
#require “ReplayMessenger.device.lib.nut:0.2.0”
cm <- ConnectionManager({
"startBehavior": CM_START_CONNECTED,
"blinkupBehavior": CM_BLINK_NEVER ,
"stayConnected": true,
"checkTimeout": 10,
"connectTimeout": 600.0,
"ackTimeout": 10.0,
"errorPolicy": RETURN_ON_ERROR
});
imp.setsendbuffersize(8096);
local sfl = SPIFlashLogger();
rm <- ReplayMessenger(sfl, cm, {"resendLimit": 900});
imp.setpowersave(false);
uart <- hardware.uartXEFGH;
lastPacket <- 0
function read_bytes(n)
{
local rx_buffer = blob(n);
local data
data = uart.read()
while (data != -1)
{
rx_buffer.writen(data,'b');
data = uart.read()
}
return rx_buffer;
}
server.log("start");
uart.setrxfifosize(117*20)
uart.configure(115200, 8, PARITY_NONE, 1, NO_TX | NO_CTSRTS | READ_READY);
local dBlob = blob(117)
function rob() {
dBlob = read_bytes(117)
dBlob.seek(0, 'b')
local tHeader = dBlob.readn(105)
if(tHeader > 1 && tHeader != 9999) {
if(lastPacket == 0 || tHeader != lastPacket) {
lastPacket = tHeader
//rm.send("0", dBlob, RM_IMPORTANCE_HIGH)
agent.send("RM_DATA", dBlob)
}
}
imp.wakeup(0.01, rob);
}
imp.net.getcellinfo(function(cellInfo) {
server.log(cellInfo)
});
server.log("Initialized")
imp.wakeup(0.01, rob);
I copied my ConnectionManager init code from someone else on these forums who seeemed to have a similar purpose.
I read the https://developer.electricimp.com/libraries/utilities/connectionmanager documentation, but it did not explain the “errorPolicy” SUSPEND_ON_ERROR/ RETURN_ON_ERROR difference.
Now, after I deployed the above code, I see that this is explained on a different article, with scary implications:
" . If RETURN_ON_ERROR is in effect, the only way for your imp to reconnect is to explicitly call server.connect() or server.connectwith() (impOS 42 and up)."
Unfortunately, I did not get this memo when I read exclusively the ConnectionManager library documentation. I had a strong assumption that the addition of the ConnectionManager library would manage the connection for me and make things better and not worse. Clearly, I should have read the documentation better.
Question: Will my imp006 ever reconnect, absent a manual intervention, given the code I deployed above? If not, the ConnectionManager documentation severely needs to be updated to not totally omit an explanation on “errorPolicy” causing this catastrophic outcome. Or, will impOS eventually reset my imp006 and allow me to flash new code?
Thank you for your help. While this is potentially very frustrating (device is 5 hours away), I am still hoping to evaluate the imp platform and, with the observation of its superior cellular stability to Particle, switch over my network eventually, and hopefully grow it with ElectricImp
