Setup an item linked to modbus

Clear I have deleted the poller I had dedicated to reading, linked the connected Things to the write poller and it all indeed still works.

UID: modbus:data:428a658773:fb6fe0acac
label: MB light 3
thingTypeUID: modbus:data
configuration:
  readValueType: bit
  readTransform: default
  writeTransform: default
  writeType: coil
  readStart: "2002"
  updateUnchangedValuesEveryMillis: 1000
  writeValueType: bit
  writeMultipleEvenWithSingleRegisterOrCoil: true
  writeMaxTries: 3
  writeStart: "1002"
bridgeUID: modbus:poller:41de4e2124:428a658773


Looks reasonable. Missing info is the associated poller - what register type and range are you reading? (as you have some coil and some discrete I think?)

I’m still struggling to figure out exactly what you ought to be doing in basic Modbus terms.
Referring to the earlier post #4, I think -

  • Writing directive to coil type registers (FC15) e.g. 1001
  • Reading status from discrete input type registers (FC02) e.g. 2001
  • (and we’re not interested in reading coil state back at all)

So in overview, openHAB binding wants -

Bridge Thing identifying PLC device

Poller Thing identifying discrete register block 2000 to 2008 or whatever

data Things, each identifying discrete bit to read e.g. 2001 and coil to write e.g. 1001

UID: modbus:poller:41de4e2124:428a658773
label: MB Poll read light status
thingTypeUID: modbus:poller
configuration:
  length: 3
  start: 2000
  refresh: 500
  maxTries: 3
  cacheMillis: 50
  type: discrete
bridgeUID: modbus:tcp:41de4e2124

Again, looks reasonable.
Editing stuff in-flight is sometimes problematic for polling bindings, so if having difficulty make sure you have restarted binding (or system) after last best-effort edit.
Still a problem, look in your openhab.log for complaints.

You are 100% correct on the wish, example for light 1:

  • Write to coil register 1000 a “1” using FC1, FC5 or FC15
    * The PLC checks upon detecting the modbus state change if the request is different from the actual state of the output (relais). If it is it will process the request.
    * The PLC will transfer the actual state of the output (relais) to the read register, 2000 in this example.
  • OH is polling this register (2000) (using FC2) and should update its state accordingly
  • When the PLC changes the state via its own input (push buttons) it will ignore the input register (1000) from OH. Switch the output, update the state register (2000).

Writing this down and with all that I learned in the last days (with your help :-)) I think that this is where I make my mistake. I am expecting (assumed) that when OH reads (2000) a state change from this register which its polling, OH will update its write register (1000) with the same state for the PLC to read.

I will do that, with all the editing something must be off… I will re-start from scratch and report back. Feels like I have all the elements to make this work, just have to get the puzzle to fit :slight_smile:
Thanks again for your support, will report back when its fixed!

I’m not quite sure what you think is happening here.
There is no ‘write register’ at the openHAB end, the closest to that would be an Item.
The PLC doesn’t read anything from openHAB, all it knows is what we choose to write to it.

data Thing channel is linked to an Item, the link is bi-directional. But not the same both ways.

Whatever we get from modbus poll/read params is used to update the Item state. Nothing else happens - we don’t re-transmit onto modbus or anything.

Any command sent to the Item is also written to Modbus using write params.

Small update from my side, the setup is now fully functional.

  • One poller for the read actions
  • Thing combines read and write channel
  • Every Thing is linked to one Item of the Type switch with autoupdate set to OFF

Stopping and starting everything resolved my remaining issue.
No rules needed!

I did discover that when defining the Item, I have the category option “lightbulb” or “light”. If you select lightbulb the UI doesn’t update the icon. If “light” is selected it does, I assume this is because the icon set doesn’t include the lightbulb variant.

Dimmers and screens are next!

1 Like