Now follow the User Guide of the CMI on how to setup CAN over Ethernet (COE). Here you will map your outputs that you configured in the previous step. As the target device you need to put the IP of your OpenHAB server into the coe.csv. Don’t forget to reboot the CMI after you uploaded the coe.csv file.

The refresh interval should be very small. The execute method of the binding blocks waits for new messages coming in for 10 seconds. If nothing has been received then the method is being restarted after the refresh interval has passed. If new data has been received then the first message is processed and the method is being restarted after the interval has passed. Messages are being processed one by one. Therefore, if you receive multiple message from the CMI, which is most likely the case, it always waits for the time configured in the refresh interval, before it processes the next one.

The binding supports all 21 measure types that exist according to the TA documentation. Unfortunately, the documentation is not consistent here, so most of the types are supported only by generic names. The known measure types are:

For the known measure types the binding also deals with the necessary scaling factors. All other measure types would be read "as is", so you might need to scale them accordingly. If you are able to figure out one of them, please update the binding or drop a note to @Wolfgang1966

The total energy collected is split up into two measures (KWh and MWh) due to the limited range of analog values. To convert them, use a rule like this (UVRKwh and UVRMwh contain the received measures):

There was a bug in the CMI that messed up the UDP messages sent for analog outputs. As a workaround do not use the outputs 4, 8, 12, 16 and 17-32 in TAPPS2. The bug might have been fixed with recent updates of the CMI. This has not been tested though.

When defining an item that is being used as a digital input in your TAPPS2 then the binding only supports to use Digital Input 1. This is due to the way the COE protocol works as all 16 digital ports are being send within one message.

For Analog Inputs it is only possible to use Analog Inputs 1, 5, 9, 13 in TAPPS2. This is also due to the way COE works as for analog messages it will send then in bundles of 4. You can however use multiple CAN nodes. According to TAPPS2 you can use CAN nodes from 1-64. So if you only have one UVR and the CMI then you should have 62 nodes available for use. I would not use the same item for sending and receiving even though that should be possible of you use one of the supported ports. Instead I would use separate items and then use rules to get the functionality that you want to achieve. That way it should be possible to have a switch item that is being updated by a CAN output and when you send a command to it, then it uses a different item with a different CAN node that maps to a CAN Input in TAPPS2. I have not tried this though yet.