Hi Nanna,
If I remember correct from earlier posts and by reading your snippet, you are using a Carlo Gavazzi Sx2WEB controller?
I use a SH2WEB and am just now converting from modbus v1 to v2.
My questions is: the modbusmap from SH2WEB is scattered with registers so we have to read the registers function by function (Smarthouse-function that is). Does this mean you make a bridge for every single function you want to control?
/Per
Hi Per
Yes iâm using SH2WEB, in the modbus memory map on the controller, I tend to group registers to avoid having too many bridge pollers.
I group all light functions in one, all temperature in one etc.
Best Nanna
Tnx for answering.
Is it a problem or bad praxis to use a poller per thing?
In ver1 I had a slave for each item, appr 150 slaves. It has worked very well.
As I understand it a poller would be equivalent to a slave in the old binding?
Regards
Med vÀnlig hÀlsning,
Per
Itâs much more code, but beside that I donât know.
Itâs easy to group it on the controller, so I went for that approach .
Best Nanna
I have a TCP/IP modbus gateway with two RTU Slaves with ID30 & ID38
Would there be any problems, since the gateway shares the same IP address
Bridge modbus:tcp:kamstrup [ host="192.168.100.143", port=502, id=38, connectMaxTries=3] {
Bridge modbus:tcp:endpointNilan [ host="192.168.100.143", port=502, id=30 ] {
I have two seperate âThingsâ definition files
No problem.
Guys I need your help.
I have used Modbus with OH1 for more then a year without problems. Now I have migrated to OH 2.3. One of major problem which I still have is Modbus.
So my config in OH1 looks like follows (just one item example):
serial.went_temp.connection=/dev/ttyUSB0:9600:8:even:1:rtu serial.went_temp.id=10 serial.went_temp.start=16 serial.went_temp.type=input serial.went_temp.length=6 serial.went_temp.valuetype=int16
and item:
Number Went_Temp_Zewn_M (Wentylacja) {modbus=âwent_temp:0â}
Now I have added binding via PaperUI, which is: binding-modbus1 - 1.12.0
and got std problem with lack of connection:
2018-10-11 21:17:50.955 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - Last request: 0a 03 00 04 00 03 45 71 2018-10-11 21:17:50.958 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - failed to read: CRC Error in received frame: 0 bytes: 2018-10-11 21:17:50.961 [ERROR] [pi.modbus.io.ModbusSerialTransaction] - execute try 1/3 error: I/O exception - failed to read. Request: net.wimpi.modbus.msg.ReadMultipleRegistersRequest@b1071 (unit id 10 & transaction 54). Serial parameters: SerialParameters@7e8781[portName=/dev/ttyUSB0,baudRate=9600,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=even,encoding=rtu,echo=false,receiveTimeoutMillis=1500]
Hardware is std USB/RS485 adaptor, it is working well, when I connect via python script.
Then I have tested the newest binding 2.4.0-SNAPSHOT which I just copied to addons - same issue.
I have tested older bindings, including that one from OH1 - same issue.
Any ideas ?
Do I need to change smg in congig file (I just remove binding name) ?
Does OH2 should work with Modbus1 as it was in OH1 ?
Yes, but the config details live in a new place, not openhab.cfg. Youâve probably worked that out already.
The new Modbus2 binding is completely different, and configured in a completely different way. It wonât work just sticking it in addons, and will probably cause problems until you get rid of it from there.
Decide which way you want to go before investing a lot of effort, then I would recommend starting a new thread for your problem and not bury it amongst 200 other posts about alpha testing.
I prefer to stay with Modbus1, since it was working very well. Now I have many other issues with migration (new server, new OS, etc) , so prefer to make it work on OH2.
If Modbus1 should work on same config (I know that addons config now is splitted) so where can be a problem ?
Hi there and sorry if this post is a bit off-topic.
Iâm running OH with 90% of all my house using modbus devices.
My Nilan ventilation system is giving me some challenges - random my TCP/IP modbus gateway loses serial communication, a simple reboot of the gateway is enough to get the system up running for a day or two.
Until now I have used the lastReadError Channel ID type to determ a problem, and then send a reboot to the gateway with a telnet command.
I donât like this âdirtyâ workaround, but how can I debug this error on the serial side?
Some gateways allow you access to a serial data log. That might or might not be helpful if itâs messing up.
You might use an old laptop as a serial monitor, listening to the serial line. You could use the same setup to simply poll the Nilan when things are âbrokenâ, to be sure that its the gateway messing up.
Make sure your serial line is terminated, and screened if itâs going near mains wiring.
Hello, Iâve running this binding in OH 2.4 on an RPi3, but I have troubles with the CPU usage. Now Iâve seen a strange behavior when Iâm looking into the logs:
2018-10-19 21:36:05.624 [vent.ItemStateChangedEvent] - hvt01Vrltemp changed from 63.1 to 64.7
2018-10-19 21:36:05.749 [vent.ItemStateChangedEvent] - hkr01Vrltemp changed from 35.1 to 35.8
2018-10-19 21:36:06.326 [vent.ItemStateChangedEvent] - hvt01Vrltemp changed from 64.7 to 63.3
2018-10-19 21:36:06.605 [vent.ItemStateChangedEvent] - hkr01Vrltemp changed from 35.8 to 35.2
The item is updated very fast but my refresh in the poller is set to 10000, so why are there so often updates to the items?
Most likely a queue of poll data has formed, due to system being busy with other things. Common during system startup for instance.
When the binding gets time to process the queue, it then looks like several polls happen in quick succession.
If it doesnât catch up and return to normal fairly quickly, you might have to track down the system bottleneck.
Your assessment sounds correct.
I would like to improve this behavior . Polling should slow down if the rest cannot handle it (e.g due to slow persistence).
You can follow progress on this issue https://github.com/openhab/openhab2-addons/issues/4135
Hi Sami (@ssalonen)
Today I tried to do some capturing with wireshark to figure out why I have from time to time some error logs. Unfortunately I am not able to see a single TCP package from OH to my Modbus server or vice versa. I expect to see simple TCP packages which I could capture by using the IP address of OH or my Modbus server as filter condition.
Is my expectation correct?
Best regards
Raphael
Yes⊠With tcp slaves you should see tcp packets with wireshark 
Donât forget if you are running wireshark on some other box you might need to enable a port on your router/switch as monitor.
Hi
I capture some TCP telegrams with wireshark to figure out why I see some error logs. For me it looks like, that OH didnât realize that the TCP connection got closed (even though OH ACK the FIN telegrams ) and sends the next request, which will be responded with a RST telegram. The slave will start to close the TCP connection with a FIN telegram. OH will ACK but do not send a FIN telegram to close the connection complete. I have the following setup:
Is this an issue of the binding or the TCP stack?
Wireshark printscreen:
Modbus TCP slave:
Best regards
Raphael
Yeah I guess it looks like that, my interpretation (client = OH, server=modbus slave)
Similar situation happens in the beginning of the log?
I am wondering what is the ACK at 3454 (and 2951)?
Btw, hereâs how the socket is configured in the java side: jamod/src/main/java/net/wimpi/modbus/net/TCPMasterConnection.java at main · openhab/jamod · GitHub
EDIT: I think we are having a half-closed connection. Server has cut down the connection but client â server connection is still active. It might we have the situation described here: Orderly (and Abortive) Connection Release in Java
Another common scenario, which may result in an unintended
SocketException, is the following: Say A has sent data to B, but B closes the socket without reading all the data. In this situation, Bâs TCP stack knows that some data is effectively lost and it will forcibly terminate with RST rather than use the orderlyFINprocedure. A will get aSocketExceptionif it then tries to send or receive data from the socket.
It might be that once the server sees that itâs getting new data from the pipe (the client->server pipe that is, it was never closed), it just tells to abort the connection, with RST.
I think the binding is checking that half-open connections would not be used â basically see the isConnected check here. I wonder if that is working or not hereâŠ
