Multiple get requests result in crash and reboot sometimes
Posted: Sat Nov 28, 2015 2:18 pmHi, I'm working on a "smart dinrail" that listens to some commands on Thingspeak via Talkback, see the prototype:
http://www.proofofprinciple.nl/index.php/smart-din
Everything just works fine except that randomly the module crashes and reboots.... The Lua script consists of two timers who requests every 2 seconds the command state, see:
Then there is another timer which reads the VARs and determine the GPIO state for the relays. Also there are two timers who will check if a state is changed, and if so, it will sent a push notification to smartphone via the Prowl API:
Sometimes it will run stable for hours, but otherwise it crashes multiple times a hour. Is this code to much for the ESP Soc? Is the code structure OK? I tried also logging the Heap size, but I'm not sure it's a heap size related issue.... Also I don't think it's a hardware issue, pcb layout is OK, there is a 100uF and 100nF ceramic cap near the Vcc pin of the module. What can be wrong?
http://www.proofofprinciple.nl/index.php/smart-dinEverything just works fine except that randomly the module crashes and reboots.... The Lua script consists of two timers who requests every 2 seconds the command state, see:
Code: Select all
tmr.alarm(0,2000,1,function ()
conn = nil
conn = net.createConnection(net.TCP, 0)
conn:connect(80,cloud)
conn:on("connection",
function(conn)
conn:send("GET /talkbacks/" ..TalkbackID .."/commands/" ..CmdIDr1 .."?api_key=" ..api .."\n\n")
end)
conn:on("receive",
function(conn, payload)
relay_a = payload
conn:close()
end)
conn:on("disconnection",
function(conn)
end)
end)
tmr.alarm(1,2500,1,function ()
conn = nil
conn = net.createConnection(net.TCP, 0)
conn:connect(80,cloud)
conn:on("connection",
function(conn)
conn:send("GET /talkbacks/" ..TalkbackID .."/commands/" ..CmdIDr2 .."?api_key=" ..api .."\n\n")
end)
conn:on("receive",
function(conn, payload)
relay_b = payload
conn:close()
end)
conn:on("disconnection",
function(conn)
end)
end)
Then there is another timer which reads the VARs and determine the GPIO state for the relays. Also there are two timers who will check if a state is changed, and if so, it will sent a push notification to smartphone via the Prowl API:
Code: Select all
tmr.alarm(2,2100,1,function ()
if(relay_a ~= nil) then
if(relay_a=="ON") then
gpio.write(1, gpio.HIGH)
gpio.write(6, gpio.HIGH)
else
gpio.write(1, gpio.LOW)
gpio.write(6, gpio.LOW)
end
end
if(relay_b ~= nil) then
if(relay_b=="ON") then
gpio.write(2, gpio.HIGH)
gpio.write(5, gpio.HIGH)
else
gpio.write(2, gpio.LOW)
gpio.write(5, gpio.LOW)
end
end
end )
tmr.alarm(3,2200,1,function ()
if(relay_a~=nil) then
if(prev_relay_a=="") then
prev_relay_a=relay_a
end
if(prev_relay_a~=relay_a) then
con=nil
conn=net.createConnection(net.TCP, false)
conn:on("receive", function(conn, pl) end)
conn:connect(80, "209.20.89.148")
conn:send("GET /publicapi/add?apikey=" ..ProwlAPI .."&application=SmartDIN&event=State+relay+A&description=" ..relay_a .."&priority=0 HTTP/1.1\r\n")
conn:send("Host: prowl.weks.net\r\n")
conn:send("Accept: */*\r\n")
conn:send("User-Agent: Mozilla/4.0 (compatible; esp8266 Lua; Windows NT 5.1)\r\n")
conn:send("\r\n")
prev_relay_a = relay_a
con=nil
end
end
end )
tmr.alarm(4,2300,1,function ()
if(relay_b~=nil) then
if(prev_relay_b=="") then
prev_relay_b=relay_b
end
if(prev_relay_b~=relay_b) then
con=nil
conn=net.createConnection(net.TCP, false)
conn:on("receive", function(conn, pl) end)
conn:connect(80, "209.20.89.148")
conn:send("GET /publicapi/add?apikey=" ..ProwlAPI .."&application=SmartDIN&event=State+relay+B&description=" ..relay_b .."&priority=0 HTTP/1.1\r\n")
conn:send("Host: prowl.weks.net\r\n")
conn:send("Accept: */*\r\n")
conn:send("User-Agent: Mozilla/4.0 (compatible; esp8266 Lua; Windows NT 5.1)\r\n")
conn:send("\r\n")
prev_relay_b = relay_b
con=nil
end
end
end )
Sometimes it will run stable for hours, but otherwise it crashes multiple times a hour. Is this code to much for the ESP Soc? Is the code structure OK? I tried also logging the Heap size, but I'm not sure it's a heap size related issue.... Also I don't think it's a hardware issue, pcb layout is OK, there is a 100uF and 100nF ceramic cap near the Vcc pin of the module. What can be wrong?