Alright, let’s have a go. One step at a time -get the reading working first.
If I understand right, you need to read the DO register 40303 for light circuit states, and we’ll eventually want to write Vlag at 40305, but we’ll need to read too for binding bitwise operations.
The 40xxx is an odd Modbus convention that tells us its holding register type.
Looking at your screenshots of your QMod utility, the Adam names register 40305 at protocol address 304 (hex 0130) so we need to be aware of the “-1 address” issue.
I advise naming Things and channels relating to the Modbus slave device e.g. DO01 and leaving Items to have the meaningful names like CowshedLights.
So, based on your original things and assuming you want to use a xxx.things file (as I would myself)
// ADAM device 1
Bridge modbus:tcp:wohnhaus01 [ host="192.168.0.152", port=502, id=1 ] {
// poll regs DI,DO,GCL
Bridge poller wh01 [ start=300, length=6, refresh=500, type="holding" ]
{
// read DO as bits
Thing data do01 [ readStart="302.0", readValueType="uint16" ]
Thing data do02 [ readStart="302.1", readValueType="uint16" ]
... etc
Thing data do16 [ readStart="302.15", readValueType="uint16" ]
// read Vlag as register, we will write bits using profiles
Thing data vlags [ readStart="304", readValueType="uint16", writeStart="304", writeValueType="uint16", writeType="holding" ]
} // end of poller
} // end of device
Will you be defining Items using files, or with the UI? UI probably advisable for OH3, but I will give example in old xxx.items file mode and you should be able to see how to create it in UI
Names of your choice.
// Item representing a lighting zone
Switch Cowshed "Cowshed lights" {channel="modbus:data:wohnhaus01:wh01:do01:switch"}
// each zone partnered with a simulated pushbutton
Switch Cowshed_pulse "Cowshed push" { channel="modbus:data:wohnhaus01:wh01:vlags:switch" [ profile="modbus:bit", bit-index="0" ], autoupdate="false", expire="1s,command=OFF" }
// Item representing next lighting zone
Switch Yard "Yard lights" {channel="modbus:data:wohnhaus01:wh01:do02:switch"}
// partner pushbutton
Switch Yard_pulse "Yard push" { channel="modbus:data:wohnhaus01:wh01:vlags:switch" [ profile="modbus:bit", bit-index="1" ], autoupdate="false", expire="1s,command=OFF" }
... etc
Note that all the pulse Items are linked to the same data Thing, but using the brand new bit profile feature to select write bit. I hope the binding version enabling this feature is in the OH snapshot!
The Item names are deliberately related in zone-pulse pairs, because we’ll make use of that in rules later.
I’ve suggested disabling autoupdate on the pulse Items, so that we manage the Item state separately from any commands in rules.
Autoupdate can stay by default on the light zone Items for a quickUI response.
The 1-second expire will “un-push” the simulated pushbutton when we begin to use it. I’m pretty confident this will work satisfactorily without the short mS pulse, but we can revise later if needed (without using expire)
Try all this, see if it configures error-free, and see if you can monitor the actual lights. (there shouldn’t be much to see in pulse yet).
We’ll add rules for control when confident that we can read.
Is it correct?
