Yup, IL ETH BK DI8 DO4 2TX-PAC is Modbus TCP. Somehow I mis-googled that and arrived at the similar Profinet version. Ah well, just hoping there was an intermediate gateway that could be tweaked.
What you’d really like is Modbus function code FC22, which allows the setting of individual bits in a holding register. This is not implemented in the OH binding. (Few slave devices support it).
No matter, Phoenix Contact made their own design decision not to support FC22 either, which does seem odd given that they chose to pack output bits into a holding register. There is simply no possible way to write an individual bit into a holding register over Modbus without FC22. This isn’t just an issue for OH
So for a workaround, the Modbus master must either keep a copy of what it thinks the whole slave register should be, or it must read the reg before re-writing with one bit changed. Neither method is “safe” since there are legitimate ways for the copy to get out of step, or for the register to be altered between read and rewrite.
I don’t think it would be a good idea to implement either method in the binding, forcing the choice upon the user. Both have advantages and disadvantages. Let user create their own item+rule based solutions using bitmasks etc., and appreciate the possible shortcomings.
But you got what you got, and have to work with it somehow
Reading from modbus registers in bitwise fashion (valuetype=bit) is supposed to work for you, providing you set them up as Contact items (read only).
Can you confirm that is or isn’t working as expected?
From the first post, and reading the device manual, it is not clear to me if modbus:tcp.slave1.type=input
should perhaps be
modbus:tcp.slave1.type=holding
(even if it is for digital input bits) or not?
For the output bits I think we’d have to use virtual Switch items, that trigger a rule on change, that manipulates bits in a single Number item, that in turn maps onto the (output) holding register.