Change Total value of a pulse counter with command

[bulthaup]

Sorry, I had to edit my first "positive" post..

I have built my own bin file with VSCode. At first I added the gasmeter pulse counter with a simple reed switch. Total count was saved and survived warm reboot. Then I added an NPN sensor and generated a few pulses.
Suprisingly, both Total counts surviced the warm reboot.

I let the D1 Mini running for a while and after 15 minutes, I rebooted it again. Gasmeter count was gone (reed switch) but NPN still survived though. Difference with my other tests is that I added reed switch on task 1 and NPN on task 2 where it was the other way around in my previous tests.

Now, whatever I do. I cannot make it work again. I'm deleting the NPN sensor and began from scratch again. Whatever I do, the Total count of task 1 with the reed switch never survives a reboot anymore.

[bulthaup]

Something is still not right though..

Setting the value of a Total pulse count to 250 and then rebooting the device gives a weird result of 2 ???

Check the video I made here:

https://www.dropbox.com/s/9cub18irohqbe ... 9.mp4?dl=0

[bulthaup]

Did some more tests.

- Task 1: Pulse counter (reed switch) on GPIO14(D2) and GND
1) SetPulseCounterTotal,99,1
2) Reboot ESP
3) Total Count resets to 0

- Added task 2: Pulse counter (this time I didn't set a GPIO, just left it at NONE)

1) SetPulseCounterTotal,99,2
2) Reboot ESP
3) Total Count restores to 99

1.PNG (17.23 KiB) Viewed 13638 times

What can we conclude from this? Still a problem with PIN initialization?

[TD-er]

Try setting a different value, so you can see to what task it is written.
For example "100" and "200" and try sending it to task 3, just to make sure I didn't mess up with the offset

[GravityRZ]

FYI.

i am testing this parallel and still do not see strange behaviour
everything works like it should on my end

setpulsecountertotal,999
counter task1 is set to 999

setpulsecountertotal,888,2
counter task2 is set to 888

setpulsecountertotal,345,3
unknown command (the same for any other task which does not exist from 3-12)

setpulsecountertotal,555,13
counter task1 is set to 555

setpulsecountertotal,555,88
counter task1 is set to 555(this is also the case for any other task higher then 13, eg also 999)

so things work like they should but only the first 12 tasks are checked if they exist.
not a big deal, perhaps this is the limit of tasks
also large counter settings like 1234567890 are set properly

really strange that bulthaup is getting these strange reactions
@bulthaup, did you ever switch powersupplies

[bulthaup]

I don't have any industrial psu here atm due to corona lockdown. The best I could try was a phone adapter from samsung and a very short usb cable.
Could this really be an issue? I thought that psu issues were more current when the esp is crashing or rebooting all of a sudden. Writing to RTC is not really power hungry right? Also, it doesn't explain why some of the tasks are being saved to RTC and some not.. I also tried my tests directly connected to USB port of my computer. I know this is not meant for "production" but it should be enough power for the tests.

The boot reason is always this btw:

Boot: Manual reboot (8)
Reset Reason: Software/System restart


So no cold boot taking place



@GravityRZ, do you have a specific GPIO boot states configuration set?

The only thing I configged on the newly flashed ESP are NTP setting to set the time, and the pulse counters.. nothing else


Check out this new video. Again weird things going on with task1. Please check the fact that changing the GPIO of a pulse counter task, also reset the Total count. I don't know if this is expected behavior?

Restoring from RTC seems to be working for task2,3,4 but not for task1 for me

https://www.dropbox.com/s/ttyqr9dtdmurj ... 4.mp4?dl=0

[GravityRZ]

i also use a fresh D1 mini and also tested it on a nodemcu v1

all gpio pins set to default, ntp and 2 pulsecounter tasks, basically the same as your setup.(1 pull up 10k on D14 but none on D13 and that also works)

the powersupply was a longshot, dirty powersupplies(spikes) could cause all kind of things.

so maybe a dumb question but how do you operate that reed switch, with a magnet?

do you have a fresh unit which you can hookup with just 2 wires/switches, no reed switch or npn?

if units could be bewitched then certainly you have one?

unless TD-er finds something strange in the code i am at a loss(if he does find something then it is strange that i am not experiencing this strange behaviour)

[bulthaup]

Try setting a different value, so you can see to what task it is written.
For example "100" and "200" and try sending it to task 3, just to make sure I didn't mess up with the offset

GravityRZ,
Is it possible to perform the following tests?
- Take blank D1 Mini, flash firmware with pull requests that includes setpulsecountertotal command
- NTP is optional
- Configure 4 Pulse count tasks, 2 with GPIO, 2 without
- Don’t connect any sensor or wire to the GPIO
- Set Total count values for every task 1-4.
- Reboot ESP
For me this is not working as expected. Actually I don’t believe that a “real” connection to a pulse counter should be necesarry? Setting the Total Pulse count with the command should eventually lead to a taskrun, thus it should be saved to the RTC.
So how the pulse were added, whether it was from a “real” pulse counter, or set by an internal command should really not matter.

Does this sound right TD-er?

[GravityRZ]

i can test that for you

i will flash a 4mb empty imgage first and after that the latest build

my interpretation(TD-er please correct if wrong)
please note that when you specify an device interval of 30 seconds it takes max 30 seconds to flash the value to the RTC. i believe this interval starts when you create the device,
so if you change the pulsecounter and immediately do a reboot the value does not stick, that is what the taskrun command does.
this however is not the problem you see

[GravityRZ]

well not suprisingly but my outcome is exactly like expected

did set the 4 counters with default sttings (interval 0 will turn to interval 60)
waited 1 minute
reboot
all values still there

after that i did set all the counters to different values

111,1
222,2
333,3
444,4

did an instant reboot and as expected the old values remained because they were not flushed to the RTC (which a taskrun command would do

100
200
300
400

4counters.JPG (81.76 KiB) Viewed 13561 times

the only thing i can think of:
you have bought a bad batch of esp's/wemos d1's
the units got affected by a strong magnet (if they are sensitive to that) or static energy discharge

if this is not the case then surely something must remain the same with al these tests.
different units:tested
different versions nodemcu/wemos: tested
different cable:?
different power supply:tested
different wifi connection(or reboot your router or let it tether with you phone to make sure you got another wifi connection)
different browser:switch between internet explorer ,edge or chrome(i use chrome), empty your cache
different platform: use you ipad instead of your pc
different way of flashing (i used espeasy flasher and OTA with released build, home build(arduino))

i have had my fair share of weird problems and i can tell you browsers are one of them
wifi connectivity is another

[bulthaup]

Can you send me an updated bin file again please? I'll try yours..

[bulthaup]

Hold your horses, I think I found the culprit! Haha, you will not believe this...

I'm using a formula because the gasmeter needs 100 pulses for 1m3 of gas.

Capture.PNG (5.25 KiB) Viewed 13553 times

Obviously, every time I set the value of task1 (the only task where I eventually set the formula %value%/100) and I reboot the D1, the formula gets applied again to the Total count.

So, I'm guessing this is still something that needs a fix?


PS: Toch bedankt voor al je moeite Gravity!

[GravityRZ]

ESPEasy.ino.nodemcu.rar

(524.25 KiB) Downloaded 250 times

[bulthaup]

Because the formula %value%/100 was still there, setting the value to 999 with the command, caused the unit to to 999/100 = 9,99. Because I set the decimals to 0, 9,99 was rounded to 9...

This actually shouldn't happen imho. The formula should only be accounted for when new pulses are added to the total amount.

[GravityRZ]

if this was the problem then i am glad we solved it.

are you saying that this formula is applied after you delete a device and add it again?
but if you wipe out a module and reflash it then it is gone right?

Hold your horses, I think I found the culprit! Haha, you will not believe this...

I'm using a formula because the gasmeter needs 100 pulses for 1m3 of gas.

Capture.PNG

Obviously, every time I set the value of task1 (the only task where I eventually set the formula %value%/100) and I reboot the D1, the formula gets applied again to the Total count.

So, I'm guessing this is still something that needs a fix?


PS: Toch bedankt voor al je moeite Gravity!

[bulthaup]

are you saying that this formula is applied after you delete a device and add it again?

Well, the formula is applied once again to the existing Total pulse count value upon reboot. So if I would collect 99 pulses from my gasmeter with the current setup (I'm talking about not using SetPulseCounterTotal, so just using a normal reed switch for pulses) the total amount would get divided by 100, causing it to be 0 again after a reboot. Just like my tests showed. This also explains why only the gasmeter wasn't working. It's the only task where I'm using this formula.
So, the bug that still remains is the fact that there is in fact 99 written to RTC, but when rebooting the same formula gets applied once more and that should not be the case. The formula should only be applied when new pulses are added to the Total count.

[TD-er]

Hmm that's indeed a case of "je verwacht het niet"
Not sure what it should do, as we don't have code to reverse the formula.

But I guess just setting the UserVar value isn't enough, as you also need to set the internal couter values.

I will think of it during diner and hopefully come up with a solution.

[TD-er]

Made an issue for it: https://github.com/letscontrolit/ESPEasy/issues/3019

[TD-er]

Made a pull request for it: https://github.com/letscontrolit/ESPEasy/pull/3020
Can someone test it?

[bulthaup]

I just made a build in VScode but the issue is still there.

Setting task1 to 999 with formula %value%/100 gives 9 after a 1st reboot (999/100= 9,99 --> rounded to 9 because of decimals)

After a second reboot, Total count becomes 0 (9/100= 0,99 --> rounded to 0)

[GravityRZ]

maybe a dumb question but formulas have been there for a while.

do other plugins which survives a warm reboot have the same problem?

[TD-er]

maybe a dumb question but formulas have been there for a while.

do other plugins which survives a warm reboot have the same problem?

It depends on whether the plugin uses an internal (raw) state to determine the next value.
I don't think there are many other plugins suffering from this, or at least I cannot think of one right now.

I think the total count is the only one that may suffer from this as it continues to count.
The normal count is reset on every read, so that one is less likely to cause issues when rendered incorrect at restore from a boot.

So what I could do, is store the raw total count value in the unused 4th UserVar value and at restore use that (hidden) one to set the raw internal value.

[TD-er]

I made an update to the pull request.
Can you test it?

[bulthaup]

I made an update to the pull request.
Can you test it?

Hi, confirmed working!

- Changing the GPIO of a task doesn't reset the Total count.-
- Deleting a task and re-adding it again with same parameters won't restore an earlier saved value from RTC for that task.

So I guess all is working like it should now? Great work TD-er!

Is this commit still necessary then?

https://github.com/letscontrolit/ESPEas ... 7dee1876ff


PS: TD-er, je betaalverzoek link werkt niet meer in je signature

[TD-er]

[...]
Is this commit still necessary then?
https://github.com/letscontrolit/ESPEas ... 7dee1876ff

Yes, as it is a work-around for when you are using a formula to convert the total pulse counter.

PS: TD-er, je betaalverzoek link werkt niet meer in je signature

Hmm dat verklaart de nogal "tegenvallende" opbrengst van die link. (1x 5 euro op ontvangen)

[bulthaup]

Great, I found you guys on Patreon meanwhile. Keep it up!

[GravityRZ]

i tested it also but i still see the old behaviour

without %value%/5

countertotal=11
reboot
countertotal=11

with %value%/5

countertotal=11
reboot
countertotal=2

can somebody perhaps share their build so i can test with that one.(i downloaded build dated 15-04 23:30 so maybe i am doing something wrong)

[bulthaup]

can somebody perhaps share their build so i can test with that one.(i downloaded build dated 15-04 23:30 so maybe i am doing something wrong)

You can clone or download zip from this repo

https://github.com/letscontrolit/ESPEas ... 0f55666354


or this

https://github.com/letscontrolit/ESPEas ... c68622c059

[TD-er]

i tested it also but i still see the old behaviour

without %value%/5

countertotal=11
reboot
countertotal=11

with %value%/5

countertotal=11
reboot
countertotal=2

can somebody perhaps share their build so i can test with that one.(i downloaded build dated 15-04 23:30 so maybe i am doing something wrong)

I can make a test build for it, as there has not yet been a nightly build with these fixes in it.

[GravityRZ]

no problem.

if you can make the build i can test it if you want but if bulthaup tested it and it works than in is fune with me.

[GravityRZ]

thanks.

probably took a different version.

can somebody perhaps share their build so i can test with that one.(i downloaded build dated 15-04 23:30 so maybe i am doing something wrong)

You can clone or download zip from this repo

https://github.com/letscontrolit/ESPEas ... 0f55666354


or this

https://github.com/letscontrolit/ESPEas ... c68622c059

[bulthaup]

normal_ESP8266_4M1M.zip

(548.19 KiB) Downloaded 274 times

[GravityRZ]

thanks,

confirmed working

question regarding downloading the latest source.
how do you get to that specific link in github

i see code, issues but somehow i do not see how to jump to were the code including the fix is

[bulthaup]

Hi,

You can start from the pull request and browse the code from that specific commit.

Untitled.png (37.24 KiB) Viewed 13358 times

[TD-er]

Whenever I make a pull request, I do actually request to merge a branch on my fork with the mega branch of the ESPEasy repository.
This can also be seen in the screenshot made by bulthaup.
You can actually click on that to open in a new browser tab and then you are viewing the code as it is present in that branch on my repository.

But then it is rather cumbersome to download all files exactly as it is on that branch via the GitHub page.
So if you want to do it more often, or at least with a pull request containing a bit more changes than a single file, then it is best to use some Git program to do it for you.

[GravityRZ]

thanks Bulthaup and TD-er.
totally clear now.

not a big deal for me to go to that point, clone/download the complete zip and compile it.