I found some details on the SMA inverter I was trying to communicate with.
I’m trying to read the Input registers (Uint32 and Int32), normally read length of 2.
This is not working with SMA, if I set the length to 4 it works perfectly - but why?
It seems to be problem/bug with the device, see discussion here https://github.com/openhab/openhab1-addons/issues/4931
Best
Sami
Thanks Sami, good to know that I haven’t “lost” it.
Hi Sami,
seems like that doesn’t work with textually configured things:
2018-06-22 23:38:57.718 [INFO ] [st.core.internal.thing.ThingResource] - Received HTTP PUT request for update configuration at 'things/modbus:poller:wc101:coils/config' for an unmanaged thing 'modbus:poller:wc101:coils'.
Best,
Max
@andrey I believe you messaged me privately as well?
Unfortunately I can’t help you with the Synology, sounds like something special needs to be done with this device.
The README of GitHub - openhab/openhab-syno-spk: openHAB Synology SPK Install Package says that
For Z-Wave and Devices that use dev/ttyACM0 or dev/ttyACM1 will at install a script copy to /usr/local/etc/rc.d that will execute install or on Boot. This exec on the Port´s chmod 777. And load some USB Kernelmodules. To make these it´s necessary to enter on Installation the Admin Password from DSM.
By looking into pacakge.tgz, you can find openHAB-zwave.sh:
sudo insmod /lib/modules/usbserial.ko
sudo insmod /lib/modules/ftdi_sio.ko
sudo insmod /lib/modules/cdc-acm.ko
sudo chmod 777 /lib/modules/usbserial.ko
sudo chmod 777 /lib/modules/ftdi_sio.ko
sudo chmod 777 /lib/modules/cdc-acm.ko
sudo chmod 777 /dev/ttyACM0
sudo chmod 777 /dev/ttyACM0
Perhaps something similar is needed for your serial port? You might consider opening a new thread regarding serial port configuration with Synology.
Best,
Sami
@zacofunny, can you please try out with the latest version?
We now have caching in place (used only with REFRESH commands) to avoid spamming the modbus, see cacheMillis parameter of poller in docs.
Default cache is now 50 ms which probably cuts out the majority of REFRESH calls.
@mbs38 Thanks for trying it out! I will try to figure something out for you .
Will first get the PR merged, and then introduce additional improvement to tackle this…
All, I noticed that the Marketplace was pointing to 2.3.0-SNAPSHOT allthough 2.4.0-SNAPSHOT is the latest.
Please try out with this new version! All feedback is now highly appreciated since the code is about to be merged to main openHAB code base.
Hi! I will try it asap! Thanks for your hard work!
You are welcome Sami. Thx for tackling this issue.
Btw: I’m really looking forward to the merge. I’ve got a friend who has another huge Modbus-Installation (~50 devices spread over multiple serial ports, >1500 I/Os). I am excited to see how the new binding is going to perform there 
Hi, I’m back 
The situation is:
- I have set up new instance of openhab (stable 2.3) and put latest snapshot of the binding
- I have set up logging to TRACE
- I have currently set 102 things (colis). Note: This is only part of the system
Current configuration (full config contains 799 markers(coils) as stated below):
Bridge modbus:serial:fatekplcusb0 "FatekPLC_USB0" [ baud=115200, timeBetweenTransactionsMillis=60, cacheMillis=500, connectMaxTries=1, stopBits="1.0", parity="none", receiveTimeoutMillis=1500, dataBits=8, echo=false, encoding="rtu", flowControlIn="none", port="/dev/ttyUSB0", flowControlOut="none", connectTimeoutMillis=10000, id=1 ] {
Bridge poller coils_Y0_to_Y255 "FatekPLC_Poller_Y0_to_Y255" [ start=0, length=256, refresh=1000, type="coil" ] {
// Note the zero based indexing: first coil is index 0.
Thing data FatekPLC_Modbus_Y0 "FatekPLC_Modbus_Y0" @ "Modbus" [ readStart="0", readValueType="bit", writeStart="0", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_Y1 "FatekPLC_Modbus_Y1" @ "Modbus" [ readStart="1", readValueType="bit", writeStart="1", writeValueType="bit", writeType="coil" ]
}
//M0 to M799
Bridge poller markers_M0_to_M799 "FatekPLC_Poller_M0_to_M199" [ start=2000, length=800, refresh=2000, type="coil" ] {
// Note the zero based indexing: first coil is index 0.
Thing data FatekPLC_Modbus_M0 "FatekPLC_Modbus_M0000" @ "Modbus" [ readStart="2000", readValueType="bit", writeStart="2000", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M1 "FatekPLC_Modbus_M0001" @ "Modbus" [ readStart="2001", readValueType="bit", writeStart="2001", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M2 "FatekPLC_Modbus_M0002" @ "Modbus" [ readStart="2002", readValueType="bit", writeStart="2002", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M3 "FatekPLC_Modbus_M0003" @ "Modbus" [ readStart="2003", readValueType="bit", writeStart="2003", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M4 "FatekPLC_Modbus_M0004" @ "Modbus" [ readStart="2004", readValueType="bit", writeStart="2004", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M5 "FatekPLC_Modbus_M0005" @ "Modbus" [ readStart="2005", readValueType="bit", writeStart="2005", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M6 "FatekPLC_Modbus_M0006" @ "Modbus" [ readStart="2006", readValueType="bit", writeStart="2006", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M7 "FatekPLC_Modbus_M0007" @ "Modbus" [ readStart="2007", readValueType="bit", writeStart="2007", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M8 "FatekPLC_Modbus_M0008" @ "Modbus" [ readStart="2008", readValueType="bit", writeStart="2008", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M9 "FatekPLC_Modbus_M0009" @ "Modbus" [ readStart="2009", readValueType="bit", writeStart="2009", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M10 "FatekPLC_Modbus_M0010" @ "Modbus" [ readStart="2010", readValueType="bit", writeStart="2010", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M11 "FatekPLC_Modbus_M0011" @ "Modbus" [ readStart="2011", readValueType="bit", writeStart="2011", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M12 "FatekPLC_Modbus_M0012" @ "Modbus" [ readStart="2012", readValueType="bit", writeStart="2012", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M13 "FatekPLC_Modbus_M0013" @ "Modbus" [ readStart="2013", readValueType="bit", writeStart="2013", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M14 "FatekPLC_Modbus_M0014" @ "Modbus" [ readStart="2014", readValueType="bit", writeStart="2014", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M15 "FatekPLC_Modbus_M0015" @ "Modbus" [ readStart="2015", readValueType="bit", writeStart="2015", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M16 "FatekPLC_Modbus_M0016" @ "Modbus" [ readStart="2016", readValueType="bit", writeStart="2016", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M17 "FatekPLC_Modbus_M0017" @ "Modbus" [ readStart="2017", readValueType="bit", writeStart="2017", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M18 "FatekPLC_Modbus_M0018" @ "Modbus" [ readStart="2018", readValueType="bit", writeStart="2018", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M19 "FatekPLC_Modbus_M0019" @ "Modbus" [ readStart="2019", readValueType="bit", writeStart="2019", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M20 "FatekPLC_Modbus_M0020" @ "Modbus" [ readStart="2020", readValueType="bit", writeStart="2020", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M21 "FatekPLC_Modbus_M0021" @ "Modbus" [ readStart="2021", readValueType="bit", writeStart="2021", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M22 "FatekPLC_Modbus_M0022" @ "Modbus" [ readStart="2022", readValueType="bit", writeStart="2022", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M23 "FatekPLC_Modbus_M0023" @ "Modbus" [ readStart="2023", readValueType="bit", writeStart="2023", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M24 "FatekPLC_Modbus_M0024" @ "Modbus" [ readStart="2024", readValueType="bit", writeStart="2024", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M25 "FatekPLC_Modbus_M0025" @ "Modbus" [ readStart="2025", readValueType="bit", writeStart="2025", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M26 "FatekPLC_Modbus_M0026" @ "Modbus" [ readStart="2026", readValueType="bit", writeStart="2026", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M27 "FatekPLC_Modbus_M0027" @ "Modbus" [ readStart="2027", readValueType="bit", writeStart="2027", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M28 "FatekPLC_Modbus_M0028" @ "Modbus" [ readStart="2028", readValueType="bit", writeStart="2028", writeValueType="bit", writeType="coil" ]
Thing data FatekPLC_Modbus_M29 "FatekPLC_Modbus_M0029" @ "Modbus" [ readStart="2029", readValueType="bit", writeStart="2029", writeValueType="bit", writeType="coil" ]
//Thing data FatekPLC_Modbus_M30 "FatekPLC_Modbus_M0030" @ "Modbus" [ readStart="2030", readValueType="bit", writeStart="2030", writeValueType="bit", writeType="coil" ]
This is my current Fatek config:
With this configuration it works without issues thaat I have had before, however I’m not satisfied since i observe the following behavior when I turn on/off switch:
2018-07-03 23:05:05.815 [ome.event.ItemCommandEvent] - Item 'Kitchen_Bar_Table_Light' received command ON
2018-07-03 23:05:05.865 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light changed from OFF to ON
2018-07-03 23:05:07.430 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light changed from ON to OFF
2018-07-03 23:05:09.590 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light changed from OFF to ON
2018-07-03 23:05:09.604 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light_GH changed from OFF to ON
2018-07-03 23:05:19.819 [ome.event.ItemCommandEvent] - Item 'Kitchen_Bar_Table_Light' received command OFF
2018-07-03 23:05:19.850 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light changed from ON to OFF
2018-07-03 23:05:21.715 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light changed from OFF to ON
2018-07-03 23:05:23.718 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light changed from ON to OFF
2018-07-03 23:05:23.729 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light_GH changed from ON to OFF
2018-07-03 23:05:51.028 [ome.event.ItemCommandEvent] - Item 'Kitchen_Bar_Table_Light' received command ON
2018-07-03 23:05:51.043 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light changed from OFF to ON
2018-07-03 23:05:51.731 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light changed from ON to OFF
2018-07-03 23:05:53.808 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light changed from OFF to ON
2018-07-03 23:05:53.813 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light_GH changed from OFF to ON
2018-07-03 23:06:00.017 [ome.event.ItemCommandEvent] - Item 'Kitchen_Bar_Table_Light' received command OFF
2018-07-03 23:06:00.042 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light changed from ON to OFF
2018-07-03 23:06:00.272 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light changed from OFF to ON
2018-07-03 23:06:04.150 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light changed from ON to OFF
2018-07-03 23:06:04.163 [vent.ItemStateChangedEvent] - Kitchen_Bar_Table_Light_GH changed from ON to OFF
So when I switch light on, it turns on correctly however the status bar in habdroid turns on, then off then on again. The above log shows it as I described. Same behavior I see in Basic UI.
A least it sets the correct state in the end, however only if I wait for the full cycle. If I do it too quickly the state sets often to wrong value.
Great to hear it’s now working!
The behavior you see with states is expected. Openhab updates item state automatically when commands are issued.
Please read the following post on autoupdate : Rule to postUpdate an Item works but Item falls back after some seconds
You might want to disable autoupdate with your items.
Sami
1 Like
Will see yet . This is still not the full amount of things I have. There is at least tripple of what is currently configured 
and I still didn’t touched holding registers or inputs. Will keep you informed.
Thanks for the hint with autoupdate. Appreciate it. I will try to see if this helps.
Great, thanks!
Make sure you update to latest version, there was a bug with the latest version, see Possible performance of bindings?
I’m running stable 2.3. Can I request for link to the latest version? Versions at marketplace seems to be not up to date?
I think the versions are up-to-date? 2.4.0-SNAPSHOT (you can check the date once you have installed the binding).
1 Like
Hi,
I have the Modbus serial working in version 1 but in the v2 I’m having some dificulty to understand how to do the same thing. Can you help me ssalonen. First I would like to start with a simple example of reading a light meter and showing the values. After I will add one more sensor, for example, a temperature sensor. And after I will add a switch to control a LED. I’m using an arduino in the hardware side.
V1 - led.sitemap:
sitemap demo label="Modbus Smart House"
{
Frame {
Text item=LightSensor icon="light"
}
Frame {
Text item=Temperature icon="temperature"
}
}
V1 - led.items
Number LightSensor "Light Sensor [%d LUX]" { modbus="slave2:0" }
Number Temperature "Temperature [%.1f °C]" { modbus="slave2:1" }
V1 - modbus.cfg
modbus:poll=5000
modbus:serial.slave1.connection=/dev/ttyUSB0:19200:8:none:1:rtu:35:1500:none:none
modbus:serial.slave1.type=holding
modbus:serial.slave1.id=1
modbus:serial.slave1.start=1
modbus:serial.slave1.length=2
The V1 example above It’s working and I unsderstood the way it works. But Trying to make the same thing in V2, I don’t know how It works. Specially the modbus.things.
V2 - modbus.things
Bridge modbus:serial:endpoint [ port="/dev/ttyS0", baud=19200, id=1, stopBits="1.0", parity="none",dataBits=8, echo=false, encoding="rtu", flowControlIn="none", flowControlOut="none", receiveTimeoutMillis=1500 ] {
Bridge poller poller1 [ start=0, length=2, refresh=500, type="holding" ] {
Bridge readwrite readwriteCollector {
//Thing read read1 [ start=0, transform="default", trigger="*", valueType="int16" ]
Thing read read2 [ start=1, transform="default", trigger="*", valueType="int16" ]
// Thing write write1 [ start=0, transform="default", trigger="*", valueType="int16", type="holding" ]
}
}
}
V2 - modbus.items
Number NumberItemTest "Number readwrite [%d LUX]" { channel="modbus:readwrite:endpoint:poller1:readwriteCollector:number" }
V2 - modbus.sitemap
sitemap modbus label="Modbus"
{
Frame {
Text item=NumberItemTest
}
}
I’m available to collaborate in the wiki to add serial examples, after I understand how to do it.
The v2 config you use (e.g. readwrite) is no longer working. It was a “side-step” during the development of this new binding.
Please refer to docs for up-to-date examples.
Let me know if you have issues
best
Sami
But in the documentation there are only full examples for TCP connection. Not for serial RTU.
Reading the documentation I came into this.
V2 - modbus.things
Bridge modbus:serial:endpoint [ port="/dev/ttyUSB0", baud=19200, id=1, stopBits="1", parity="none", dataBits=8, echo=false, encoding="rtu", flowControlIn="none", flowControlOut="none", receiveTimeoutMillis=1500 ] {
Bridge poller poller1 [ start=1, length=2, refresh=500, type="holding" ] {
Thing data NumberItemTest [ readStart="1", readValueType="int16" ]
}
}
V2 - modbus.items
Number NumberItemTest "Number readwrite [%f]" { channel="modbus:data:endpoint:items:NumberItemTest:number" }
V2 - modbus.sitemap
sitemap modbus label="Modbus"
{
Frame {
Text item=NumberItemTest
}
}
Is this correct?