Modbus openHAB2 binding available for alpha testing

openhab2-addons
modbus
binding
Tags: #<Tag:0x00007f6cf430c880> #<Tag:0x00007f6cf430c718> #<Tag:0x00007f6cf430c3f8>

(Rossko57) #344

Ah. Behaviour with expire binding is of future interest to me. This one would have caught me out.

Currently in OH1 I have many coil outputs working like pushbuttons; rule commands ON and after a while expire sets back OFF again. Saves a whole lot of rules and timers.
Some at least I could set up as modbus write-only, that should allow same behaviour using expire.

I guess philosophically I’m subverting the original purpose of the expire binding as a dead man’s switch. It’s convenient in this (ab)use, but not essential as other means are available.
It does not feel like an issue that needs to be addressed by breaking OH guidelines (barring performance effects !!).

I assume a failed write-only slave would be detectable via “last error” channel? Which represents an improvement over using expire for fault detecting purpose.


(Nathan Stratton) #345

Thanks for the detailed explanation! I just moved from expire to a rule that turns them off for now.


(Mbs38) #346

I’ll take a look.
Max


(Jan Nelissen) #347

Current situation:

The Schneider M221 PLC (see config attached) controls my lights. I’ve switches on the inputs of the PLC. Some of the outputs direct activates my lights and some outputs control some 5V relays.
I’ve had help programming the PLC, so my knowledge about PLC and Modbus is very poor.

OH 2.2 is running on an micro PC with Win10.

Also i’ve some z-wave devices up and running (dimmers and multi-sensor)

Problem:

I want to keep using my plc to control the lighting in case OH stops running.
OH has to control the outputs of the PLC and also use the inputs.
The ouput of the plc can be triggered by a switch or an sensor (Rules)
Actions on OH can be triggered by input of the PLC (switch) (all active lights off)
I like to combine the functionality of both OH and PLC

I’ve tried an setup with modbus tools slave simulator on other laptop and succeeded in read/write coils and read digital inputs.

Only if I change to the M221 plc nothing happens (with correct settings). Does anyone has some experience with Schneider PLC and modbus?

I’m using the binding of Sami Salonen and tried to program via PaperUI.


(Ssalonen) #348

@Jakke17, I think you are more likely to find help by opening a new thread regarding this topic. Sounds like you have sorted out the binding but having trouble with the plc.

What do you think?

Best
Sami


(Jan Nelissen) #349

@ssalonen, I’ve already tried twice but no reaction. The binding works fine but indeed the M221 plc doesn’t react to the binding. I will try again

Best Jan


(Andreas Viborg) #350

[SOLVED] I’m trying to do write to FC16 using the binding but can’t make it work.
I’ve tried sending this raw string from a console program: hex:1E1003EA0001020002+CRC which sets the control parameter to the requested value.

Then I setup my modbus.things file, I made a unique write data thing:

Bridge modbus:serial:nilanCombiPolar [ port="/dev/ttyUSB-48503", baud=19200, id=30, stopBits="1", parity="even",dataBits=8, echo=false, encoding="rtu", flowControlIn="none", flowControlOut="none", receiveTimeoutMillis=1500 ] {
	Bridge poller controlOutput[ start=1000, length=8, refresh=60000, type="holding" ] {
		Thing data outputType   [ readStart="1000", readValueType="int16" ]
		Thing data outputRunSet [ readStart="1001", readValueType="int16" ]
		Thing data outputModeSet  [ readStart="1002", readValueType="int16"]
		Thing data outputVentSet   [ readStart="1003", readValueType="int16" ]
		Thing data outputTempSet  [ readStart="1004", readValueType="int16" ]
		Thing data outputServiceMode  [ readStart="1005", readValueType="int16" ]
		Thing data outputServicePct   [ readStart="1006", readValueType="int16" ]
		Thing data outputPreset  [ readStart="1007", readValueType="int16" ]
	}
	Thing data writeOutputModeSet [ writeStart="1002", writeValueType="int16", writeType="holding", writeMultipleEvenWithSingleRegisterOrCoil=true ]
}
Number ventilationModeSet "Mode set [%d]" { channel="modbus:data:nilanCombiPolar:controlOutput:outputModeSet:number" }
Number ventilationWriteModeSet "Mode write set [%d]" { channel="modbus:data:nilanCombiPolar:writeOutputModeSet:number" }

I then set the ventilationWriteModeSet to 2 using the REST API and the log says that value has changed but nothing happens to the modbus slave when I check its control panel. No errors in the openhab log either. I have no problem reading data.
What is wrong?


(Andreas Viborg) #351

Seems the modbus binding doesn’t react to changes in the REST API, when I use the Paper UI it changes.


(Ssalonen) #352

Regarding REST not having an impact: I recommend posting a new general thread about this. It sounds like it might be a general issue (or even intended feature) with things configured via file.

Would you like to post the solution for your previous issue with writing? Perhaps it helps others

Best
Sami


(Sir Leone) #353

Trying new binding (2.3) yesterday and i have observed problem with things in paper ui - they didnt appear after put them in modbus.things file.


(Ssalonen) #354

Do you have all the required addons installed? Serial feature, modbus transport and modbus binding.

You can verify bundles from openhab console and using bundle:list command.

Please post logs for further diagnostics.


(Andreas Viborg) #355

When testing my rule to set ventilationWriteModeSet I used the REST API as I thougth it was the easiest ui. I assume the result I got was expected.

I did learn than I need to use ventilationWriteModeSet.sendCommand(2) instead of ventilationWriteModeSet.postUpdate(2) in the rule to make it send a Modbus command value of 2.

Still learning openhab…


(Ssalonen) #356

Thanks for the clarifiication. That is how it should work indeed (regarding your rule example).

There is a whole section regarding state vs commands in openHAB docs if I remember correctly.

Perhaps you have wrong REST call?