Creating Device to Evesdrop on I2C Bus - Need Guidance

ESPHome
1

First time trying to create and ESP32 device - I’m working to reverse-engineer the output of a water flow meter that’s part of my home filtration system. The meter is on a proprietary and expandable bus speaking I2C. I’ve used a logic analyzer to gather enough data samples to understand the communication but I don’t know how to parse and publish meaningful data in ESPHome.
The meter reports 4 bytes of data from 3 registers - for now, I only want to publish 2 bytes from one read command when they’re non-zero. The communication is repeating and is structured is like this:

Address | Read/Write | Data                | Command?
  0x51         W       0x01, 0x04, 0x00      0xAC
  0x51         R       0x00, /0x00, 0x00/    0x2E
  0x51         W       0x03, 0x00, 0x00      0xAC
  0x51         R       0x00, 0x00, 0x00      0x2E
  0x51         W       0x04, 0x00, 0x00      0xAC
  0x51         R       0x00, 0x00, 0x00      0x2E

The data I want to publish is from the 1st read command (highlighted in green) and only the 2nd and 3rd bytes. I need to avoid publishing for every read because the bus traffic is constant after an hour of idle water flow.

I don’t think I can use the I2C “Component” because it causes the controller to act as a device on the bus and isn’t passive. I found an I2C sniffer that will publish everything it hears up on the bus (esphome_i2c_sniffer) but I’d like to filter the data by address and further-limit publishing to non-zero values as mentioned above. Can someone please help me get started with this?

2

Make a copy of that repo (even just locally). Add the additional constraints you want in the loop() function and only call publish if the conditions match.

3

Hey, I recently made a similar thing. It’s not (yet) a generic i2c-sniffer, but the sniffing component can possibly be used to filter more than my targeted scd40-CO2-sensor. Caveat: this was created solely by ChatGPT. If you ask it to adapt it to your use case, it might be quite simple to get to run.

4

Thanks for the offer! I ended up vibe coding this as well. It makes me feel dirty that I couldn’t figure it out for myself, but I can’t argue with the results!

5

Hehe, it’s always a question of how much resources you’re willing to sink into it. And sinking LLM-resources into it might cost a few bucks, but doesn’t take away much from your own resources :smiley:

I for one am impressed with how it handled the reverse engineering both of the i2c protocol as well as the (ac based) probing of the temperature and humidity sensors. And the implementation of the Sensirion-BLE-protocol. And the creation of a complete schematic to replace my protoboard. Quite the rabbithole.