O.K. I think I understand what you want to do . I thought you wanted the counter to reset at midnight. What you have shown will set the counter to 1 the first time each day that the ‘reset’ record processes and then increment the counter each subsequent time the ‘reset’ record processes. But then I think you need only three records:
record(bo, "$(user):reset") {
field(FLNK, "$(user):day")
}
record(stringin, "$(user):day") {
field(DTYP, "Soft Timestamp")
field(INP, "@%j NPP")
field(TSEL, "$(user):now.TIME")
field(FLNK, "$(user):count")
}
record(calc "$(user):count") {
field(INPA, "$(user):day NPP MS")
field(INPB, "366")
field(CALC, "A#B?1:VAL+1;B:=A")
}
I see the confusion. I wasn't using the "now" record to set/update the time, it was only to simulate pressing "reset". I updated the records after removing the simulated presses, which may help explain my reasoning. I about to test it...so I could still be wrong.
If the "reset" button is not pressed over the course of a day, it stays at 0. If it is pressed, then it sends the time stamp to "day" which stores it.
Since "clear' only cares that the day is different to determine reset to 1 or increment, I do not need to have a record performing a SCAN.
What do you think ?
record(bo, "$(user):reset") { field(FLNK, "$(user):day")
}
record(stringin, "$(user):day") { field(DTYP, "Soft Timestamp") field(INP, "@%j NPP")
field(TSEL, "$(user):now.TIME") field(FLNK, "$(user):clear") }
record(calcout, "$(user):clear") { field(INPA, "$(user):day NPP MS") field(INPB, "366") field(CALC, "A#B?1:0;B:=A") field(DOPT, "Use CALC") field(OOPT, "Every Time") field(OUT, "$(user):count.C PP") }
record(calc, "$(user):count") { field(INPC, "$(user):clear.VAL") field(VAL, "0") field(PINI, "YES") #field(TPRO, 1) field(CALC, "C?1:VAL+1") }
Let’s work through your code: - The ’now’ record process every second. As part of processing it set’s its TIME field to the current date and time. At the end of processing it does a forward link to the ‘day’ record.
- The ‘day’ record thus processes ever second. It reads the time value from ‘day.TIME’ and converts either the minutes (as shown in your example for testing) or the day of the year and sets its value field from the conversion result. At the end of processing it does a forward link to the ‘clear’ record.
- Thus the ‘clear’ record processes every second. The ‘clear’ record gets its ‘A’ field value from the ‘day’ record. (FWIW I had an typo in my example, too, The CALC field should be “A#B?1:0;B:=A”). So the value is set to 1 if the new ‘day’ value differs from the value when the ‘clear’ record previously processed.
- Now here is where you changed things. You have OOPT set to "Every Time” so the ‘clear’ record will push a value into the ‘count’ record ‘C’ field every second which will then cause the ‘count’ record to process every second (in addition to the times that the ‘count’ record process as a result of your button being pressed).
- Thus the ‘count’ record processes at least once per second. Every time the ‘count’ record processes it either clears or increments its value. Since you have the ‘clear’ record causing the ‘count’ record to process once a second this means that the ‘count’ record increments its value once per second in addition to incrementing its value every time your button of interest is pressed.
What you need, and what I think was in my original example is to have the ‘clear’ record OOPT field set to "When Non-zero". This will ensure that the ‘clear’ record causes the ‘count’ record to process (and clear) only when the day (or minute, for testing) changes.
Hi Eric, I'm not sure if I'm miss-understanding your example, or mis-stated my use case.
Use case: Every time a user presses "reset" on a display manager (caput), the counter increments. The counter resets to 0 everyday at 0 hour, providing a daily sum of resets.
In my adaption of your record scheme, I use the "now" record to simulate pressing reset (caput on a bo). I take the time stamp from that press, compare it to the time stored, and increment the count if the time is within the same period, (day, minute or hour depending on %j, %M %H). If the time component increments, then send the reset signal.
I think that the code you show below won’t quite work right. It will increment the count once per second. Note the OOPT field in my example. It pushes the value into the count record (and hence causes the ‘count’ record to process) only when the calculation is non-zero — i.e. only when the count record is to be cleared.
This is what I've decided on based on Eric's and Diego's examples:I learned a lot from this. Many thanks to everyone for sharing their ideas.
One gotacha: The STRINGIN record translates the time stamp to a strftime conversion, %M for testing and %j for production. That output is still a string, "001" through "365". However, CALC takes this string and casts it into an integer. I haven't confirmed this assumed cast from base source code yet, so correct me if I'm wrong.
>cat db/counter.db record(bi, "$(user):now") { field(PINI, "YES") field(SCAN, "1 second") field(FLNK, "$(user):day") }
record(stringin, "$(user):day") { field(DTYP, "Soft Timestamp") field(INP, "@%M") # for testing purposes using 1 minute field(TSEL, "$(user):now.TIME") field(FLNK, "$(user):clear") }
record(calcout, "$(user):clear") { field(INPA, "$(user):day NPP MS") field(INPB, "1000") field(CALC, "A>B?1:0;B:=A") field(DOPT, "Use CALC") field(OOPT, "Every Time") field(OUT, "$(user):count.C PP") }
record(calc, "$(user):count") { field(INPC, "$(user):clear.VAL") field(VAL, "0") #field(TPRO, 1) field(CALC, "C?0:VAL+1") }
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·