This has been discussed before but I can’t wrap my head around it. After several hours, my imp goes from online=>offline and I have to cycle power to get it back.
I cannot understand the past discussions about: server.setsendtimeoutpolicy
I’m not sure why I can’t understand it, but I don’t know what code to insert into the imp code and where to insert it.
In the past (before agents), I think we just used something like this: function watchdog() { imp.wakeup(5*60, watchdog); }
watchdog();
Now that we use agents, that won’t work anymore? Is that correct?
There has to be something else to keep communication between imp and agent ?
So, in comes “server.setsendtimeoutpolicy”.
Looking at the previous mess of posts that all seem to have different answers (or methods used), I am assuming I put this in my imp device code: const TIMEOUT = 10;
server.setsendtimeoutpolicy(RETURN_ON_ERROR, WAIT_TIL_SENT, TIMEOUT);
Is that correct? and if not, what else has to happen?
Sorry for rehashing this all over again, but with the lack of good tutorials and working examples, I’m just lost here. I hope I’m not the only one that can’t “get it”.
You do not have to do anything to keep the link up; the watchdog thing was to work around an issue in release17 which was fixed soon after.
server.settimeoutpolicy deals with how the imp deals with connection loss (eg allowing you to continue to run code when wifi goes away vs the imp waiting for wifi to return).
Using the policy you quoted will make the imp not attempt to reconnect. When the link is lost (can be for many reasons including NAT timeouts) the imp will just start returning errors from any call that requires wifi to be up (if you have an onunexpecteddisconnect handler installed, that will get called though, and you can manually issue a reconnect there).
This is likely not what you want - you probably want to just leave the default policy in place, which does attempt to reconnect.
More info on what your code is doing, and whether you can replicate the issue with a simple imp.configure() line as the only code on the imp, would be helpful.
During the night (last night), it did not go offline. But it has the previous two nights.
The Agent:
http.onrequest(function(req, resp){ if (req.method == "POST"){ local body = http.urldecode(req.body); server.log(body.data); device.send("data", body.data); } resp.send(200, "OK"); });
The device:
`// UART Communication to TI SN74LV8153 Serial to Parallel Chip
function writeSerial(value) {
local newvalue=value ^ mask;
if(value==00){
newvalue=00;
}
hardware.pin9.write(0);
local outputs = newvalue;
local address = 0x00; // write to address 0 chip
// Send serial data to TI chip
hardware.uart12.write(format("%c%c", 0x01 | (address <<1) | (outputs & 0x0f) <<4, 0x01 | (address <<1) | (outputs & 0xf0)));
server.log(“data sent”);
hardware.pin9.write(1);
mask=newvalue;
}
// Convert hex string to an integer
function hexToInteger(hex){
local result = 0;
local shift = hex.len() * 4;
// For each digit..
for(local d=0; d<hex.len(); d++) {
local digit;
// Convert from ASCII Hex to integer
if(hex[d] >= 0x61)
digit = hex[d] - 0x57;
else if(hex[d] >= 0x41)
digit = hex[d] - 0x37;
else
digit = hex[d] - 0x30;
// Accumulate digit
shift -= 4;
result += digit << shift;
}
return result;
}
// pin9 is an LED blip indicator whenever data is sent to TI chip
hardware.pin9.configure(DIGITAL_OUT);
hardware.uart12.configure(19200, 8, PARITY_NONE, 1, NO_CTSRTS);
mask <- 00;
agent.on(“data”, function(value) {
value=hexToInteger(value);
writeSerial(value);
});
writeSerial(00);`
An interesting note … my old imps had the words “developer edition” on them. My new imps do not have that. This problem never happened with my old imps, but then again, I had not been using the agents very much.
So now, this offline thing happens intermittently, at unpredictable times. At first I thought maybe it happens after 12 hours of sitting there without any activity. Last night, it happened 2 hours after being used.
The developer/non developer imps are identical - the only difference is the laser etch.
The issue is certainly some local network condition that somehow we’re not managing to detect (and hence recover from) these are hard to debug because, well, we’re not at your house
The issue is definitely not universal; I have imps that have been online for months, only interrupted by firmware updates as they’re released, both at home and at the office.
Any more detail you can give, eg signal strength (RSSI)? We have seen issues with overly strong signals (higher than -20dBm).
The location is just outside the house … within 24 feet, through two walls and outside wall. With my laptop in the same place, I’m getting good signal. The imp is close to 120vac power by about 2 inches. I’ll move things apart as a test.
I’m powering the imp/april with a 6vdc wall-wart transformer.
The serial to parallel using the TI chip is working flawlessly. This is the same project described on another thread. Your serial stream of bits example that you gave me saved the day … thanks again.
I’ll find something that will give me an ‘aha’ moment … hopefully.
Closeness to an AC power supply shouldn’t be an issue, but the wall-wart worries me a little. You should probably have a bigish bulk capacitor on the input of the imp - maybe 100uF+ - due to the inductance of the wire from the supply. The april has a switching supply with a fairly small input capacitor on it.
24 feet through two walls is definitely not going to be too strong a signal unless your antenna is a parabolic dish pointed at the imp
Hugo,
5 days now since I added a large filter capacitor at the incoming 6vdc wall-wart power supply going to my imp & TI chip. No offline yet. Working perfectly. I don’t want to jinx it, but it’s looking good. Nice call on the capacitor … thanks.
What is on Pin1? I’ve heard that you need to be actively driving it or have a pull down resistor on pin1. Is that just a rumor or is it needed?
I would definitely recommend bypass caps but I also agree with @302tt that ideally you should be able to see the bad behavior come back if you take them off or else we don’t know if its the true fix.
I’m in the processes of putting the Christmas lights project together now, so I’ll wait until after Christmas to experiment with the filter caps. I’m quite sure that was the problem, but I’ll confirm it later. My Pin 1 is the UART12 TX pin. It is connected directly to the TI chip serial-in. All of this pertaining to my project that I posted on Instructables:
