From verbose logs we should be able to see what data the binding is polling exactly.
Would be interesting to see verbose logs for this sequence of events…
One thing to check out is any warnings regarding queue size in the log. With verbose logs you can find out the binding queue size, it should stay small.
It’s not clear what you mean here. The value reverts to 100 after 20 seconds?
As your OH config is for a uint32 type, you should read two holding registers with modbus tool, just in case there is something going on in the “other half”.
Have a look in events log for the “mystery” Item value change, then you’ll know where to look in the debug log. There should be many successful read polls before that?
Brilliant fix! So, you’ve now got a working Dimmer Item with two different Modbus channels? Ah no, wait, this is just one holding register pair now isn’t it?
The transform may be circumventing some issue with number/string formatting or parsing into percentage. Might tie in with reported different Number/Dimmer behaviour?
The two lines of log? No… I would need more to really dig into this. Ideally would be the whole sequence of events, starting from command from openHAB, value changing, and then value reverting back start (e.g. your case mentioned here).
Really would appreciate all the help!
Best,
Sami
EDIT:
I think I know what might be the reason, with a similar setup (reading & writing to holding register, using dimmer, no transformation), I have the following in the verbose logs
xxxx will be updated to 'ON' (type OnOffType). Input data: number value 60 (value type 'uint16' taken into account) and bool value t
So numeric value of 60 is converted to ON. Logic is explained more thoroughly here: Modbus - Bindings | openHAB (Transform On Read section)
The default is to convert non-zero numbers to ON / OPEN , and zero numbers to OFF / CLOSED , respectively. If the item linked to the data channel does not accept these states, the number is converted to best-effort-basis to the states accepted by the item. For example, the extracted number is passed as-is for Number items, while ON / OFF would be used with DimmerItem.
The behaviour is meant to be smart with Switch etc items (converting numeric values to “boolean” values) but obviously a bit unexpected with DimmerItem. Since Dimmer items accept ON/OFF, the same piece of logic applies to it as well (a bit unexpectedly, I admit).
Humm, bit debatable whether automatically converting a number read from a Modbus register to a Dimmer Item would be a good idea.
Given the variety of manufacturers devices (although dimmers are rare!) I would not think that numeric100 representing 100% is guaranteed. 255 seems just as likely.
Not to consider we’re (usually) dealing with 16-bit values … or as in this case, 32-bit.
We’ve already had this conversation, I bet?
Requiring a transform to scale a register to a Dimmer Item doesn’t seem unreasonable. Even for the odd time it is effectively a no-op transform.
It would be a good idea to make this clear in the docs, an example would be helpful.
Out of interest, is it just chance that the write side works here? I imagine that would often need scaling/transform as well.
OpenHAB Dimmer type Items are not a straightforward match to Modbus registers, as they feature a numeric value which is limited to 0-100 Percent, as well as handling ON/OFF commands.
Transforms can be used to match and scale both reading and writing.
Example for a dimmer device where 255 register value = 100% for fully ON :
Thing definition
// Wrap everything in a function (no global variable pollution)
// variable "input" contains data string passed by binding
(function(inputData) {
// here set the 100% equivalent register value
var MAX_SCALE = 255;
// convert to percent
return Math.round( parseFloat(inputData) * 100 / MAX_SCALE );
})(input)
dimwrite255.js
// variable "input" contains command string passed by openhab
(function(inputData) {
// here set the 100% equivalent register value
var MAX_SCALE = 255;
var out = 0
if (inputData == 'ON') {
// set max
out = MAX_SCALE
} else if (inputData == 'OFF') {
out = 0
} else {
// scale from percent
out = Math.round( parseFloat(inputData) * MAX_SCALE / 100 )
}
return out
})(input)
Item
Dimmer myLight "My Dimmer" { channel="modbus:data:remoteTCP:MBDimmer:DimmerReg:dimmer" }
The example looks good! I just noticed one small thing, the writeValueType should be int16, there’s no such thing as uint16 when writing. Second thing was missing braces (}) in the things snippet.
Woah, is that so? Seems a little asymmetric. I haven’t tried it, does it fail ? Or are we just talking about the logic - because an OH Number covers the range of both uint16 and int16 without worry.
Is there an implication that to write hex FFEE to a register, you’d need an OH Number of -18 for int16, rather than 65518 for uint16? Or do both varieties just give the same result automagically? (65518 technically “won’t fit” into int16 but I’m sure the binding can just do it anyway on a write) Just a bit worried about truncation of numbers over 32767, the theoretical max for int16.
