feature-requests
feature-requests copied to clipboard
esphome
Modbus TCP
Describe the problem you have/What new integration you would like
Since Esphome is becoming more and more complete system, it would be useful to implement modbus tcp feature.
Please describe your use case for this integration and alternatives you've tried:
It would be useful to connect directly to an Esphome node a Modbus slave TCP device bypassing HA. In this case it would work even HA was down.
Additional context
Agree, it would be great for those remote locations as we could just drop in a small ESPHome and then use wifi backhaul to HA
I would very much like to see the possibility of connecting modbus TCP devices. You can then use esphome as the simplest PLC for home automation with a conditional minimum of costs. An important function may be the ability to switch modbus master/slave modes for possible further integration with other controllers or platforms that have this interface
I'd love to see this implemented too if possible! Having a simple low power esphome device to translate these modbus TCP devices into home assistant would be amazing. My preference would be to have this in esphome rather than using the modbus TCP integration directly in home assistant itself.
Curious as to the exact use case that folks see for this.
It sounds to me like people are looking for the equivalent of mbusd (https://github.com/3cky/mbusd) in ESPHome, translating incoming modbus TCP into Modbus RTU over UART, rather than ESPHome opening a TCP connection to an existing Modbus TCP endpoint, and querying registers?
My particular use case is the former rather than the latter. Ideally, modbus_controller: would have an option to listen on a TCP port (502 by default if enabled?), and translate incoming modbus TCP formatted messages into modbus RTU messages sent over a local UART. Being able to multiplex/interleave these with modbus messages generated by local modbus entities would be ideal, of course, as that would enable ad hoc modbus queries from a network PC to coexist with defined entities without having to flash new firmware all the time.
Possibly having a mapping from Modbus TCP address to Modbus RTU address would also be useful.
That is exactly my use case. I have several appliances designed initially to be connected over an RS485 link. I don't want to run wires between the appliances, but rather put an esphome device in each appliance that connects the appliances over modbus TCP.
That is exactly my use case. I have several appliances designed initially to be connected over an RS485 link. I don't want to run wires between the appliances, but rather put an esphome device in each appliance that connects the appliances over modbus TCP.
One thing to keep in mind is that ModbusRTU has specific latency requirements, and I'm not sure how well trying to convert ModbusRTU to ModbusTCP, transmit over WiFi, then from ModbusTCP back to ModbusRTU will end up working in practice.
What you might have to do in the end is mirror the remote registers locally, so that the ModbusRTU queries can be satisfied immediately, and then update the local copies at whatever interval makes sense.
In my application the baud rate is 9600, so that is pretty slow. Shouldn't that be OK regarding any latencies?
In my application the baud rate is 9600, so that is pretty slow. Shouldn't that be OK regarding any latencies?
This link discusses latencies and timeouts a bit more: https://control.com/forums/threads/response-time-requirement-for-modbus-rtu-master.49674/
The main thing I took from that was that they increased the timeout to cater for the experienced latencies. Not sure if you have control over your appliances' timeouts or not. One way of avoiding the timeouts is to cache the registers locally as mentioned previously. Then, by controlling your own poll frequency of the remote endpoint, you can limit how stale those cached values will be.
Alright, those are all constraints to be considered by the developer of the feature... I was just trying to clarify the feature request and add to the votes for the feature. I wasn't offering to develop the feature, since I haven't the competence (yet).
I was wondering if there was not a way around this, like using a plain serial connection over TCP to convey the raw serial information between the devices, using a custom component like this : https://github.com/oxan/esphome-stream-server. This one only does the server side UART->TCP - the client side is missing (TCP->UART).
If you want just RTU to TCP conversion, there are various dedicated devices which transparently do that (see on Ali).
I've seen even models on 433MHz which are wired on the ends, but wireless in between, even in one master + multiple slaves scenario.
But indeed, timing strictness will tell if they will work or not with your specific units.
Ah, the problem is I don't "just" want that. I have the esphome devices in my appliances to monitor a bunch of sensors and perform settings via HA. Since they are there, it would be efficient to also use them to connect the appliances together. But OK, the dedicated devices could be a fallback position.
Ah, the problem is I don't "just" want that. I have the esphome devices in my appliances to monitor a bunch of sensors and perform settings via HA. Since they are there, it would be efficient to also use them to connect the appliances together. But OK, the dedicated devices could be a fallback position.
Curious about the details of your appliances. I'm contemplating this for an inverter, that can do modbus over RS485. Being able to expand that to an RS485 device some distance away (power meter, for example) might be useful.
The appliances are heaters, where one master heater or a central console applies its settings and measures to the slave heaters through RS485.
If your inverter is a Victron, it does modbus over TCP, which allows you to integrate it in HA. I'm interfacing mine with Shelly energy meters, for which there is some official support, and some hacks for non-officially supported devices.
Hello I'm interested in this request, too. Any news about its development?
+1 I have my inverter installed remote. Inverter have Modbus TCP. Remote location have network, ethernet and WiFi. Remote location can access the Internet.
I would love to have an esphome device connect to my inverter over Modbus TCP and then act as a gateway to some 'public' MQTT broker over TLS on the Internet. Home Assistant would then be able to get all values from my inverter by reading them from the MQTT broker on the Internet.
I have already verified that the esphome device can access the MQTT broker on the Internet (EMQ) and write to topics when at the remote location.
Adding support for Modbus TCP would make my day/week/month/year/millennium and complete the missing link in my config.
Having a remote location where you would like to communicate to something with Modbus TCP and have it report back to your HA can not be that uncommon, right?
Regards,
/Jonas...
Here's another use case for Modbus TCP which I'm exploring: emulating a Fronius "smart meter" based on data read from the P1 port on the utility electricity meter. I've been using the latter (based on https://github.com/psvanstrom/esphome-p1reader) for more than a year now, feeding the meter readings into OpenHAB where they are used in combination with readings from the (Fronius Gen24) inverter and power pricing prognoses to switch on/off high power consumers. This works fine but there is one piece missing: the capability to limit power export when the electricity price goes below a given level. I can of course simply tell the inverter to stop producing when the electricity price goes so low that we'd have to pay to feed electricity in to the network but that is not a good solution because we'd end up paying taxes and 'transport charges' for imported electricity - the price level at which we end up paying for feed-in is much higher than the price level at which we'd end up being paid to import electricity due to those taxes and 'transport charges'.
If the inverter knows the power flow at the grid connection point it can limit production to just what is needed locally so as to (mostly) eliminate feed-in. The Fronius-provided solution for this consists of a separate 'smart meter' which is to be installed at the grid connection point, after the utility meter. This meter connects to the inverter over Modbus (RTU or TCP) using the SunSpec protocol standard which makes it an easy target for emulation. I currently run a MQTT-to-Modbus bridge which achieves this goal, the inverter happily takes its output and presents it as if it is produced by a Fronius smart meter. This works but it is more complicated than needed and the solution does introduce some extra latency which could be avoided by adding a Modbus TCP slave to the P1 reader. I have a somewhat working prototype based on Tasmota but it is not reliable enough to be used in earnest, mostly due to the fact that the Modbus implementation is written as a Tasmota script. It is also limited to running on an ESP32 while I'd like to keep on using the current ESP2688-based hardware. Having a 'real' Modbus slave implementation in Esphome might make it possible to achieve the goal of having the P1 reader speak both MQTT as well as Modbus, eliminating the need for the MQTT-to-Modbus bridge.
@Yetangitu ESPHome already supports being a server (aka slave) as ModBUS RTU. I even think this is better than TCP because it excludes single points of failure like network hardware in between. So you could simply emulate Fronius Smart Meter directly connected to the inverter's ModBUS RTU port with an RS485 transceiver.
Sure, direct serial connection is likely preferable for the reasons you state (and latency, etc). It's not always convenient (or wise) to run a direct serial connection if distance is a factor, or if the only path is alongside the existing mains wiring, etc, etc. In which case, having the TCP option makes it feasible again.
@Yetangitu ESPHome already supports being a server (aka slave) as ModBUS RTU. I even think this is better than TCP because it excludes single points of failure like network hardware in between. So you could simply emulate Fronius Smart Meter directly connected to the inverter's ModBUS RTU port with an RS485 transceiver.
Yes, that would be an option but that would involve two separate devices - the P1 reader at the utility meter and a device connected to the inverter acting as a bridge - while I already have a device attached to the utility meter which could double as a Modbus slave. The inverter supports Modbus TCP which is how I currently emulate the smart meter, running a MQTT-to-Modbus bridge in a container on the server-under-the-stairs. Once esphome supports Modbus over TCP - and that is important, running a wire between the P1 reader on the utility meter and the inverter is a bad idea given that they are more than 60 m apart (utility meter in the house, inverter in a barn). It is not just a log of work to draw the wires, the real problem is that such long wires produce large induced currents when lightning strikes nearby. This has already cost us a number of network cards, two printers, six modems (damaged by induced currents in the phone lines back when we still had copper-based ADSL), two DECT base stations, a television and more. I have repaired most of this damage but I know better than to run long stretches of wire between sensitive devices.
Modbus TCP could be the solution to my 'problem', as said I have a working prototype using Tasmota but I'd prefer a more solid approach, preferably one which can run on an ESP8266.
I understand your points.
Me willing to help - the actual reality is, that while ModBUS RTU is available already in ESPHome (master and slave) and it's actually a pretty well working solution, the ModBUS TCP is not and likely won't be until somebody contributes it.
So for you instead of just having to endlessly wait and watch for the problems you currently face, maybe it would probably worth throwing another ~$5 for an ESP + RS485 to your likely ~$3000 value inverter and test the solution with the existing available feature set. Just my trying to be constructive suggestion.
Your case is not something that just "would be nice"... Imho every experiment is worth the effort.
Or I have a look at implementing Modbus TCP given that it seems to be a feature worth having and most likely not that hard to implement. After all, I already have a working solution - the software bridge I linked to - which does not involve the complications of adding another single-purpose device.
It is not a money problem, it is a matter of principle. The P1 reader is only one step away from the data source - the utility meter - so it is the most logical spot to implement this functionality. Adding bridges, whether those be software bridges as I'm using now or hardware ones in the shape of another ESP hooked up to the inverter is a good work-around but less than optimal.
i would like to connect to my heatpump with an esp32c3 with esphome. it seams to me, easyest way is modbus tcp: https://dimplex.atlassian.net/wiki/spaces/DW/pages/3303571457/Modbus+TCP+Anbindung
in home assistant it works fine with:
modbus:
- name: "dimplex_si8tu"
type: tcp
host: !secret wp_ip
port: !secret wp_modbus_port
binary_sensors:
- name: "dimplex_si8tu Digital"
address: 2
slave: 1
slave_count: 207
input_type: coil
scan_interval: 5
unique_id: dimplex_si8tu_digital
but there is no possibility with esphome?
I reasearch solution to update remote node on AVR over ModbusRTU, with commands: 0x14 - Read File Record 0x15 - Write File Record described here https://github.com/emelianov/modbus-esp8266/tree/master/examples/Files so using esphome as proxy ModbusRTU <=> ModbusTCP its a way.
But this means I can't read my heat pump via Modbus TCP via WLAN?
At this stage, I believe the answer is no.
mit ein bisschen anpassung sollte es damit gehen https://github.com/mortenx/modbustcp_wifi_esphome
mit ein bisschen anpassung sollte es damit gehen https://github.com/mortenx/modbustcp_wifi_esphome
aber da ist keine anleitung dabei. ich verstehe nicht ganz wie die anpassungen aussehen müssen