Replying publicly to your question: I did indeed have an issue with modbus TCP before, see Modbus TCP integration
My issue was different though in the sense that I wanted quick feedback (push button events). In the end, I did find that the vendor of the hardware provided their own translation of the modbus events into websockets, which I in turn then translated into MQTT events, for which home assistant has excellent support.
The custom component you mention is a step further then just using the already available modbus integration. A custom component means you hook your own code into the home assistant ecosystem. Check the development docs for that: https://developers.home-assistant.io/
As I understand it, for developing your custom component the idea is:
provide some (python) code that can interact with your sensor (since it’s modbus, this will probably be a thin wrapper around pymodbus, https://pymodbus.readthedocs.io/en/latest/).
provide your custom component code that calls this stand-alone library.
The home assistant community likes this approach because:
it doesn’t need to live (and be maintained by) in to core home assistant code – it gets pulled in instead when required
pushing for more open libraries means an overall global better IoT open source landscape
Another thing you mentioned was a hassio-addon. I don’t use hassio myself, but I suspect this is some kind of addon to make it possible for you to connect your (containerized) home assistant core instance to the peripherals on the host system (?) Before you get any deeper into that, please make sure you understand the networking model of hassio, the addons and home assistant core: https://developers.home-assistant.io/docs/supervisor#architecture.
tl;dr: I would recommend to check out whatever’s just possible with the built-in home assistant modbus integration, before trying anything else.
Just to mention esphome has started to integrate ezo sensors. The ezo library seems to have support for other ezo devices. I am using it with hum ezo even though it’s not documented.
The carrier board has an i2c mode. You should be able to just connect it to an esp. I2c is a chainable communication standard, each device gets an address and connects to the same ports. All the ezo devices are well documented and already individually addressed to work with each other.
Hi Mikefila thanks for your reply but I am being dumb. How do you go about connecting the Atlas EZO sensors to ESP? My sensors are connected to the Tentacle 3 board and do use i2c. However the ESP install instructions state to connect to the sensor device to a usb port. My sensors (on tentacle 3) are connected to the rasp pi 4 and they do not have a usb connection.
The rasp pi does have a usb connection but the esp install indicates I need a usb to usb micro connection.
I connect it straight from the carrier board to the i2c inputs on my esp. The T3 that you have is the i2c version?
If so you should be able to power the T3 and connect the T3’s i2c output directly to an esp. Don’t stack the board on a pi. The pin out for the T3 is here.
Don’t stack them on a pi, you can stack 2 boards on top of each other. i2c is bus that you can add multiple sensors to. The problem you will have is if you need to run 2 of the same type of sensors.
Like 2 ph probes, they each need to be set to different addresses. The come pre set to address but can be changed.
I have my ezo circuits on a tentacle 3 board on a separate Pi than the one running HA. That other Pi runs Atlas IoT and through MQTT provides sensor data to HA.