New release 1.43.6 for ESP32

Here you'll find the updated available
User avatar
cicciocb
Site Admin
Posts: 1900
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 407 times
Been thanked: 1271 times
Contact:

Re: New release 1.43.6 for ESP32

Post by cicciocb »

Depends on what your program does.
Do you put the wifi on sleep?
User avatar
Electroguard
Posts: 836
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 268 times
Been thanked: 317 times

Re: New release 1.43.6 for ESP32

Post by Electroguard »

Nope, it just scans for ble devices same as before, sending output to tft only - no mention of wifi for this.
Only difference is it displays clock and elapsed timer, plus shows coldest outside temp with the time.

The update hasn't yet hung, and I thought everything was good... until I noticed that although the clock and elapsed time still kept going, the actual gizmo values being displayed were not what was currently being sent by the gizmo's and had stopped being updated hours previously, even though the script was apparently still regularly acknowledging ble scans from the known gizmo ID's. Still loads of ramfree, and no accumulating text strings used in the script... so it's as if an Annex ble 'system' string is reaching max after a few hours and is unaware that it's not accepting new data and just keeps giving out the same old data.
User avatar
cicciocb
Site Admin
Posts: 1900
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 407 times
Been thanked: 1271 times
Contact:

Re: New release 1.43.6 for ESP32

Post by cicciocb »

Post your program, I'll give an eye.
I cannot reproduce your problem
User avatar
Electroguard
Posts: 836
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 268 times
Been thanked: 317 times

Re: New release 1.43.6 for ESP32

Post by Electroguard »

You can enter your own gizmo ID's and names into sensosr$
When the script is RUN it populates the appropriate sensor fields after getting the results of a ble scan, and displays the working free mem top right.
The initial higher startup free mem is shown top left as a reminder, but touching top left a bit later when things have settled down will populate the top left 'reminder' with the current working free mem for a more realistic subsequent comparison.
Bottom left is clock, bottom right is elapsed time since RUN.

The main purpose was to check overnight reliability.
But after startup and AFTER the results of the first ble scan, STOP the program always causes browser disconnect.
It will stop ok prior to the ble scan, but always disconnects when stopped after ble scan.

Gizmo results seem to be ok for several hours, but are wrong when looked at next morning.

Edit: Removed unnecessary and added elapsed time of last received gizmo update at bottom middle.

Code: [Local Link Removed for Guests]

option.wdt 0
debuglevel=0  '0=don't wlog BLE devices (normal), 2,3,4 wlog various debug info
sensors$ = "ATC_9AFEA8.Data=Inside ATC_BEF7AB.Data=Outside abc=Freezer"   'list of sensor ID=name pairs
records=1     '0=don't save records, 1=save max and min recod values
tft=1         '0=disable tft display output, 1=enable tft display output
ram=1         '0=isable Ramfree tft display
'rtc=0 
xres=320:yres=240
'xres=480:yres=320
'touch.calib
'---- User variables are above 
lastupdate$="_"
sensors=word.count(sensors$," ")
wlog "Looking for "+str$(sensors)+" sensors"
dim info$(sensors): dim id$(sensors): dim name$(sensors): dim temp$(sensors): dim hum$(sensors): dim batt$(sensors): dim cnt$(sensors)
if records=1 then dim coldest$(sensors): dim whencoldest$(sensors): dim warmest$(sensors): dim whenwarmest$(sensors): dim ctm$(sensors) 
for sensor=1 to sensors
 info$ = trim$(word$(sensors$,sensor," "))
 if debuglevel=4 then wlog info$
 id$(sensor) = word$(info$,1,"=")
 name$(sensor) = word$(info$,2,"=")
 temp$(sensor) = str$(sensor)
 hum$(sensor) = "xx"
 batt$(sensor) = "xx"
 cnt$(sensor) = ""
 ctm$(sensor) = ""
 if records=1 then 
  coldest$(sensor) = "": whencoldest$(sensor) = "" 
  warmest$(sensor) = "": whenwarmest$(sensor) = ""  
 endif
next sensor
t$=time$
rf=0
startup=timeunix(t$)
runtime=timeunix(t$)
if tft=1 then gosub tftpage
onbluetooth ble_receive
bluetooth.scan 10
timer0 1000,clock
wait


clock:
t$=time$
runtime=timeunix(t$)-startup
if tft=1 then
 gui.settext clk, t$
 gui.settext rtm, unixtime$(runtime)
endif
return

tftpage:
gui.init 10, 0 
gui.autorefresh 100, 1    
x=0:y=2:w=100:h=30:m=10:c=(xres/2)-(w/2):f=4
clk=gui.textline(x,yres-h,w,h, time$,f,white,black,0,3,0)
lu =gui.textline((xres/2)-(w/2),yres-h,w,h,lastupdate$,f,green,black,0,4,0) 
rtm=gui.textline(xres-w,yres-h,w,h, t$,f,orange,black,0,5,0)
y=45
s1=gui.textline(x,y,xres,h,name$(1),f,black,cyan,white,4,0)
y=y+h+m
if sensors >= 2 then s2=gui.textline(x,y,xres,h,name$(2),f,black,cyan,white,4,0)
y=y+h+m
if sensors >= 3 then s3=gui.textline(x,y,xres,h,name$(3),f,black,cyan,white,4,0)
y=y+(h+m)
x$=coldest$(2)+" at "+whencoldest$(2)
if records=1 then col=gui.textline(x,y,xres,h,x$,f,blue,black,0,4,0)
if ram=1 then 
 y=2
 nrm=gui.button(x,y,w,h, str$(ramfree),f,0,0,1,cyan,black,red,0)
 mem=gui.textline(xres-w,y,w,h, str$(ramfree),f,yellow,black,0,5,0)
 gui.setevent nrm,1,saveram
endif
return

saveram:
gui.settext nrm,str$(rf)
return

showit:
if tft=1 then
 if sensor=1 then gui.settext s1,info$(1)
 if sensor=2 then gui.settext s2,info$(2)
 if sensor=3 then gui.settext s3,info$(3)
 gui.settext lu,lastupdate$
 if records=1 then gui.settext col,coldest$(2)+" at "+whencoldest$(2)
 if ram=1 then  rf=ramfree: gui.settext mem,str$(rf) 
endif
return

ble_receive:
select case bluetooth.status
case 1: wlog "BLE Device Connected"
case 2: wlog "BLE Device Disconnected"
case 3:
 bluetooth.read_iobuff(0)
 for z = 1 to iobuff.len(0)
  print iobuff.read(0, z-1),
 next z
case 4:
 print "scan terminated"
 a$ = bluetooth.scanresult$
 if debuglevel = 3 then wlog a$: end select: bluetooth.scan 10: return
 for sensor=1 to sensors  
  info$(sensor)=json$(a$, id$(sensor))
  if debuglevel = 1 then wlog "Sensor="; str$(sensor), info$(sensor) 
  if info$(sensor)  = "not found" then
   info$(sensor)=name$(sensor)+" not found"
  else
   a = iobuff.fromhex(0, info$(sensor))
   temp = iobuff.read(0, 6) * 256 + iobuff.read(0, 7)
   if (temp > 32767) then temp =  temp - 65536
   temp$(sensor) = str$(temp/10)
   hum$(sensor) =  str$(iobuff.read(0, 8))
   batt$(sensor) = str$(iobuff.read(0, 9))
   cnt = iobuff.read(0,12)
   if cnt > val(cnt$(sensor)) then lastupdate$ = unixtime$(runtime)
   cnt$(sensor) = str$(cnt)  
   info$(sensor) = name$(sensor)+" t="+temp$(sensor)+" h="+hum$(sensor)+" b="+batt$(sensor)'
   if iobuff.read(0,12) > val(cnt$(sensor)) then lastupdate$ = time$
   if records=1 then
    if (val(temp$(sensor)) < val(coldest$(sensor))) or (coldest$(sensor) = "") then
     coldest$(sensor) = temp$(sensor): whencoldest$(sensor) = time$ 
    endif 
  endif
  endif
  if debuglevel = 2 then wlog "sensor"+str$(sensor)+" "+info$(sensor)
  gosub showit
 next sensor
 bluetooth.scan 10 
end select
return

end '------------- END ----------------


User avatar
cicciocb
Site Admin
Posts: 1900
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 407 times
Been thanked: 1271 times
Contact:

Re: New release 1.43.6 for ESP32

Post by cicciocb »

Why do you use bluetooth.clear and wifi.awake ?
User avatar
Electroguard
Posts: 836
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 268 times
Been thanked: 317 times

Re: New release 1.43.6 for ESP32

Post by Electroguard »

Originally I used wifi.sleep at startup before the bluetooth scan.
After the scan, instead of doing another ble scan it branched to enable wifi for udp and web output, then afterwards put wifi to sleep again before starting another ble scan. So I evidently forgot to comment out wifi.awake when removing the other wifi stuff... but it was always awake anyway.

Is not much detail about the bluetooth instructions yet ... so I couldn't see how to disable ble while using wifi, therefore the next best thing seemed bluetooth.clear before wifi.awake to prevent anything from the ble scan interfering with the wifi stuff.

Couldn''t find mention of bluetooth.scan in the Help other than it being used in the example with a parameter of 10. So I wondered if it might be the scan duration in seconds, but it actually seemed more like the number of transmitting ble devices to receive from... cos when I set the parameter to 1 it only received data from the first device. So if bluetooth.scan parameter actually controls a string for receiving ble devices data, perhaps that 'adjustable' string might be the culprit why new data is not retrieved from ble transmissions after several hours.
So my next step was to try reducing the parameter to 3 tonight to see if that makes a difference, and if not, then try increasing to 20 tomorrow night.

I also want to try trapping how long before the data problem occurs, perhaps by recording the time of each 'count' update from a gizmo.
So the time when a gizmo's count stops incrementing could at least give a measure of how long before the problem occurs.
User avatar
cicciocb
Site Admin
Posts: 1900
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 407 times
Been thanked: 1271 times
Contact:

Re: New release 1.43.6 for ESP32

Post by cicciocb »

The number after the bluetooth.scan command is the time in seconds.
Reducing to 3 simply the module will rescan for 3 seconds
Try to remove wifi.awake and bluetooth.clear, maybe these could generate problems.
User avatar
Electroguard
Posts: 836
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 268 times
Been thanked: 317 times

Re: New release 1.43.6 for ESP32

Post by Electroguard »

Hi Francesco,
I removed what you said (and some other unnecessary clutter), and added a 'Last gizmo update' elapsed timer to middle of bottom, then posted it up as an edit over top of the earlier script.

When I ran it last evening it was ok for just 1 hour 35 mins before the gizmo data stopped updating, even though the clock and elapsed timer kept running. The 'Inside' gizmo and tft device are sat on the same desk BTW, and the 'Outside' gizmo is only 2m away, so its not a ble connectivity issue.

I upped scan time to 20 (not expecting it to make any difference)... and the gizmo's have been updating ok for more than 10 hours since.
While it's a step in the right direction its not very conclusive - eg: a side-effect of 20 sec scan is that it does many less scans. Also, I know there's a tft gui target array bug which interferes with a users handler array, therefore I should try removing the tft from the equation ... so I will probably do a web page only version later, and drop scan time back to 10 secs, then more lengthy testing.

BTW, removing the clutter has stopped it from disconnecting when doing a STOP.
User avatar
cicciocb
Site Admin
Posts: 1900
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 407 times
Been thanked: 1271 times
Contact:

Re: New release 1.43.6 for ESP32

Post by cicciocb »

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Fri Nov 26, 2021 10:32 am Hi Francesco,
I removed what you said (and some other unnecessary clutter), and added a 'Last gizmo update' elapsed timer to middle of bottom, then posted it up as an edit over top of the earlier script.

When I ran it last evening it was ok for just 1 hour 35 mins before the gizmo data stopped updating, even though the clock and elapsed timer kept running. The 'Inside' gizmo and tft device are sat on the same desk BTW, and the 'Outside' gizmo is only 2m away, so its not a ble connectivity issue.

I upped scan time to 20 (not expecting it to make any difference)... and the gizmo's have been updating ok for more than 10 hours since.
While it's a step in the right direction its not very conclusive - eg: a side-effect of 20 sec scan is that it does many less scans. Also, I know there's a tft gui target array bug which interferes with a users handler array, therefore I should try removing the tft from the equation ... so I will probably do a web page only version later, and drop scan time back to 10 secs, then more lengthy testing.

BTW, removing the clutter has stopped it from disconnecting when doing a STOP.
Robin,
increasing the time to 20 will not do less scan, it will simply gives the result after 20 seconds (it scans for 20 seconds and not each 20 seconds).
Anyway, I did a test some days ago using the BLE and telegram, sending temperature update on my mobile for 2 days without any issues and the module was still connected to the wifi. The scan time was 3 seconds.
Heinz
Posts: 4
Joined: Wed Mar 31, 2021 5:18 pm

Re: New release 1.43.6 for ESP32

Post by Heinz »

Hello cicciocb,

I am starting from srcatch. Where do i found the download for this Release.

Tahnks & Best Regards
Heinz Schertler
Post Reply