Just to mention some proven alternative approaches for your research if you haven’t already considered them:

• float level sensors
• ultrasonic level sensors
• capacitive level sensors

I also found the logparser did not handle certain log entries, such as the logfile produced by the mysensors gateway on raspberry pi, e.g. prefixed with timestamps, etc.

Opened pull request to improve this, comments welcome, especially if you are able to test this locally (only need to copy the Logparser directory and open logparser.html locally in a browser):
https://github.com/mysensors/MySensors/pull/1468

maybe a good knowledge resource for cross-compilation against rpi targets:
https://tttapa.github.io/Pages/Raspberry-Pi/C++-Development/Building-The-Toolchain.html

FWIW,
on a more specific tweak, one of the things I struggled with for a while was why the mysensors defaults for RF24 transport use tx power level RF24_PA_HIGH (-6 dBm) by default instead of RF24_PA_MAX (0 dBm)

I wound up setting:
#define MY_RF24_PA_LEVEL (RF24_PA_MAX)
in all my sketches, as it seems to make the difference for those several walls and/or extra few meters of range.

(Not sure why the -6 dBm setting was chosen?)

Very easy to program with SDCC (via makefiles and/or vscode/platformio), however, it's all pure C, and I dont know if anyone has any recent C-only implementations of mysensors (it all seems to be C++).

https://github.com/zerog2k/stc_blinky

Also, the STC15F204EA (or STC15L204EA) are probably the least capable - only 256b ram, 4k code, and no hardware uart/spi, etc. The can do some basic RF24 tasks, but I doubt they could handle the full mysensors state machine.

There are the more capable versions, e.g. STC15W408AS, etc with more ram (2-4k), code (8+ kB), and a basic set of peripherals (hw uart, spi, etc) - however still far underperforming typical arduino (atmega328p) specs.

@Dreded
FWIW, I don't have direct experience myself with longevity and durability of heatshrink + hot glue, but one of the YT channels I follow does. Julian Ilett has a custom-built pwm solar charge controller which he made small production runs of, and started having failure issues with this method, as these are exposed to outdoor environmental conditions.
https://www.youtube.com/watch?v=_YGlRkArsyA

however, I would think that "potting" or filling the heatshrink openings with "RTV" (i.e. room-temperature vulcanizing) silicone sealant. This stuff is used on marine and aircraft applications to completely waterproof stuff.

So this is where I see for atmega 168/328, Tone lib is modding Timer2:
https://github.com/arduino/ArduinoCore-avr/blob/master/cores/arduino/Tone.cpp
So that's why it's important to explicitly set every Timer2 register.

Reviewing AVR130 app note, I think I was incorrect about being able to sleep and externally clock T1 (to count pulses), as T0/T1 seem to be synchronous, meaning they require the system (i/o) clock to be running to latch in the edges of external source, and only IDLE power save mode supports running the clk_io. This mode will use way more current, e.g. w/ internal rc osc at 8MHz at 3.3v about 700uA.

Seems that only Timer2 can allow an "asynchronous" external clocking event (pulse counting) with cpu clocks off (in very low power modes).

Just blabbering, yet another aproach could be to, instead of bothering with RTC crystal on Timer2:

1. use watchdog timer as a wakeup (interrupt only) source, for either an approximately 4 or 8 second interval (5 mins = 300 secs, 300 / 4 = 75 wakeups)
2. use Timer2 as external event counter to count the pulses (without interrupt/wakeup?)

regarding the mysensors lib, I'm not an expert, but reviewing the code, seems like you covered it:
mysensors sleep overloads call _sleep in MySensorsCore.cpp
https://github.com/mysensors/MySensors/blob/master/core/MySensorsCore.cpp#L562
which call transportDisable() like you do then call hwSleep() variants in MyHwAVR.cpp (depending upon how you call sleep, e.g. with pin interrupt setups or not), which eventually call hwPowerDown()
https://github.com/mysensors/MySensors/blob/master/hal/architecture/AVR/MyHwAVR.cpp#L83
which seems to do pretty much what you are doing (maybe a few other things, etc..) to call sleep. ref: https://www.microchip.com/webdoc/AVRLibcReferenceManual/group__avr__sleep.html

So I dont really see any additional state machine stuff happening w.r.t. MySensors itself.

@Encrypt
yes, interesting... i also had strange issues trying to implement rtc first time, but it was due to arduino lib mucking with Timer2 registers (due to Tone libs). The answer was to make sure all registers were not assumed to be default, but explicitly set in setup(). You seem to have that here.
I did a quick scan of mysensors repo code, but I don't see where it is touching any of Timer2's registers, so not sure.
Did you toggle led/pin in the current code's ISR, to be 100% sure your the issue is that the isr is getting triggered at unexpected interval? (maybe sanity check that with scope.) That should bifurcate the problem either to the timer implementation/configuration, or something else.

@zboblamont I also agree here. But it should be totally possible to setup Timer1 as externally clocked counter, i.e. pulse from meter can increment Timer1 counters without interrupting CPU from sleep, and only interrupt and increment another counter variable on Timer1 overflow (if it happens) so you can be sure you have complete, accurate count when you wake up from your long sleep to do your accounting and reporting.

Briefly looking at the datasheet for the water sensor, I didn't get a sense of what the unit of water volume/flow a single HF pulse means. Depending on what this unit is, and how often you wakeup and check the T1 counter value, it may not even be necessary to bother with handling counter overflow, e.g. pulses = 1 liter; would you ever consume >65kL in <10 mins?
In this case, you only simply need to worry about waking up from long sleep interval, polling and clearing counter, sending, and going back to sleep.

also, declaring static var inside isr is strange to me (maybe it works?) but I have always seen that you should declare any vars to be manipulated in isr to be global and volatile

If you are using watch crystal (32khz) connected to TOSC1/2, I have an "rtc" one second tick counter you can use (from an unrelated project):
https://github.com/zerog2k/rcxr01/blob/master/rcxr01_demo1/src/rtc.h

You can extend this to different tick periods with different prescalers.

But i think any interrupt will bring mysensors out of wait? Which means you will need to enter sleep yourself, and decide whether to go back to sleep or hand control back to main loop for mysensors to do reporting thing.

Here are some examples i put together for directly controlling entering/exiting low-power sleep:
https://github.com/zerog2k/rcxr01/blob/master/rcxr01_demo1/src/sleep.h

You can also use watchdog timer as (less accurate) wakeup timer.
(But you said you need more exact, <1 sec, accuracy to send at [exactly] 5 sec boundaries, which means you'll need timer2/rtc/watch crystal for that level of accuracy)

You can use a separate counter, e.g. timer1 in counter mode to capture sensor pulses as an external clock for the counter. You probably only need interrupt on counter overflow, so you can capture overflow counts. Then when you wake up on an interval and check the number of pulses you can evaluate overflows + remaining counter value, and determine number of pulses since previous wakeup, etc. (without needing wakeup/cpu to keep track of individual pulses)

maybe try using the RF24 library's simple scanner example sketch to scan your rf channels to ensure there is no other source of interference on your selected nrf channels (defaulting to chan 76 [0x4C])
(ok sorry, i see that you are using rfm69 ;)

@magpern

for others trying to find a good channel, I found this useful showing Wifi and BLE channels. (Orange are BLE advertising channels, which should always be reserved/unoccupied by NRF stuff):

Yes I think wifi channels >11 (like 12,13,14 overlap to 2476).
So sometimes nrf channel 1 is a good choice, but as always, depends on your environment ;)
Do you have wireless mice, keyboards, etc - many of these use NRF24 or similar 2.4GHz ISM? Are you sure the other 2.4GHz devices are really bluetooth and not proprietary?

@magpern glad to see you got it fixed, however I don't think wifi channel 11 interferes with channel 76, which is at 2476 MHz.
Maybe there are some other sources of interference on nrf channel 76 in your environment?

I would like to suggest that the "Serial Protocol" button/page (https://www.mysensors.org/download/serial_api_20) be renamed to a more generic "Protocol" button. The contents are relevant regardless of whether folks are using serial gateways, or like in my case mqtt gateway.

nm, I seems like it eventually sends the sketch name

ok, I think i have also may have found a bug in the HA mysensors implementation, i.e. if you name your sketch with some reserved names, it never registers in HA.

I.e.
sendSketchInfo("motion_sensor", "1.0"); won't work in HA
but sendSketchInfo("motion_sensor_foo", "1.0"); shows up :(
I didn't see any mention of this in https://www.home-assistant.io/components/mysensors/
Maybe it's a bug (should mysensors ha component rename it or prefix with some namespace, etc; or should this be documented in guide - and then what are the reserved names which we cannot name sketches to?)

@bereska
look at how the reference sketch in the homeassistant mysensors page works.
I starts with a bool initialValueSent set to false.
It checks for this in loop, and if not already set to true, it will send initial values, then set initialValueSent = false, so that it never runs again (until sensor is restarted).

Also regarding your sketch logic, should it periodically send values of all sensors (like at least once per hour, per day, etc)? You may want to look at that as well.

Looking at your HA log, do you see that both V_FLOW and V_VOLUME values are sent after some time?

With the sketch, their idea is that you use initialValueSent to send initial values (for all types) only once (at first boot) in loop section.

@bereska
looks mostly correct, althought I would take a look at the example here to use their technique for ensuring you send initial values for V_FLOW and V_VOLUME.
ref: https://www.home-assistant.io/components/mysensors/

From your sketch, it seems possible that either may not be sent right away, e.g. if volume or flow is not changing, etc.

Also, where in HA UI are you looking? I had to add my sensor to one of my lovelace cards. Still getting the hang of the new UI (but definitely better than it was before). I also saw it in developer, states under current entities