We are currently building a device that can run in either online or offline mode and I wanted to confirm a few things about offline mode. The general gist of what the device does is as follows:
Online: retrieve API data, move some servos Offline: send a message over UART to a SIM800 to retrieve that same API data from the agent
We are shipping these devices to different clients, some of them having networks the devices can not connect to. This is why the SIM800 was added onto the board, so we could retrieve data independent of WIFI.
For the offline devices I am wondering what setup is needed to make sure the Imp operates with no WIFI. Would something along the lines of this be the right path? Taken from https://electricimp.com/docs/api/server/connect/
function connectCallback(state) {
// If we’re connected…
if (state == SERVER_CONNECTED) {
// do not use the SIM800 for data retrieval
} else if (state == SERVER_DISCONNECTED) {
// no wifi, start polling from the SIM800
}
}
function connect(callback, timeout) {
if (server.isconnected()) {
// We’re already connected, so execute the callback
callback(SERVER_CONNECTED);
} else {
// Otherwise, proceed as normal
callback(SERVER_DISCONNECTED);
}
}
You should note that if the device doesn’t connect in 30 days, the agent will be stopped - so though imps can operate offline, the agent won’t live forever. All server.save() storage is kept though, and the agent will be restarted the instant the imp is seen online again.
Sometimes the imp isn’t going to be the best choice for control. There are other devices that control, use WiFi, and don’t require a cloud/agent. Those other devices will take more time to develop, build, program, etc, but if you have your own website, dedicated server, maybe you could host your own API “cloud” for your family of controlled devices. Example, the ESP8266 paired with another micro-controller. You need to explore all of your options.
Another thought is devices that have SIM cards that use a cellphone data plan. Those devices communicate without WiFi … example, medical devices that people use in their homes. They send data back to the doctors for evaluation. They can be used anywhere that have cellphone service.
@Hugo thanks for that note I was not aware of that previously.
@mlseim totally agree with those points. Unfortunately late in the process we decided having cell data was needed. In most cases the devices will operate strictly on WIFI but we wanted to have cell data for a backup.
Still having issues with this, hoping someone has some advice. When I run the same set of commands to send and receive a text message when the device is on wifi it works. When I clear the wifi config and turn on the device it does not execute the offline code. I can easily see if it is working because my Agent code will still log the received text message. Currently this is my boot code:
`server.setsendtimeoutpolicy(RETURN_ON_ERROR, WAIT_FOR_ACK, 15)
local connectAttempts = 0
// connect and boot functions
function onConnectedCallback(state) {
if (state == SERVER_CONNECTED) {
server.log("On wifi")
// disable fona
fonaEngage.write(1)
} else {
// drive it low to enable the FONA
fonaEngage.write(0)
// turn on the FONA
fonaKey.write(1)
imp.sleep(2.0)
fonaKey.write(0)
// poll the fona in a few seconds
// this is my crucial function
imp.wakeup(20.0, pollFona)
}
}
function connect(callback, timeout) {
if (server.isconnected()) {
// We're already connected, so execute the callback
callback(SERVER_CONNECTED)
} else {
if (connectAttempts < 3) {
server.connect(callback, timeout)
connectAttempts++
} else {
callback(reason)
}
}
}
connect(onConnectedCallback, 15)`
What I need to have happen is for the imp.wakeup(20.0, pollFona) to run so it can retrieve the given info via text. Anyone have any ideas what would be going on here? It seems as if the else statement in the onConnectedCallback function never gets run. I can text the endpoint while all this is going on to verify it logs and sends data.
Looks like you have a bug in your connect() function - after 3 connect attempts (presuming the code that you have not shown here actually does queue another connecte attempt - the code here doesn’t do that) then you fall into a clause that says “callback(reason)” - but “reason” does not exist.
This would result in the imp going back to SUSPEND_ON_ERROR mode as it tries to report the error to the server.