#D2 formatting on webgui.esp does not work any more after update

[AloisKlingler]

hi,

have updated on a wemos d1 mini with relay shield from firmware espeasy_mega_20201102_normal_esp8266_4m1m to most current ESP_Easy_mega_20211224_normal_ESP8266_4M1M after that, a custom webgui.esp with number formatting does not work any more as before, the numbers are printed with only one digit if below 9.

webgui.esp: attached webgui.esp.txt

devices:

looks on the webgui like:

also the time is affected, not only the variables. both were looking ok before the update.

rules:

on System#Boot do
 GPIO,5,0
 Monitor,GPIO,5
 TaskValueSet,2,1,0
 TaskValueSet,2,2,0
 timerSet,1,30
endon

on Rules#Timer=1 do
 SendToHTTP,192.168.0.250,80,/apcucollector.php?smartswitch=%sysname%&ipv4=%ip%&uptime=%uptime%&load=%sysload%&freeram=%sysheap%&rssi=%rssi%&BabyphoneState=[Babyphone#State]
endon

on Clock#Time=All,**:** do
 TaskValueSet,2,1,%syshour_0%
 TaskValueSet,2,2,%sysmin_0%
 asyncevent,calcsleeptime
endon

on GPIO#5 do
 if [Babyphone#State] = 0 and [Time#HourSw] != 0 and [Time#MinSw] != 0
  sendTo 80,'event,ControlZ3=102'
 endif
 TaskValueSet,2,3,%syshour_0%
 TaskValueSet,2,4,%sysmin_0%
 asyncevent,calcsleeptime
 timerSet,1,1
endon

on calcsleeptime do
 if [Babyphone#State] = 1
  Let,1,(([Time#Hour]*60)+[Time#Min])
  Let,2,(([Time#HourSw]*60)+[Time#MinSw])
  Let,3,([INT#1]-[INT#2])
  if [INT#3] < 0
    Let,3,([INT#3]+1440)
  endif
  Let,4,([INT#3]/60)
  Let,5,[VAR#4#F]
  Let,6,(([VAR#4]-[INT#5])*60)
 else
  Let,5,0
  Let,6,0
 endif
endon

on resettime do
 TaskValueSet,2,3,%syshour_0%
 TaskValueSet,2,4,%sysmin_0%
 asyncevent,calcsleeptime
endon

BR Alois

[tonhuisman]

Can you upgrade to a more current PR-build? (See the Actions tab, next to Issues and Pull requests), as I think this template-parsing issue has been fixed already, about 2 months ago, when the Arduino libraries where updated to 3.0.x. You can pick any recent PR-build, as most PR changes are in plugins in TEST builds, mostly not in the NORMAL builds (and then it would still be improvements 😃). If desired you can later revert to an older build (but I can't see why you would want that).

[AloisKlingler]

Github only shows me an unicorn with "This page is taking too long to load. Sorry about that. Please try refreshing and contact us if the problem persists." on clicking on any of these builds :-/

[tonhuisman]

Github only shows me an unicorn with "This page is taking too long to load. Sorry about that. Please try refreshing and contact us if the problem persists." on clicking on any of these builds :-/

That is a server problem at GH side, I'm having the same issue here 😞

[AloisKlingler]

fixed with 20220328 :-)

[AloisKlingler]

@tonhuisman I do not know if it is worth creating a new ticket:

TaskValueSet,2,3,%syshour_0%
 TaskValueSet,2,4,%sysmin_0%

leads to "0" instead of e.g. "07" on the affected Device set:

585581044: EVENT: resettime
585581065: ACT  : TaskValueSet,2,3,07
585581072: ACT  : TaskValueSet,2,4,34
585581079: ACT  : asyncevent,calcsleeptime
585581206: EVENT: calcsleeptime
585581246: ACT  : Let,1,((0*60)+34)
585581255: ACT  : Let,2,((0*60)+34)
585581262: ACT  : Let,3,(34-34)
585581274: ACT  : Let,4,(0/60)
585581279: ACT  : Let,5,0
585581285: ACT  : Let,6,((0-0)*60)
...
585611518: Dummy: value 1: 0
585611520: Dummy: value 2: 34
585611521: Dummy: value 3: 0
585611523: Dummy: value 4: 34

after switching to %syshour% this works correct:

586341439: EVENT: resettime
586341461: ACT : TaskValueSet,2,3,7
586341467: ACT : TaskValueSet,2,4,47
586341472: ACT : asyncevent,calcsleeptime
586341622: EVENT: calcsleeptime
586341662: ACT : Let,1,((7*60)+47)
586341672: ACT : Let,2,((7*60)+47)
586341679: ACT : Let,3,(467-467)
586341691: ACT : Let,4,(0/60)
586341697: ACT : Let,5,0
586341702: ACT : Let,6,((0-0)*60)
...
586391519: Dummy: value 1: 7
586391521: Dummy: value 2: 47
586391523: Dummy: value 3: 7
586391525: Dummy: value 4: 47

[tonhuisman]

I do not know if it is worth creating a new ticket:

TaskValueSet,2,3,%syshour_0%
TaskValueSet,2,4,%sysmin_0%

leads to "0" instead of e.g. "07" on the affected Device set:

Well, IMHO it is not related, but the _0 (zero-prefixed) variants of these variables are normally used for presentation, so actually return a string, maybe there is the issue. And besides that, representing a numerical value with a 0 prefix in the C and C++ programming languages (as used by ESPEasy), implies the value is octal (8-base, not decimal = 10-base), and while that doesn't pose a problem for 07, it does for 08 and 09, as that would be invalid values.

We could have a look at the code that processes this, to see if this should be changed or not.

[TD-er]

We could have a look at the code that processes this, to see if this should be changed or not.

This is a bit tricky as we do preprocess the string to match whether it is a numerical and then feed this to standard functions to create a floating point value. But some plugins may directly call those functions without our preprocessing. I guess stripping leading zeroes may be possible to add to our function to return a numerical, but I'm not sure if that als breaks code where it was intended to show the leading zeroes like writing to a display.

[tonhuisman]

These numerical issues that at some point existed, have been resolved for a long time, so this issue can be closed.