Hey Sami,
Yes, ur test-client worked. But the setup didn’t work with my hardware.
Thanks for reply.
Could you please use the pollmb python script to read the registers from your real slave?
Does that show the bits as you would expect?
Best
Sami
Even more weird stuff inside the log.
- The log file in the installation does not match the addons folder. For example, MQTT is mentioned even though that addon is not installed
- still the log files that do not match the code
- you have something else listening the same port (causing the errors in the beginning of the log)
The above might be explained that two installations were logged to the same file. From line ~6300 onwards it seems to match the zipped addons.
Here’s the findings
- All read requests seem to go through as expected
- slave responds with error 2 when writing the data. Error 2 means Illegal data address:
20:24:54.064 [ERROR] [.b.modbus.internal.ModbusSlave:324 ] - ModbusSlave (slave1): error when executing write request (net.wimpi.modbus.msg.WriteSingleRegisterRequest@13abd5): Error Code = 2
Are the logs against the diagslave test server or is it against the real hardware? With diagslave you should not get that error. With real hardware you can get that error if the address is wrong, or you read too many registers (outside allowed memory area).
I would recommend
- check registers addresses (see error above)
- checking the reads with
pollmbor modpoll (modpoll -m tcp -t4 -r 8009 -c 2 192.168.0.20should do it if polling holding register 8008-8009 (zero based index like in openhab)).
Are you sure you want to read holding registers or is input registers that you are really interested in?
Best,
Sami
Hey Sami,
The log is Interesting for you from the last Openhab-Start in the log. I
Think it was around 20:25 or maybe later. Because of the new installation I
had first fix the many errors I had.
Yes it’s tested with real hardware.
Yes I have 3 holding registers (with digital outputs) that I try to
control. They are starting from adress 8007 length 3 registers. At this
special error I changed start to 8008 but not changed length to 2. That was
causing the error. From adress 8000 starting there are 7 register with
digital inputs but first I want to get the outputs working because it’s
easier for me to see the results.
But anyways I will do some testing with pollmb und you please have a look
at the end of the log-file with the “working” openhab-setup.
I hope u understand my (maybe) bad English.
Marcus
Yeah if it works with the test server I’m out of leads. Let’s hope testing with the tools help.
Best
Sami
pollmb is working flawless. there must be something wrong the binding.
pi@raspberrypi:~/pollmb $ python pollmb.py -h 192.168.0.20 -p 502 -t 2 -f 6 -a 8007 -q 1 -d 0123
Contacting Modbus host at 192.168.0.20 port 502 timeout 2.0 sec.
Sending Modbus function: 6, addr: 8007, qty: 1, data: 0123 for 1 polls at 1 msec
1: Reply was: function: 6, data: 0123
pi@raspberrypi:~/pollmb $ python pollmb.py -h 192.168.0.20 -p 502 -t 2 -f 6 -a 8008 -q 1 -d 0123
Contacting Modbus host at 192.168.0.20 port 502 timeout 2.0 sec.
Sending Modbus function: 6, addr: 8008, qty: 1, data: 0123 for 1 polls at 1 msec
1: Reply was: function: 6, data: 0123
pi@raspberrypi:~/pollmb $ python pollmb.py -h 192.168.0.20 -p 502 -t 2 -f 6 -a 8009 -q 1 -d 0123
Contacting Modbus host at 192.168.0.20 port 502 timeout 2.0 sec.
Sending Modbus function: 6, addr: 8009, qty: 1, data: 0123 for 1 polls at 1 msec
1: Reply was: function: 6, data: 0123
In the log u see again the same behavior. It looks like that openhab is not using the valuetype=bit and is ignoring it.
How can we check if the binding is using the valuetype?
That is the question that will lead us to a solution.
Hi excellent you got that tool working!
I’m afraid I don’t quite understand the test you made . Could you please use the python tool to read the data? You are now writing the data which a different operation.
The binding uses function code 03 to read holding registers. The examples you pasted use fc06 which should actually just echo the request (see http://www.simplymodbus.ca/FC06.htm).
So ultimately you cannot determine what the slave actually does with the write request…
BestSami
Get Outlook for iOS
Here is this what u wanted?
1st i write data to my register. And 2nd i read the data. This is working fine.
pi@raspberrypi:~/pollmb $ python pollmb.py -h 192.168.0.20 -p 502 -t 2 -f 6 -a 8008 -q 1 -d 0123
Contacting Modbus host at 192.168.0.20 port 502 timeout 2.0 sec.
Sending Modbus function: 6, addr: 8008, qty: 1, data: 0123 for 1 polls at 1 msec
1: Reply was: function: 6, data: 0123
pi@raspberrypi:~/pollmb $ python pollmb.py -h 192.168.0.20 -p 502 -t 2 -f 3 -a 8008 -q 1
Contacting Modbus host at 192.168.0.20 port 502 timeout 2.0 sec.
Sending Modbus function: 3, addr: 8008, qty: 1, data: 0000 for 1 polls at 1 msec
1: Reply was: function: 3, data: 0123
pi@raspberrypi:~/pollmb $
But still the big question is why is the binding ignoring the valuetype paramter in my openhab.cfg?
Is there maybe a writing-mistake or else?
Ok I think I now realized the reason for this confusion.
I better you changed (turned on/off) the switches in the openhab?
I was so focused on your original problem of reading the data I forgot that non-16bit register types are supported in the binding when writing data. This limitation is actually documented in the documentation as well
Conversion rules for converting command to 16bit integer
UP, ON, OPEN commands that are converter to number 1
DOWN, OFF, CLOSED commands are converted to number 0
Decimal commands are truncated as 32 bit integer (in 2’s complement representation), and then the least significant 16 bits of this integer are extracted.
Note: The way Decimal commands are handled currently means that it is probably not useful to try to use Decimal commands with non-16bit valuetypes.
So I believe reading has worked all along, but if you flip the switches, the register data gets set to zero or one thus making many bits to zero. Then the read result might not match what you expected.
You have at least two options to workaround this limitation
- do not use valuetype bit, and use int16 instead, but let the whole register represent the bit value. Naturally this is wasteful in terms of memory usage (16 bits represent single boolean)
- use valuetype int16 and do the bit extraction in the rules. Similarly you can handle commands in the rules to modify single bit. Requires auxiliary item for the register data, and somewhat complex rules
I’m personally using the first approach as the memory is no issue for my modbus slave.
Best
Sami
Hey Sami,
Do you have a simple example rule for me?
I don’t know how to do this.
And maybe it’s interesting for others.
Or is this functionality in the next version of the binding?
Marcus
Hi Marcus
No I don’t have a rule straight away but I did try it some year ago so it should be possible. In the end, it just bit operations which are supported by the rule language.
I would recommend trying the other option if possible.
Regarding next versions, Who knows? It’s community effort after all 
personally I think I’m not be able to put time for this. Unfortunately there are not many people contributing to this binding I think.
Currently I’m working to get the transformation support to the binding and after that I’m planning to look how could we make modbus fit better in openhab2 (things, channels etc).
Best
Sami
Edit : but this feature is kind of important. Now there is read support for all kind of values, eg 32bit floats etc but no writing support. The functionality is kind of asymmetric…
Yes that functionality is more than important!
Now i bought another buscoupler which support more common modbus-function-codes. But that is an expensive solution…
Thank you for trying to help me!
Bye
Btw refer to this thread for the original discussion of considering valuetype on write
Also notice this github issue
Best
Sami
I would exercise caution about developing bitwise typing for Modbus registers. The concept “makes no sense” in the underlying protocol, which only permits 16-bit register writes. (After all, for bitwise operations Modbus expects you to use coils and contacts instead of registers).
So there would be a difficulty in supporting bitwise write of a register - you have to re-write the whole 16-bit unit in the slave. There is a debate there about what you rewrite it with, where do the other 15-bits come from? Perhaps the binding should first read the existing slave register, or perhaps it should hold an image of what it thinks the register was last time it looked (or wrote it)? All that is really a circumvention attempt around the rules of the protocol, either way is clumsy.
Same would apply to bytewise handling.
Much more straightforward to handle multiples of course - 32 bits etc. But still hammering a square peg into a round hole.
1 Like
Going back a stage, aren’t these devices Profinet? You’re using some kind of Profinet<>Modbus gateway? I wonder if the root issue here is a configuration issue, the gateway mapping Profinet contacts to Modbus registers?
These devices are modbus. If you don’t trust me read their manual.
And there are many industrial devices out there that does not support coils
or discrete inputs, because normally Modbus protocol is only register-based.
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.
1 Like
The inputs are working. I have bought another phoenix-device: FL IL 24 BK.
It supports coils and I will use it only for my outputs.
The other 2 devices which I already have I will use for my inputs. That’s a
working solution for me.