ESP8266 Community Forum

- Thu Jan 22, 2015 7:54 pm #7989 ...out of curiosity, luckily I am using an ESP-07 and stopped using GPIO 0 (index 3) and changed the PIR interrupt to another pin. All seems okay now. I still have my flag in place to favor PIR over temperature data, but it's been solid ever since. EDIT: not so solid, the module rebooted

Are you using ESP-01? ...just a thought, but maybe GPIO 0 is a NO NO? Wish I never bought ESP-01, but at least they are not ESP-05!!!


-Cheers!

- Thu Jan 22, 2015 8:57 pm #7992

Are you using ESP-01? ...just a thought, but maybe GPIO 0 is a NO NO? Wish I never bought ESP-01, but at least they are not ESP-05!!!

I'm using ESP-01 and Olimex MOD-WIFI-ESP8266-DEV, no difference in using GPIO0 or something else* with the NodeMCU firmware. The only thing to keep in mind is to pull GPIO0 high during reset (because low would start programming mode).

*except GPIO16, which is handled by node.led() and node.key() in NodeMCU

- Thu Jan 22, 2015 8:59 pm #7993 It seems that the problem of publishing on timer is a problem of non-blocking programming style like node JS. I am successfully to publish on timer using the attacted code. Plus, the code gives you automatic reconnect when the wi-fi access point is off and then turn back on. Please give it a try.

Code: Select allwifi.setmode(wifi.STATION)
wifi.sta.config("OpenWrt","")
print(wifi.sta.getip())



m = mqtt.Client("TT", 120, "user", "password")
m:lwt("/lwt", "TT", 0, 0)

m:on("offline", function(con)
     print ("Checking MQTT server...")
     connectionCheck()
     print(node.heap())
end)

-- on publish message receive event
m:on("message", function(conn, topic, data)
  print(topic .. ":" )
  if data ~= nil then
    print(data)
  end
end)



function disconn_cb()
     --print("TCP Disconnected")
     --tmr.stop(0)
     --tmr.stop(3)
     connectionCheck()
end


sf = 0
count = 0



function connectionCheck()
     tmr.stop(5)
     --tmr.stop(0)
     --tmr.stop(3)
     
     if wifi.sta.status() == 5 and wifi.sta.getip() ~= nil then
               --wifi.sta.connect()
               --print(wifi.sta.getip())
               tmr.alarm(0, 1000, 1, function()
                    tmr.stop(0)
                    m:connect("192.168.100.2", 1883, 0, function(conn)
                         print("connected")
                         --m:subscribe("/topic",0, function(conn)
                              m:publish("/topic","hello",0,0, function(conn) print("sent")
                                   tmr.alarm(3, 1000, 1, function()
                                        if sf == 0 then
                                             sf = 1
                                             m:publish("/topic","hello" .. tostring(count),0,0, function(conn)
                                             --print("sent2")
                                             sf = 0
                                             count = count+1
                                             end)
                                        end
                                   end)
                              end)
                         --end)
                    end)
               end)


          else
               tmr.alarm(5,1000,1,connectionCheck)
               print("Retry!!")   
     end
end

tmr.alarm(5,1000,1,connectionCheck)







- Sun Jan 25, 2015 11:19 pm #8221 Same issue here, PANIC: unprotected error in call to Lua API (mqtt.lua:18: sending in process)
Using the 20150124 NodeMCU with basic code (as shown in the first post)
In my case I can repro it by having it attempt to send two messages at roughly the same time. Any chance a queue of some sort could be implemented in the module?

I'm publishing dht temperature data every 45 seconds using a timer. I also have a PIR sensor that is interrupt driven to publish as well. At times they attempt to publish at the same time and I get "unprotected error in call to Lua API (pir.lua:34: sending in process)" and the module reboots.

I've added a flag to skip publishing dht data in favor of PIR motion, it helps, but reboot still happens. Seems like there should be a queue or something.

I ran into exactly the same problem - using some "poor man's semaphore" for now. It works quite ok. I also tried to implement a real queue, but then I get frequent reboots because out-of-heap.

Code: Select all-- publish status
function pub()
  sub=nil -- don't need than any more
  if inpub then
    tmr.alarm(4, 50, 0, pub)
    return
  end
  inpub = true
  m:publish("e44/conf/light/table/status", lsoft, 0, 1, function()
    m:publish("e44/conf/light/room/status", lhard, 0, 1, function()
      m:publish("e44/conf/light/shelf/status", lstudent, 0, 1, function()
        m:publish("e44/conf/temp/status", temp, 0, 0, function()
          print("PUB OK ", node.heap())
          inpub = false
        end) 
      end)
    end)
  end)   
end

-- publish button pressed
function button()
  if inpub then
    tmr.alarm(3, 60, 0, button)
    return
  end
  inpub = true
  m:publish("e44/conf/buttons/0", "1", 0, 0, function()
    inpub = false
  end)
end

inpub = false
tmr.alarm(0,1000,1,pub)

-- int on GPIO0 down
gpio.mode(3, gpio.INPUT, gpio.PULLUP)
gpio.trig(3, "down", function(level)
   button()
end)



I guess what we really need here is
1. some kind of queue in C, using less RAM
2. a more peaceful result of mqtt.publish(), e.g. false/true instead of raising a fatal error

Axel.