Pulse counter P003 sends every pulse to controller, ignoring the interval setting

Roos-AID commented 3 years ago

Checklist

[x] The title of this issue is "to the point" and descriptive.
[x] This issue describes what is happening.
[x] This issue describes what components are affected (e.g. name of plugin/controller)
[x] This issue describes how to reproduce it.
[x??] This issue describes when it was introduced (when known) and what version is now showing the problem.

I have...

[x] searched the issue tracker or the forum for a similar issue. (include links when applicable)
[x] entered a system description using "Copy info to clipboard" on the sysinfo page. (when possible)
[x] entered the full filename of the used version (e.g. ESP_Easy_mega-20181001_test_ESP8266_4096_VCC.bin )
[x] given a list of active plugins or controllers when applicable.
[ ] filled out all applicable fields below.

Steps already tried...

[ ] Tried a clean install (empty .bin files are included in the ZIP)
[ ] Tested previous/other build (mention which one already tested)
[ ] Tested on other node to make sure hardware isn't defective.
[ ] Verified if the problem is limited to a single plugin/controller

If you self compile, please state this and PLEASE try to ONLY REPORT ISSUES WITH OFFICIAL BUILDS!

Summarize of the problem/feature request

Since I installed ESP_Easy_mega_20200913_normal_ESP8266_4M1M it seems that the Pulse counter is sending each pulse to controller 1 (MQ Openhab) instead of waiting until timer expires. Timer is set to 60 sec.
Same problem also with ESPEasy_ESP82xx_mega-20201130 .

With version ESP_Easy_mega-20190827_normal_ESP8266_4M.bin it was still working ok. I reverted to this version and it is working as expected.

Expected behavior

Send counter, total count and time every 60 seconds (setting from timer)

Actual behavior

At every change the counter is send , so both 1 value and 0 value is send to MQ controller.

Steps to reproduce

System configuration

Hardware:

ESP Easy version:

ESP Easy settings/screenshots:

Rules or log data

Roos-AID commented 3 years ago

Any news on this? Would like to use some of the new features.

tonhuisman commented 3 years ago

Looking at the code of both the P003 plugin and C005 controller, this seems highly unlikely, the collected pulse data is only retrieved on a PLUGIN_READ action, and that should only happen either at the configured Interval time, or when issuing a TaskRun command from the rules or an external source (like MQTT or HTTP), I think we need to see more of your configuration to better understand what's going on, can you share screenshots of the Controller page for OpenHAB MQTT and your Pulse counter?

Roos-AID commented 3 years ago

Ton, I installed latest version again, and the bug showed again. So, unlikely, but it is there. Restored ESP_Easy_mega-20190827_normal_ESP8266_4M.bin and it was OK again.

Below screenprints on the working and latest (defect) FW.

Screenprint Device overview on FW 20190827, working OK:

Screenprint Config page Pulse counter, working OK:

Screenprint Config MQTT

Screenprint Firmware overview

Screenprint MQ Log in Openhab showing the input values from Device Count value, one message per 60 seconds

Then Flashed latest Firmware : the Screenprint MQ Log in Openhab showing the input values from Device Count value alternating between 0 and 1 every couple of seconds.

Screenprint of Device overview with the bad firmware, exactly same for working and not working version, same for pulse config.

Screenprint of Firmware version installed

Then I restored the firmware to the ESP_Easy_mega-20190827_normal_ESP8266_4M.bin and the MQ log is OK again.

tonhuisman commented 3 years ago

Hmm, strange (again). You don't seem to have Rules enabled, so that can be excluded as a possible source for these triggers.

@TD-er Are any controller- or plugin- triggers scheduled when a pulse (in fact any gpio state-change) is received? As the Rules are disabled, there are no Monitors active, AFAICS, though there is stuff happening on GPIO's. Latest changes to the Controller C005 and Plugin P003 are quite some time ago, so it feels surprising this is an issue found now, and not earlier.

@Roos-AID Can you re-try, please, with an ESPEasy build from October 2020, before the move of GPIO commands to the ESPEasy core?

Roos-AID commented 3 years ago

@Roos-AID Can you re-try, please, with an ESPEasy build from October 2020, before the move of GPIO commands to the ESPEasy core?

As you can see from the original report, with version ESP_Easy_mega_20200913 the problem also manifested itself. So it was introduced before that.

As the Node is in a pre-production environment, it isnt that easy to test different firmwares.

A key thing to mention is the use of Serial ! I have a Open Therm Gate Way on the serial port, maybe serial is triggering something ?

I can setup a test bench if you like where I can install different FW versions , let me know.

TD-er commented 3 years ago

A key thing to mention is the use of Serial ! I have a Open Therm Gate Way on the serial port, maybe serial is triggering something ?

What does this gateway send to the ESP? Is it sending commands for ESPEasy? I only see a single pin, so it looks like it is only sending to the gateway?

Roos-AID commented 3 years ago

The serial connection is the P020 plugin, connecting serial at 9600 baud to TCP port 6638. The gateway sends continuously data about the central heating to a server through TCP/IP. So it is receiving and sending to the gateway. GPIO-14 is a reset pin to reset the Gateway when ESP reboots.

The ESP should not have problems with the content of the datastream.

Roos-AID commented 3 years ago

@tonhuisman Ton, any news/ideas ? Can I do something to get further analysis ?

tonhuisman commented 3 years ago

I have not found any clues yet on what could cause this, and I wouldn't know how to replicate your situation.

A few things you could try:

You could disconnect, or at least disable, all other devices from the unit and see if that improves the situation.
What read interval do the DS18b20 sensors have?
What happens if the tasks 1 and 3 are moved to another position? (Maybe there's an off-by-one issue somewhere in the code)

tonhuisman commented 3 months ago

@Roos-AID Long time ago... I've changed some code in P003 Pulse counter, according to issue #5096, and opened PR #5098 to try and solve that. Are you available to test with a build from this GH Actions run, to see if the newly introduced option Ignore multiple Delta = 0 with an Interval of 0 solves your issue? TIA!

Roos-AID commented 3 months ago

Ton,

Sorry, cannot test this on short notice. I have implemented the functionality in the OTGW software and put this into production. So there is currently no ESPEasy involved.

I do have other ESPEasy instances running but none with Pulse input on the HW.

Met vriendelijk groet,

Rob Roos

Op 10 aug 2024, om 16:40 heeft Ton Huisman @.***> het volgende geschreven:

@Roos-AID https://github.com/Roos-AID Long time ago... I've changed some code in P003 Pulse counter, according to issue #5096 https://github.com/letscontrolit/ESPEasy/issues/5096, and opened PR #5098 https://github.com/letscontrolit/ESPEasy/pull/5098 to try and solve that. Are you available to test with a build from this GH Actions run https://github.com/letscontrolit/ESPEasy/actions/runs/10331692241, to see if the newly introduced option Ignore multiple Delta = 0 with an Interval of 0 solves your issue? TIA!

— Reply to this email directly, view it on GitHub https://github.com/letscontrolit/ESPEasy/issues/3420#issuecomment-2282143563, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQ5PY23ZXFP6LSNLN4E2Y3ZQYQ7JAVCNFSM6AAAAABMJ4NPASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBSGE2DGNJWGM. You are receiving this because you were mentioned.

letscontrolit / ESPEasy