Hi Community,
I’m struggling with a somewhat unusual behavior/layout of my MDT heating actuator. Each channel of the actuator exposes a communication object to set the HVAC mode with data point 20.102 (write operation). To get the status you can:
- Configure the same communication object to be also readable. Unlike normal actuators, that respond with sending out the altered status after writing to its communication object, this actuator doesn’t send out the new status. You have to actively read (poll) it to get the changed status.
- Configure another communication object to send out the changed status, but in a different format having no official data point type. It uses the suggested HVAC Status data type described in the appendix of the data point type specification.
With neither of the two by MDT suggested ways I can manage to define a single knx thing that can be used as an item in OH2.
For the first way I would need to configure a thing channel that would actively read back the state from a second listening address to get the reflected state.
For the second way I need to have basically a thing channel with two different data point types associated with it. One for writing and one for listening as well as an appropriate translation for a common, internal item state.
Any suggestions?
My only solution was to define two channels. One for writing and one for reading. But this leads to a non intuitive way of interacting with this one thing.