Edit: I just found this might be ESH core functionality so I copied this to the ESH forum. I apologize for the double posting.
I’m developing an OpenHAB 2 binding that enables us to use some specific advanced Modbus devices. In this scenario each Modbus device can provide any number of different things. Different devices have different capabilities and therefore provide a different set of things. Thus, the modbus node itself will be configured as a bridge that offers access a set of things.
As Modbus is a register based protocol, each thing has a set of modbus registers for configuration values, current status and to commit actions. What I want to do first is to create a configuration for each available thing that maps the configuration registers to OpenHab thing configuration.
For this I need to be able to specify some extra attributes to a parameter (e.g. modbus register). These attributes would be read by the Java implementation of the thing. From what I can find the configuration schemas do not support this. For example this could look like this:
<parameter name="portNumber" type="integer" required="true">
<label>Port Number</label>
<description>Port on the device this thing is using.</description>
<default>1</default>
<advanced>true</advanced>
<attribute name="modbusRegister">120</attribute>
<attribute name="modbusRegisterMode">relative</attribute>
</parameter>
Does anyone have an idea how to accomplish this using the currently available functionality? If not, what are your thoughts about extending the configuration schema to allow name-value attributes?
For ZWave I have the same requirement and I encoded this in the paramater name. So, I need parameter 24, and it might be 2 bytes long, then it would be config_24_2.
You could do something similar I guess and name your parameter portNumber_120_relative or something similar…
Thanks for sharing your solution. Guess I will follow this approach, too. I think of including it to the description and use the ConfigDescriptionProvider to get hold of it. However, this feels so incredible wrong so I hoped that there is “a right way”.
I also found your discussion on this topic now where some guys suggest an external database as a source of this information. In my scenario the set of available things is limited so an extra database would be a bit excessive in this case.
Another approach would be to create a thing class for each supported thing type and add custom annotations to the fields in order to provide the extra information. A custom ThingTypeProvider would then scan for these annotations to create the thing configuration based on the annotations. I looked into other bindings and only found homematic doing something similiar (but without annotations). As I don’t want to reinvent the wheel I opened this discussion.
I know that is a bit academical but what do you think about this approach? Would it be a good solution or drive us to far away from OpenHab best practises? One advantage would be that the custom ThingTypeProvider could call getters and setters to retrieve and update the configuration so the implementation could react on changes (in my case it would read from/write to modbus directly)
public class ModbusNodeHandler extends BaseThingHandler {
@ConfigurationParameter(label="Port Number", description="Port on the device this thing is using.",
defaultValue="1", advanced=true, attributes={"modbusRegister=120","modbusRegisterMode=relative"})
Integer portNumber;
...
}
