Replies: 1 comment
-
Thank you @martgras this is very helpful. I'll start the ball rolling ... Support for User-Defined functionsIn my example, I have a device that talks the Modbus protocol, but uses it's own functionality - correctly in the user-defined function range (https://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf) (chapter 5) which are documented as 65-72 and 100-110. The standard One obvious problem with modbus user defined functions is that they have no pre-defined size, so it's difficult to know where the end of the response packet is. One might wait for the 3.5 byte-size pause and use that, or keep a running check on the CRC waiting for a match (which was my pattern in PR #3461), or declare the size when the command is created (which I think is the cleanest) or perhaps callback to the command class on each received byte (gives best flexibility, but may not be needed). The general push of ESPHome seems to be to try to keep as much stuff in YAML as possible and there are some idiosyncrasies there, so I'd propose that this layer get some extra functionality. I think the something like the following YAML syntax might work sensor:
platform: modbus_controller
user_defined_function: 65
custom_command: [0x1, 0x2, 0x3]
response_length: 6
lambda |-
// do stuff in C++
error_lambda |-
// handle error condition
:
Support for blueprint modbus devicesIt occurs to me that once someone has gone to the trouble to configure a modbus component, crafting the sensors, switches and so on it would be nice to offer that configuration to others who have the same device and don't have time/skills to build it themselves. Currently this can either be done by sharing YAML or by building a custom C++ class. Two styles with their own pros and cons. Maybe there is some way using the ESPHome code gen and a table of data to build what is required? All the Modbus devices I've seen document their coils, sensors and so forth using a bunch of tables, including my device with it's user-defined function usage. I'll think more on this subject. |
Beta Was this translation helpful? Give feedback.
-
I'm creating this thread to collect ideas how to improve modbus in esphome.
One topic is how to make modbus_controller accessible as a base class for new components.
Maybe it's possible just using python without having to use C++
Another topic is dealing with multiple devices. Currently there is a chance that responses are assigned to the wrong device.
The code should ensure that no other request is sent while waiting for a response. Currently all modbus_controller devices should behave correctly but if a device built on modbus only could interfer.
Pull request or any other suggestions are welcome
Beta Was this translation helpful? Give feedback.
All reactions