I’m trying to use the ModBus serial binding with a new ABB power meter. Unfortunately the registers are at non-traditional addresses, for example active power can be read from address 23316. As I understand it, modbus is gradually moving away from the traditional addressing standard, hence this issue. Is there any likelihood that the Openhab modbus binding will allow the use of non-traditional addressing at any point?
In case it is an M2M/DMTME device it shoud comply to this document: https://library.e.abb.com/public/635fd2b8ca9d770ac12578cb0023448f/2CSG445011D0201.pdf
The Modbus-Binding can easily be set up to read data from these devices using this pdf file as a reference.
However, the document above doesn’t state that a register at address 23316 cointains the active power value.
What kind of ABB power meter are you refering to?
[mbs38] mbs38 https://community.openhab.org/users/mbs38
November 5In case it is an M2M/DMTME device it shoud comply to this document:
https://library.e.abb.com/public/635fd2b8ca9d770ac12578cb0023448f/2CSG445011D0201.pdfThe Modbus-Binding can easily be set up to read data from these devices
using this pdf file as a reference.However, the document above doesn’t state that a register at address
23316 cointains the active power value.
What kind of ABB power meter are you refering to?
Mine is a B21-212-100. The documentation is at
https://library.e.abb.com/public/cb70f205c20e8970c1257b98004c5b0b/2CMC485004M0201_A_en_B21_User_Manual.pdf.pdf
Nigel
Have you tried it, what is the problem? I guess you mean that 23316 (x5B14) falls outside the old school 9999 (x270E) upper boundary. So far as I know the OH binding (I assume you are using version 1.9) doesn’t implement that limit and will address up to 65535 (xFFFF)
Shouldn’t cause any trouble.
Well, the input register values in Modbus span from 30000 to 39999 and the power register in the B21-212-100 is at 23316 (0x5B14). If I want to read it how do I specify it in the openhab config file? The only way I can think of is to use a negative offset, so for example
modbus:serial.slave1.connection=/dev/pts/8:38400:8:none:1:rtu
modbus:serial.slave1.type=input
modbus:serial.slave1.start=-6684
modbus:serial.slave1.length=2
may work, but it seems a bit of a kludge. Remember input registers start at 30000 so a start of 0 corresponds to 30000. I’ll have to unwire the meter from the existing system that’s reading it (Misterhouse) and bring it over to Openhab and see if that works. I was hoping that the author of the modbus binding might be able to give me a definitive yes or no before I went to that length. Ideally there would be a global configuration variable that would flip between traditional and absolute addressing and if I was more experienced with Openhab and java I’d probably implement it, and possibly will at some point in the future.
No, that’s not the issue. The issue is that traditionally, input registers fall between 30000 and 39999. The Modbus binding documentation goes so far as to explicitly say that it implements these limits. Hence my problem. I’m currently reading the meter on a different machine with a perl script and a hacked CPAN library module that allows me to specify an absolute address. This works fine.
Oh, and by the way I’m using 1.9. I should have said that at the beginning.
Modbus numberings are a bit funny. 39999 really means input type register number 9999. What actually goes out on the Modbus protocol are commands to implement Input-type reads at address 9999. 39999 is never ever sent.
So for OH binding for that example you would specify an ‘input’ type at start address 9999. (or more likely 9998 see the one-out comment later)
In your case, the meters docs talk about Modbus functions 3, 6 and 16. These are all Holding register functions, so these are the ones that should concern you just now. ‘Traditional’ holding registers span 40001-49999, but again the 4 is really only indicating the type and the 9999 is the ‘real’ reg number. Have another look at the addressing part of the Wiki
Although the original 1980s Modbus spec limited the address part to 9999, that is pretty arbitrary and there is no practical reason it cannot actually span up to the limit of a 16-bit number, 65535, sometimes called extended addressing.
Don’t overcomplicate it, just use the values straight from the meter docs
Something like
modbus:serial.meter.start=23316 # hex 5B14
modbus:serial.meter.length=1 # just one item
modbus:serial.meter.type=holding # this is the equivalent of the 40000 stuff
modbus:serial.meter.valuetype=int32 # double length signed, the docs say
You’ll need to pay attention to the meter data type (16, 32-bit, signed etc.) as you get further in.
There is a further confusion with Modbus addressing, 40001 register number gets transmitted as Holding register address x0000. There is a one-out effect. But where manufacturers quote hex addresses as in the case of this meter, they are almost certainly low-level protocol addresses that you can use as is within OH. OH ‘counts from zero’ as almost everybody does these days.
1 Like
That’s extraordinarily helpful and thanks for taking the time to explain (and read the meter documentation). It’s all starting to fall into place at last (even though I’ve been using this particular meter for nearly two years now). I cudgelled my brains over this when I first installed these meters and got it working by hacking the CPAN code (with the help of the CPAN module author, who I’m now convinced didn’t really understand Modbus addressing either). I’m now ready to move this pair of meters over to Openhab from Misterhouse and I’ll make the attempt this afternoon. Fingers crossed everything will work. I’ll let you know what happened.
OK, not a lot of success. I’ve added the two slaves as below
Main meter
modbus:serial.mainmeter.connection=/dev/ttyUSB1:9600:8:none:1:rtu
modbus:serial.mainmeter.id=10
modbus:serial.mainmeter.start=23316 # hex 5B14
modbus:serial.mainmeter.length=1 # just one item
modbus:serial.mainmeter.type=holding # this is the equivalent of the 40000 stuff
modbus:serial.mainmeter.valuetype=int32 # double length signed, the docs say
Annex meter
modbus:serial.annexmeter.connection=/dev/ttyUSB1:9600:8:none:1:rtu
modbus:serial.annexmeter.id=11
modbus:serial.annexmeter.start=23316 # hex 5B14
modbus:serial.annexmeter.length=1 # just one item
modbus:serial.annexmeter.type=holding # this is the equivalent of the 40000 stuff
modbus:serial.annexmeter.valuetype=int32 # double length signed, the docs say
And a couple of items
/* Power meters */
Number MainMeter “Main power [%d]” (Power, g_Chart_power) {modbus=“mainmeter:0”}
Number AnnexMeter “Annex power [%d]” (Power, g_Chart_power) {modbus=“annexmeter:0”}
All I get in the log is
14:12:45.122 [DEBUG] [o.b.m.internal.ModbusActivator:30 ] - Modbus binding has been started.
14:12:45.130 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item ‘MainMeter (Type=NumberItem, State=Uninitialized)’ with ‘ModbusGenericBindingProvider’ reader.
14:12:45.135 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item ‘AnnexMeter (Type=NumberItem, State=Uninitialized)’ with ‘ModbusGenericBindingProvider’ reader.
14:12:45.206 [DEBUG] [.modbus.internal.ModbusBinding:290 ] - modbusSlave ‘annexmeter’ instanciated
14:12:45.210 [DEBUG] [b.m.internal.ModbusSerialSlave:41 ] - overriding modbus port: null by: /dev/ttyUSB1but there is currently only one port supported
I’ve added openhab to the dialout group so I don’t think it’s a permissions problem.
Any ideas?
Try the troubleshooting stuff in the Wiki. You don’t seem to be getting any polling / poll failures in your log, suggesting some basic issue.
Hmm… well I’ve done the troubleshooting stuff (actually I was running the log in debug mode anyway). I’ve done a bit more since. The modbus binding just doesn’t seem to be even attempting to open the serial port, fuser shows that the port isn’t owned by anyone. Openhab is in the dialout group and minicom allows me to open the port so there isn’t a permission problem. My next thing is going to be to try using the tty0tty loopback to see if I can see any traffic.
A bit more information. I thought that I’d test to confirm the access of openhab to the USB serial ports that I’m using (I’m using an 8 port USB->serial adapter). I know that other programs can access these ports and work fine with them but this was the first openhab port to try. I decided to try the serial binding with another port on the same adapter. The serial binding seems to work fine and fuser shows that the port is bound to the Openhab process, so the problem seems to rest fairly and squarely with the modbus binding which just doesn’t seem to want to even open the port. I wonder if anyone else can confirm using the modbus binding with a USB->serial convertor on a Raspberry Pi.
And I wonder if someone can confirm that I’m not doing anything stupid with my connection configuration.
Got it!
It was the comments at the end of the line that the configuration file didn’t like, so not
modbus:serial.mainmeter.connection=/dev/ttyUSB1:9600:8:none:1:rtu
modbus:serial.mainmeter.id=10
modbus:serial.mainmeter.start=23316 # hex 5B14
modbus:serial.mainmeter.length=1 # just one item
modbus:serial.mainmeter.type=holding # this is the equivalent of the 40000 stuff
modbus:serial.mainmeter.valuetype=int32 # double length signed, the docs say
but
modbus:serial.mainmeter.connection=/dev/ttyUSB1:9600:8:none:1:rtu
modbus:serial.mainmeter.id=10
modbus:serial.mainmeter.start=23316
modbus:serial.mainmeter.length=1
modbus:serial.mainmeter.type=holding
modbus:serial.mainmeter.valuetype=int32
Looks like it’s polling happily now. Just need to sort out the data type.
many thanks for all the help.
Now all working. One final tweak
modbus:serial.mainmeter.connection=/dev/ttyUSB1:9600:8:none:1:rtu
modbus:serial.mainmeter.id=10
modbus:serial.mainmeter.start=23316
modbus:serial.mainmeter.length=2
modbus:serial.mainmeter.type=holding
modbus:serial.mainmeter.valuetype=int32
is working (the length needed to be 2 because it was fetching 2 x 16bit registers). Both meters are now reporting active power in 100ths of a W. Many thanks to rossko57 for help.
Well, I’m back here. Having happily used the Modbus 1 binding since 2016 I’m now trying to migrate to the Modbus 2 binding and it’s just not working. I know the hardware is fine because it’s been working since 2016 but Modbus 2 just doesn’t seem to allow a holding register at address 23316. Is this a backward step or am I misunderstanding things again?
What makes you think that? It’ll be fine.
What’s your config, what happens?
v2 Binding docs include a guide for migration
Note in particular changes to ‘length’, which counts standard registers. Meaning a 32-bit value occupies two 16-bit holding registers.
Thanks for your encouragement (again). I spent 3 hours last night trying to get this working, through PaperUI and although I could get the serial slave bridge installed and it came online the corresponding poller stayed offline. The comments in the poller setup UI seemed to imply that holding registers were indexed from 40000 which is why I eventually gave up in despair and went to bed (mind you, despair comes easily at 1.30 in the morning). I’ve read and re-read the migration guide (it’s now seared onto the backs of my eyeballs). Do you think it’s worth trying to configure the whole thing using text files?
I may try that next… hold the front page.
Clock another one up to stupidity and working too late.
I wrote the config in as text files this time which helped me get things clear in my mind.
It was the old problem of udev created serial port links not being recognised as valid serial ports by openhab2. I had the modbus serial port on /dev/USBmodbus which was linked to /dev/ttyUSB1 via a udev rule. The error log entry confused me by talking about a permission problem and I checked that openhabian was in the dialout group (which it was). Eventually the penny dropped and adding the /dev/USBmodbus to /etc/default/openhab2 fixed the problem.
I still reckon that the comments on register addressing in the paperUI click and drool interface (and in the binding documentation) is confusing, but then I’m a bear of very little brain and Long Words Bother Me.
Thanks again to rossko57. You are an ever-present help and encouragement in trouble.
1 Like