Woah, you only want one. I think you’re running into the USB port name changing problem
You cant have more than one serial slave. Delete those two at 9600 baud. Make sure the last one is online. Then configure from there.
Yes, I already tried this, and now the only slave is myNilan. Tried again to pull out the USB-stick and re-insert. The same thing as before happened: For a short while all went green “Online” but after 1-2 minutes they all went “Offline-communication_error” . Now only the Modbus Serial Slave myNilan is online - everything else offline. Any idea if it would be risky to try to change the two wires in A/B?
Any sensible RS-485 hardware is designed to be proof against wire reversal.
So, feel free to swap, but at your your own risk.
It makes no sense to unplug the USB stick all the time. The Rpi is not Plug&Play in any way.
Insted make use of restarting (rebooting) your Rpi.
I doubt it will do any harm to switch the two wires. (A and B). But dont try switching the Ground wire. That could cause serious problems…
Tried that, and also followed Kims advise to reboot. The change of A/B gave at least one physical change: Apart from the constantly lid yellow LED, now for the first time the LED two places away from the yellow LED now blinks green (appr. 1 time every second). I take this as a confirmation that the connection is now correct. That was not the case before. Also this time it took considerably longer time before the Things turned from “Online” to “Offline”. All, except some of the “Regular Poll” Things were green initially, but now again they are all “Offline” except the slave.
Could the cable be the problem?
On the USB stick there are three leds, yellow, green and red.
Yellow should be solid lit.
Green and red will flash when data is send/received.
Thanks. The green LED flashes, but never seen a single glimpse from the red LED. Had a spare Serial2USB (another brand without LED’s) and tried to connect it. The same behaviour: All Things go online for 1-2 minutes, then goes offline. Now I removed the stick completely, but “Modbus Serial Slave” is still marked as online 
I will order a new cable, and then see what happens. Will not be delievered before Tuesday/Wednesday next week.
Thanks for all your help, and have wonderful Easter Holiday 
Unfortunatly thats typical for many devices/bindings… I fail to understand why.
The cable I use is just plain ordinary UTP (network cat 5e solid core) cable… Works just fine. I have aprox 7 meter.
You might have multiple slaves attached to a serial line.
and
The binding cannot know if a device is broken until it tries a transfer.
So
When a transfer fails, all the binding can know is that particular poller Thing is broken, and should not assume the whole serial bus is broke.
So
When a failure puts a poller Thing in error, the binding will carry on and try the next poller (even if it uses the same serial Thing)
Until
each individual poller has its own failure.
Many thanks Kim. I need approximately 10 meters, and have just ordered a cable with 5x0,25mm2. With a little luck they will put it in the parcel box at the collection centre so I can pick it up Saturday.
You will need twisted pair cable for a 10m run.
Thanks rossko. I believe I have seen somewhere that twisted pair is not recommended for this wiring. And as I currently am using a normal Cat5e, with very thin copperwires, I have ordered a non-twisted 0.25mm2 to secure a good connection. Can I use an ordinary Cat5e, or can you recommend a cable better suited for this job?
I do not understand why the red LED never glimpse. I have checked that all cables are properly connected both on the Nilan device and in the USB-plug.
??
Please check any RS485 reference.
Got things up and running! Found out from another thread that Nilan apparently have started to not connect the plug to the CTS602 print. Haven’t in my wildest fantasy thought of that as a possibility, and simply do not understand why they have chosen that strategy, but after I got this fixed, everything is now working.
Thanks to you and rossko57 for all your help, and also thanks for sharing your work. Would never have been able to do this on my own
Nilan are just plain and simple stupid… On my device, the pins are connected to the plug just fine. But userFuction isn´t… It really makes no sense at all. How come they dont connect everything option… I really dont get it.
Glad you got it sorted!
Sorry to bother you @rossko57 but I need an advice regarding my Nilan modbus setup…
It turns out for some reason, I can not change the state of a specific documented register of the Nilan devices. I´m pretty sure it has been setup correctly.
Now I wonder if there is any easy way to troubbleshoot this one, to make sure, its a document issue?
In detail:
According to Nilans modbus document of registeres, register input #100 should be available.
My things file is rather simple, and the other registers are working just fine. So I assume this is not a modbus setup issue:
Bridge poller 100Registers [ start=100, length=17, refresh=6000, type="input" ] {
Thing data inp100 [ readStart="100", readValueType="int16" ]
Thing data inp101 [ readStart="101", readValueType="int16" ]
Thing data inp103 [ readStart="103", readValueType="int16" ]
Thing data inp105 [ readStart="105", readValueType="int16" ]
Thing data inp106 [ readStart="106", readValueType="int16" ]
Thing data inp107 [ readStart="107", readValueType="int16" ]
Thing data inp113 [ readStart="113", readValueType="int16" ]
Thing data inp114 [ readStart="114", readValueType="int16" ]
Thing data inp115 [ readStart="115", readValueType="int16" ]
}
And my items:
Switch nilan_Input_UserFunc "User function [%s]" <boy_2> (gNilan) {channel="modbus:data:myNilan:100Registers:inp100:switch" }
What happens is, when I activate the switch to ON. It goes back to OFF within a second or two, which leads me to think, this command is beeing rejected by Nilan for some reason.
So is there anyway easy to troubbleshoot this one, and to confirm, this really is a Nilan issue? I have a feeling the device simply dont have the register 100 at all. But it makes no sense, which 100 shouldn´t be working.
Another theory is, that this register doesnt accept ON/OFF at all… But according to the consol, the status of the item is OFF… So I guess thats not the problem:
openhab> smarthome:status nilan_Input_UserFunc
OFF
openhab>
This is what happens in the log, when I try to switch it ON:
2020-04-15 14:00:27.223 [ome.event.ItemCommandEvent] - Item 'nilan_Input_UserFunc' received command ON
2020-04-15 14:00:27.274 [nt.ItemStatePredictedEvent] - nilan_Input_UserFunc predicted to become ON
2020-04-15 14:00:27.294 [vent.ItemStateChangedEvent] - nilan_Input_UserFunc changed from OFF to ON
2020-04-15 14:00:32.622 [vent.ItemStateChangedEvent] - nilan_Input_UserFunc changed from ON to OFF
It goes back to OFF after 5 seconds.
There is a simular problem with the register 113… Its userfuncion2. But this maye be due to my Nilan device is not having the optional and special Userfunction2 board installed. It only has UserFuntion1.
I really need an advice how to get futher with this issue, where to troubbleshoot. Maybe debugging or something other to do?.. Its starting to bother me.
There’s no details given for writing. You have to be explicit, the binding does not assume you want to write to the same register in the same format. This allows deliberate configuring of read-only channels … which is what this currently is.
The Modbus binding will not attempt writing here.
The next time a read poll is performed, the Item will get set to the real device state again.
The binding docs suggest setting autoupdate false for writeable, polled Items (when you get that far!)
EDIT - looking more closely, these are Input register types. In Modbus, these are by design read-only.
I do not think Nilan’s “User function” is what you think it is i.e. it’s an input not an output.
Hmm… There is a holdning register as well for this…
There is a detail missing in my previous post.
The UserFuncion is a function which has it own program in the device. It can be activted from an external switch (pushbutton), which has to be wired directly to the device. This is the switch I normally use to active the UserFunction, and its working just fine.
But in my search for way to active it through modbus, I simply cant get it to work…
The input register 100, does not change, when I activate UserFunction by the use of the external pushbutton. Which tells me, it doesnt really read the state at all.
Insted the holdning register 123 do read the state of the UserFunction when activated through the external switch.
Thats why I thought that input register 100 must be the way to activate the funktion through modbus.
This is the holdning registers:
When I active holdning register 123 from openhab modbus, the same thing happens. It goes ON and a few seconds after, it goes back to OFF.
When I activated UserFunction by the use of the external pushbutton, holding register 123 goes to ON for the time the UserFuction is programmed to be ON.
I really wonder if this is not possible with modbus at all. And it doesnt explain what input register 100 doesnt change at all. There is something odd going on, or I´m missing something.
This is my things for holdning register:
Bridge poller holdingRegisters [ start=100, length=28, refresh=6000, type="holding" ] {
Thing data hol100 [ readStart="100", readValueType="int16" ]
Thing data hol102 [ readStart="102", readValueType="int16" ]
Thing data hol103 [ readStart="103", readValueType="int16" ]
Thing data hol123 [ readStart="123", readValueType="int16", writeStart="123", writeValueType="int16", writeType="holding", writeMultipleEvenWithSingleRegisterOrCoil="true" ]
Thing data hol125 [ readStart="125", readValueType="int16", writeStart="125", writeValueType="int16", writeType="holding" ]
Thing data hol126 [ readStart="126", readValueType="int16", writeStart="126", writeValueType="int16", writeType="holding" ]
}
This is my item:
Switch nilan_Output_UserFunc "User function active [%s]" <boy2> (gNilan) {channel="modbus:data:myNilan:holdingRegisters:hol123:switch"}
But again… The very same thing happen. It goes ON for a few seconds, and then back to OFF.
PS. I know about the autoupdate=false… But in this case I´m glad I didnt use it, cause then I would be able to see it goes back to OFF 
I’ve no idea how your Nilan should function.
You cannot ever write to an Input register over Modbus, so that’s straightforward.
If the Nilan does not like you writing to a Holding register, it will either say so or will ignore the write, either event will be visible in your openhab.log
If it does accept the write, I’ve no idea what it might do with it.
EDIT - You seem to expect this User Function should manifest as some kind of binary on/off; note that holding/input registers are 16-bit numbers. Maybe you need to consider if on/off are represented by some particular numeric values.
When you link a numeric register to a switch channel, the binding assumes 0 is OFF and anything else is ON when read. I think it writes 1 for ON