[Modbus] Coil reset only after item update to ON (OFF excepted)

[primary1]

Hello.
In OpenHAB 2.0.0.4b there is something wrong with modbus binding 1.9.0.b4.
Problem occurs when using separate coils for reading and writing:
When updating item to ON, coil is setting, but after item update to OFF, nothing is happen.
If coil is set, updating item to ON one more time results in coil reset...
In OH 1.8.3 everything works good.

Expected Behavior

item update results in corresponding coil status.
Item update to ON is setting coil,
Item update to OFF is resetting coil.

Current Behavior

##Item state = OFF, coil = FALSE 2016-11-05 18:00:30.496 [ItemCommandEvent ] - Item 'Swiatlo_Parter_Salon_Sufit' received command ON 2016-11-05 18:00:30.504 [ItemStateChangedEvent ] - Swiatlo_Parter_Salon_Sufit changed from OFF to ON ##item state updated to ON, coil = TRUE 2016-11-05 18:00:35.598 [ItemCommandEvent ] - Item 'Swiatlo_Parter_Salon_Sufit' received command OFF 2016-11-05 18:00:35.611 [ItemStateChangedEvent ] - Swiatlo_Parter_Salon_Sufit changed from ON to OFF ##item state updated to OFF, coil = TRUE 2016-11-05 18:00:41.958 [ItemCommandEvent ] - Item 'Swiatlo_Parter_Salon_Sufit' received command ON 2016-11-05 18:00:41.985 [ItemStateChangedEvent ] - Swiatlo_Parter_Salon_Sufit changed from OFF to ON 2016-11-05 18:00:42.189 [ItemStateChangedEvent ] - Swiatlo_Parter_Salon_Sufit changed from ON to OFF ##item state updated to ON and OFF immediately, coil = FALSE

I also niticed, updating item to ON is toggling coil status:

smarthome:status Swiatlo_Parter_Salon_Sufit ON ##item status = ON, coil = TRUE smarthome:send Swiatlo_Parter_Salon_Sufit ON smarthome:status Swiatlo_Parter_Salon_Sufit OFF ##item status = OFF, coil = FALSE smarthome:send Swiatlo_Parter_Salon_Sufit ON smarthome:status Swiatlo_Parter_Salon_Sufit ON ##item status = ON, coil = TRUE smarthome:send Swiatlo_Parter_Salon_Sufit ON smarthome:status Swiatlo_Parter_Salon_Sufit OFF ##item status = OFF, coil = FALSE

Steps to Reproduce (for bugs)

1. Create item with separate coils for reading and writing
2. Click several times in HABDroid or Classic UI / Bassic UI.
   Coil is toggled only whe updating item to ON.

OH logs.zip

Your Environment

Debian Jessie, Java 8 (openJDK)

[ssalonen]

Formatted the Current behaviour for better readability

##Item state = OFF, coil = FALSE 
2016-11-05 18:00:30.496 [ItemCommandEvent ] - Item 'Swiatlo_Parter_Salon_Sufit' received command ON 
2016-11-05 18:00:30.504 [ItemStateChangedEvent ] - Swiatlo_Parter_Salon_Sufit changed from OFF to ON 
##item state updated to ON, coil = TRUE 
2016-11-05 18:00:35.598 [ItemCommandEvent ] - Item 'Swiatlo_Parter_Salon_Sufit' received command OFF
2016-11-05 18:00:35.611 [ItemStateChangedEvent ] - Swiatlo_Parter_Salon_Sufit changed from ON to OFF 
##item state updated to OFF, coil = TRUE 
2016-11-05 18:00:41.958 [ItemCommandEvent ] - Item 'Swiatlo_Parter_Salon_Sufit' received command ON 
2016-11-05 18:00:41.985 [ItemStateChangedEvent ] - Swiatlo_Parter_Salon_Sufit changed from OFF to ON 
2016-11-05 18:00:42.189 [ItemStateChangedEvent ] - Swiatlo_Parter_Salon_Sufit changed from ON to OFF 
##item state updated to ON and OFF immediately, coil = FALSE

I also niticed, updating item to ON is toggling coil status:

smarthome:status Swiatlo_Parter_Salon_Sufit ON 
##item status = ON, coil = TRUE smarthome:send Swiatlo_Parter_Salon_Sufit ON smarthome:status Swiatlo_Parter_Salon_Sufit OFF 
##item status = OFF, coil = FALSE smarthome:send Swiatlo_Parter_Salon_Sufit ON smarthome:status Swiatlo_Parter_Salon_Sufit ON 
##item status = ON, coil = TRUE smarthome:send Swiatlo_Parter_Salon_Sufit ON smarthome:status Swiatlo_Parter_Salon_Sufit OFF 
##item status = OFF, coil = FALSE

[ssalonen]

So if understood correctly, everything goes well except the last piece:

##item state updated to OFF, coil = TRUE 
2016-11-05 18:00:41.958 [ItemCommandEvent ] - Item 'Swiatlo_Parter_Salon_Sufit' received command ON 
2016-11-05 18:00:41.985 [ItemStateChangedEvent ] - Swiatlo_Parter_Salon_Sufit changed from OFF to ON 
2016-11-05 18:00:42.189 [ItemStateChangedEvent ] - Swiatlo_Parter_Salon_Sufit changed from ON to OFF 

I believe you are expecting not to have the last log line at 2016-11-05 18:00:42.189?

To further diagnosse what is happening, could you please provide verbose logs? There is guide for openhab1, but not sure how logging is configured in openhab2. Note the net.wimpi.modbus logger configuration.

Please note that the binding reads from the configured coil number the current status. By default this happens every 200ms. I think this might be "reseting" the state for you, depending how your modbus slave works.

[primary1]

Well,
problem occurs at this point:
##item state updated to ON, coil = TRUE 2016-11-05 18:00:35.598 [ItemCommandEvent ] - Item 'Swiatlo_Parter_Salon_Sufit' received command OFF 2016-11-05 18:00:35.611 [ItemStateChangedEvent ] - Swiatlo_Parter_Salon_Sufit changed from ON to OFF ##item state updated to OFF, coil = TRUE

item status is ON and coil = TRUE, what is correct.
When I click in UI to disable coil, item is receiving command to OFF, then item change from ON to OFF (what is correc), but coil state doesn't change.

I'm not sure how to set DEBUG logging.
In karaf:

`openhab> log:list

Logger | Level

ROOT | DEBUG
javax.jmdns | ERROR
org.eclipse.smarthome | INFO
org.jupnp | ERROR
org.openhab | INFO
org.openhab.binding.modbus | DEBUG
org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper | ERROR
smarthome.event | DEBUG
smarthome.event.InboxUpdatedEvent | DEBUG
smarthome.event.ItemStateEvent | DEBUG
smarthome.event.ThingStatusInfoEvent | ERROR`

but still not getting debug log output.

I also get in karaf:
openhab> log:display org.openhab.binding.modbus 13:25:32.583 [DEBUG] [.binding.modbus.internal.ModbusSlave] - ModbusSlave (wyjscia): FC05 ref=12288 value=true 13:25:35.464 [DEBUG] [.binding.modbus.internal.ModbusSlave] - ModbusSlave (wyjscia): FC05 ref=12288 value=false 13:25:38.451 [DEBUG] [.binding.modbus.internal.ModbusSlave] - ModbusSlave (wyjscia): FC05 ref=12288 value=true 13:25:58.007 [DEBUG] [.binding.modbus.internal.ModbusSlave] - ModbusSlave (wyjscia): FC05 ref=12288 value=true

start: coil = FALSE
After 1st command: coil = TRUE - OK
After 2nd command: coil = TRUE - not OK
After 3rd command: coil = FALSE - not OK
After 4th command: coil = TRUE - OK

Keep in mind, when using single coil for reading and writing everything works good.

[ssalonen]

@primary1 regarding log configuration in openhab2, I found this community thread. Perhaps this works for you:

log:set TRACE net.wimpi.modbus
log:set TRACE org.openhab.binding.modbus

Verify using log:list. Hope this works for you.

Could you please clarify what do you mean by "coil = TRUE"? Do you mean the actual/true coil value in the modbus slave? What modbus coil you are referring with "coil"? coil number 0 or coil number 11776? I'm sorry I'm still at lost what do you expect to happen and what happens now.

[primary1]

Yes, "coil = TRUE" is actual coil value in modbus slave device.
Coil number "0" is physical output of my PLC.
Coil number 11776 is a "flag". OpenHAB should set this coil to TRUE. Then PLC toggle coil number 0 value, and reset coil number 11776.
OpenHAB should read coil number 0 value, and write "1" to coil number 11776 to toggle coil number 0.
That works in OpenHAB 1.8.3 and earlier like a charm.
I'll try to get some logs.

[ssalonen]

OK, now it starts to make sense. I think the change from 1.8.3 might be #3864? The change was that binding processes openhab commands as-is with no changes.

So, when you ask the modbus binding to command coil ON, openHAB modbus binding writes 1. But note that when you ask OFF, the binding writes 0. This is not what you want?

[primary1]

OK, so everything is clear now.
When coil number 0 is ON, openHAB send OFF command to coil 11776.
That behaviour is pointless, because slave device must keep booth coils (0 and 11776 is my case) with the same state all the time.
In this case it's better to use single coil for reading and writing.
When openHAB write TRUE to 11776, slave will change 0 to TRUE.
Whe openHAB write FALSE to 11776, slave will change 0 to FALSE.
When slave device set 0 to TRUE or FALSE, openHAB will read it via 11776.

In 1.8.3 to change coil number 0 value, openHAB just set 11776 to TRUE.
Then slave just resets 11776 and change coil 0 value.
That behaviour corresponds to:
http://github.com/openhab/openhab/wiki/Modbus-Binding#separate-coils-for-reading-and-writing
This was much simpler to implement in slave device.

Am I right?

[ssalonen]

When coil number 0 is ON, openHAB send OFF command to coil 11776.

No, it should not do that. openHAB modbus binding does not send commands, it only posts state updates. Commands are sent when e.g. clicking in sitemap, or custom rules call sendCommand. Note that there is difference between state updates and commands. For more information, see this wiki article.

In this case, the binding reads the coil 0 status, and sends item status update (in openhab event bus). No coil value is written over modbus. With 1.9.0, no matter what is status of the coil, the behaviour is the same.

The binding does receive commands. Those are always processed the same way, the bit (ON/OFF) is written to (write) coil 11776.

In this case it's better to use single coil for reading and writing.

I agree, single coil is always simpler to understand. What prevents you from doing this? I'm afraid I still have hard time understanding what you are trying to achieve. What kind of slave device we are talking about? Does that slave force you to have two coils?

When openHAB write TRUE to 11776, slave will change 0 to TRUE.
When openHAB write FALSE to 11776, slave will change 0 to FALSE.

OK. I believe this logic is something you have had to implement to the slave?

When slave device set 0 to TRUE or FALSE, openHAB will read it via 11776.

Actually openHAB 1.9.0 should not read from 11776 since the read coil is 0., not 11776.

http://github.com/openhab/openhab/wiki/Modbus-Binding#separate-coils-for-reading-and-writing

Note the link to the github issue though, it relates to the pull request I also referenced above. I believe that piece of text needs updating for the 1.9.0.

I hope this clarified something.

Best,
Sami

[primary1]

When coil number 0 is ON, openHAB send OFF command to coil 11776.

I meant something different: when item state is currrently ON, and I click in sitemap to OFF,
openHAB sends command OFF. Next modbus binding write FALSE to 11776 coil.

I agree, single coil is always simpler to understand. What prevents you from doing this? I'm afraid I still have hard time understanding what you are trying to achieve. What kind of slave device we are talking about? Does that slave force you to have two coils?

I use Fatek PLC as slave device. Currently I'm using openHAB 1.8.3 with separate coils for reading and writing. I do that, because it's simpler to control PLC outputs via openHAB and PLC itself. To migrate to openHAB 2 I have to change write coils behavior - large piece of ladder program.

Actually openHAB 1.9.0 should not read from 11776 since the read coil is 0., not 11776.

I wrote this referring to single coil to read and write. Nevermind.

To summarize: modbus binding in openHAB 2 writes "0" or "1" value depending on what commands received. This happend also in single coil and two coils case .
In two coils case modbus binding should writes only "1", no difference what command received.
This is how it works in openHAB 1.8.3 and earlier.

You wrote obout it in issue #3684 .

• If command does not match polled value (i.e. user really tries to change to value of the coil), we write boolean x to the modbus slave.
  • For some reason I can't understand, the value x depends on the command's status (see this and this).
    • if command corresponds to boolean true, coil is set with value x=true
    • if command corresponds to boolean false
      • coil is set with value x=false only if read location is same write location.
      • Otherwise, coil gets value of x=true (note! even though command was false, value of true is written).

I don't know now if this is bug or proper behavior?

[ssalonen]

Ok good I think I understand now. Obviously this is a regression in 1.9.0. I think you have showed that there is a valid use case for the code.

I will think about this and reply here.

I'm currently thinking if we could implement the transformation support (#4204). I think it would serve your use case as well, you would just map both ON and OFF commands as value 1 on write, right?

[primary1]

OK, thank you.

Well, transformation support could be very useful -it can simplify the configuration.
I have some rules to do math operations on received and sent values via modbus binding.

[ssalonen]

Great to hear, I try to find time for this in the coming weeks

[ssalonen]

I now published experimental version implementing transformation support in the community forums

I appreciate all the feedback!

[primary1]

It seems that it works correctly.
I'll migrate to openHAB2 and let you know if everything is OK.

[9037568]

Closed via merged PR.