New release 1.43.6 for ESP32
- cicciocb
- Site Admin
- Posts: 2095
- Joined: Mon Feb 03, 2020 1:15 pm
- Location: Toulouse
- Has thanked: 450 times
- Been thanked: 1385 times
- Contact:
- Electroguard
- Posts: 886
- Joined: Mon Feb 08, 2021 6:22 pm
- Has thanked: 285 times
- Been thanked: 329 times
Re: New release 1.43.6 for ESP32
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.
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.
- cicciocb
- Site Admin
- Posts: 2095
- Joined: Mon Feb 03, 2020 1:15 pm
- Location: Toulouse
- Has thanked: 450 times
- Been thanked: 1385 times
- Contact:
Re: New release 1.43.6 for ESP32
Post your program, I'll give an eye.
I cannot reproduce your problem
I cannot reproduce your problem
- Electroguard
- Posts: 886
- Joined: Mon Feb 08, 2021 6:22 pm
- Has thanked: 285 times
- Been thanked: 329 times
Re: New release 1.43.6 for ESP32
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.
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 ----------------
- cicciocb
- Site Admin
- Posts: 2095
- Joined: Mon Feb 03, 2020 1:15 pm
- Location: Toulouse
- Has thanked: 450 times
- Been thanked: 1385 times
- Contact:
- Electroguard
- Posts: 886
- Joined: Mon Feb 08, 2021 6:22 pm
- Has thanked: 285 times
- Been thanked: 329 times
Re: New release 1.43.6 for ESP32
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.
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.
- cicciocb
- Site Admin
- Posts: 2095
- Joined: Mon Feb 03, 2020 1:15 pm
- Location: Toulouse
- Has thanked: 450 times
- Been thanked: 1385 times
- Contact:
Re: New release 1.43.6 for ESP32
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.
Reducing to 3 simply the module will rescan for 3 seconds
Try to remove wifi.awake and bluetooth.clear, maybe these could generate problems.
- Electroguard
- Posts: 886
- Joined: Mon Feb 08, 2021 6:22 pm
- Has thanked: 285 times
- Been thanked: 329 times
Re: New release 1.43.6 for ESP32
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.
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.
- cicciocb
- Site Admin
- Posts: 2095
- Joined: Mon Feb 03, 2020 1:15 pm
- Location: Toulouse
- Has thanked: 450 times
- Been thanked: 1385 times
- Contact:
Re: New release 1.43.6 for ESP32
Robin,[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.
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.
-
- Posts: 4
- Joined: Wed Mar 31, 2021 5:18 pm
Re: New release 1.43.6 for ESP32
Hello cicciocb,
I am starting from srcatch. Where do i found the download for this Release.
Tahnks & Best Regards
Heinz Schertler
I am starting from srcatch. Where do i found the download for this Release.
Tahnks & Best Regards
Heinz Schertler