How to make Neovac Watermeter smart?!

Dear Community

I hope you can help me with this issue, as I am honestly running out of ideas and feel that I have already tried almost everything.

Current situation
I would like to integrate my cold and hot water meters into Home Assistant.
This is the meter model I am using, including a photo for reference:

Both meters are equipped with a reed contact, which is connected to a Superstatic 749.
According to Neovac, the Superstatic has not a M-Bus interface, but for the 433 MHz radio transmission the encryption keys are not provided, so accessing the data wirelessly is not possible.

Product documentation:
instructions-for-use-superstatic-749.pdf

What I have already tried

  • Tapping into the reed contact and connecting it directly to an ESP32. This works electrically, but then no data is sent anymore to the Superstatic 749, so this approach is not usable. I also tried this with an optocoupler, without success.
  • AI on the Edge. Unfortunately this solution is unreliable due to reflections and glare, and it is far too inaccurate for obtaining a live consumption value.
  • HomeWizard Watermeter, without success:
    https://www.homewizard.com/de-at/shop/watermeter-wlan/
  • An inductive sensor (LJ12A3-4-Z/BX, NPN, NO). This also did not work, most likely because the plastic housing of the water meter is too thick.
  • I contacted Flume to check compatibility. According to their support, their product is not compatible with my water meter

I also discussed possible solutions directly with Neovac. The only option they offer is to replace both the Superstatic and the water meters entirely, which would cost well over CHF 1’000. In around six years, the meters are planned to be replaced anyway with LoRaWAN-enabled devices, so this investment does not make much sense to me…

My question
Has anyone here found a working solution for integrating Swiss water meters like these into Home Assistant? It seems that many of the commonly available smart water meter solutions simply do not work with Swiss-installed meters.

I would really appreciate any ideas, approaches or experiences that might point me in the right direction.

Best regards,
Goran

If it took 749 out, it was likely wired improperly. The manual linked says 749 input has 2Mohm pullup at 2.3V.
But even if correctly set up, it’s fragile approach with 3.3V Esp. Some comparator ic or BSS138 might work…

Your model doesn’t have pulse output?

The 749 is still working correctly and was not damaged.

The reed contact on the meter is properly connected and is providing clean, stable pulses that are being counted reliably. There are no electrical issues, no dropouts, and no false triggering.

The problem is not related to the input stage or voltage level matching, but to the lack of a practical and reliable way to read the meter mechanically or via sensors without modifying the meter itself.

This model does not have a dedicated pulse output.

So how was your wiring setup when it worked on esp but took 749 out ?

I cut the reed cable that runs from the water meter to the 749 and used Wago connectors to connect the ESP in parallel.

That setup worked for the ESP and pulses were detected correctly, but the 749 stopped receiving pulses.

I also tested the same setup using an optocoupler, but without success.

I was never able to get both the ESP and the 749 to receive the pulses reliably in parallel.

Because of that, I stopped the experiment and removed the ESP32 entirely.

The reed cable between the water meter and the 749 is now reconnected using Wago connectors and works without any issues.

There’n no way to make it work with optocoupler.
But direct connect to esp, if done correctly, shouldn’t take out 749.

I physically cut the reed cable between the water meter and the Superstatic 749 and terminated both reed wires using Wago connectors.

From these Wago connectors, I connected the ESP32 in parallel:

  • one reed wire to an ESP32 GPIO configured as INPUT_PULLUP (3.3 V)
  • the other reed wire to ESP32 GND

With this setup, the ESP32 detected the reed pulses correctly and reliably.

However, once the ESP32 was connected in parallel, the Superstatic 749 stopped receiving pulses entirely.

Removing the ESP32 immediately restored normal pulse detection on the 749.

The root cause is the electrical interaction between the two inputs:

the 749 has an internal ~2 MΩ pull-up to 2.3 V, while the ESP32 input (with its own pull-up and input circuitry) loads and disturbs the reed signal when connected in parallel. This prevents the reed contact from switching cleanly for the 749.

After removing the ESP32 completely and restoring the direct reed connection between the water meter and the 749 using Wago connectors, the 749 has been working normally again without any issues

Make sure you didn’t connect the wires the other way around… Also, instead of using internal pullup, use weak external one, similarly your 749 does.

Starting point
• A cold-water meter reed contact is wired into a Superstatic 749 (two conductors: red/white).
• Goal: read the same reed pulses in parallel with an ESP32 (ESPHome) without breaking pulse counting on the 749.

ESPHome configuration
• pulse_meter on GPIO21
• pin.mode: INPUT (no internal pull-up)
• internal_filter tested (started around 20 ms, adjusted during troubleshooting)
• Template: m³ = total_pulses * 0.0001

Parallel “listen-only” wiring
• ESP32 GND connected to 749 GND.
• ESP32 GPIO21 connected in parallel to the reed input line.
• External pull-up on the ESP32 side: resistor between 3V3 and GPIO21
• first 1 MΩ
• then 2 MΩ (two 1 MΩ in series)

Key tests and observations
• Manual GPIO test: shorting GPIO21 to ESP32 GND increments pulses → ESP32 + ESPHome config are working.
• Wire orientation was critical:
• ESP32 GND on red + GPIO21 on white → immediate burst of false pulses (floating/noise).
• ESP32 GND on white + GPIO21 on red → stable at rest (no noise).
→ Practical conclusion: white behaves like GND/COM, red behaves like the signal line in this setup.
• With the stable wiring, the 749 continues to count correctly when water flows.
• However, the ESP32 still does not see real pulses from the reed contact, even while the 749 is counting them.

Voltage measurement
• Measuring between the two reed wires via the spare slots on the Wago connectors (with ESP disconnected) showed about 0.67 V (or -0.67 V when reversing the probes).
• This value was not stable/near the expected pull-up level, so it was not usable to reliably identify GND vs signal from voltage alone. The wire assignment was instead confirmed by the noise vs stability behavior above.

Current working hypothesis
• The 749 input appears to use a very weak pull-up around ~2.3 V. That is fine for the 749, but may be too low/marginal for an ESP32 to reliably interpret as a HIGH level, so the ESP32 never sees clean edges even though the 749 does.

Now if you are sure of the correct polarity, experiment with stronger pullup like 100k.
Don’t go really strong though, it’s likely taking 749 out and it’s not healthy for it.
In that case try with comparator ic or BSS138.

Can I use a Schmitt-trigger inverter (e.g., 74HC14 powered at 3.3 V) instead of a comparator or BSS138 to buffer the reed/749 input and feed clean 3.3 V pulses to an ESP32, while keeping the 749 counting reliably in parallel?

I don’t see why not.

I’ve now tested parallel tapping the Superstatic 749 pulse input using a MOSFET buffer as well, without success.

Setup:

  • The 749 pulse input is a “dry contact” input with ~2.3 V internally and a very weak pull-up (~2 MΩ).
  • ESP32 connected in parallel (common ground with the 749).
  • 2N7000 (TO-92): Gate to the pulse signal (red), Source to GND (white), Drain to ESP32 GPIO21, 10 k pull-up to 3.3 V on the Drain, ESPHome input inverted.

Result:

  • The Drain sits cleanly at ~3.3 V at idle, but when water flows the ESP32 still receives no pulses, while the 749 continues counting correctly.
  • On the reed/signal line I only measure ~0.67 V instead of a clear HIGH level. With that, the 2N7000 doesn’t switch (VGS too low). It looks like the 749 input is extremely high impedance and possibly scanned/sampled.
  • Stronger pull-ups on the signal might raise the level, but they’re risky because they can load/shift the 749 input again, which is exactly the problem with parallel operation.

At this point I don’t think there’s a clean, reliable solution for true parallel operation on this specific 749 dry-contact input.

That mosfet has quite high threshold: V_GS(th) = 0.8–3 V so it might not work here. Try with esp internal pullup or 100k if it helps.

BSS138 has much lower threshold 0.8-1.5V.

ps. if you don’t have those on hands, they are commonly used on level shifters, you can borrow it from there :wink:

Thank you for your support, but at this point I think I will leave it there.

These approaches might work, but not reliably and with the risk of damaging the 749.
There is probably no clean or robust solution for this setup.

Up to you, but I have no reason to think BSS138 would not work on this circuit.
It’s guaranteed to work at >1.5V and from the meter’s perspective, the BSS138 gate is almost an open circuit.

Maybe it would be technically possible, but it would not be a clean or sustainable solution. If there is no robust and reliable option, I will likely have to wait for the planned LoRaWAN migration in about six years.

I disagree. Direct connect with Esp is not clean and sustainable, but mosfet approach doesn’t violate anything to my opinion.

I’m searching since a while to integrate my Superstatic 749 and T30 into Home Assistant, but without any success…

A while ago, NeoVac offered a radio to M-Bus gateway, but when I ask them, they said, they will no longer offer it. I guess because they want to sell their own expensive solution :frowning:

Unfortunately another closed system which does not provide any useful interface.

If OP gave up, you can give it a try with BSS138.
2.3V 2M pullup on reed is tricky, but if 749 can detect it, with correct circuit Esp can read it as well.