Update Values in App and BasicUI

Setup, Configuration and Use Beginners
#9

I don’t know this Beckhoff device or what you can get out of it.

Where you’ve got a read/write device, it’s usually worth thinkng about how Oopenhab+Modbus works. The device never sends data to Openhab, it has to be read. So the binding periodically reads (polls) the device(s).
When you send a command to an Item linked to a Modbus write, the binding sends the new value to the device, and I think also auto-updates the value of the Item.

So there are two potential pitfalls there -
A. The OH Item may get auto-updated to a value that is not (or not yet) existing in the real device.
B. Depending on exact timing of independant write and poll events, the OH Item may get updated to a value that does not (or not yet) reflect the real device.

In my own modbus config, I usually set read/write Items to have autoupdate=false property, which deals with issue A

Issue B isn’t usually a problem, as it invariably gets sorted out at the next read/poll, but is something you have to bear in mind sometimes if writing timing critical rules.

I don’t know if this has anything to do with your problems, but I would at least set autupdate=false if you are sure the Dimmer state can be read from the device.

Openhab Dimmer states are I think percentage i.e. 0-100. What does Beckhoff think? States 0-254 are common enough, and there you’d need a Transform to match/scale ranges.

P.S. I think you need a fairly up to date Modbus binding version for fully functional Dimmers. 1.10

1 Like
#10

thanks for the reply,

so to debug I did the following, I added in items:

Dimmer Dimmer1 "Dimmer [%.1f]" (ALL) {autoupdate="false",modbus=">[slave2:1],<[slave4:1]"}
Dimmer Dimmer2 "Dimmer [%.1f]" (ALL) {autoupdate="false",modbus="<[slave4:1]"}
Number status5 "status5 is [%d]" {modbus="slave4:1"}

in sitemap:

Slider item=Dimmer1
Slider item=Dimmer2
Text item=status5

If I use the UI and use the slider to a new value I get the following:

21:48:25.499 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'Dimmer1' received command 24
21:48:25.944 [INFO ] [marthome.event.ItemStateChangedEvent] - status5 changed from 0 to 24

If I use my physical button:
21:49:32.694 [INFO ] [marthome.event.ItemStateChangedEvent] - status5 changed from 24 to 20

so it seems there is no feedback to dimmer1 or dimmer2. Am I missing something because the variables in my beckhoff device are really changing as you can see above

#11

Please make sure you are using binding version 1.10 for Dimmer type support

#12

Forgot to mention, apologies. Had 1.10 before and tried 1.11 today

#13

I’m not convinced that the binding will “connect” a single Modbus register to multiple Items correctly. Sami @ssalonen may remember for v1?

If it were me I would reduce the bound Items to a single Dimmer and see what happens, now that you have shown the underlying mechanics work.

Beware of the hidden config caching effect when you make changes like that.

If you do want multiple Items involved, you could work around with a rule updating item X from a change in Y

Or it might be an interesting test case if you wanted to try alpha version 2

#14

As far as I know there are no known issues related to this.

Openhab Dimmer states are I think percentage i.e. 0-100. What does Beckhoff think? States 0-254 are common enough, and there you’d need a Transform to match/scale ranges.

This is something to check. With verbose logs the binding should also tell when transformation fails, e.g. Due to value outside the scale.

I advice you to configure (slave configuration parameter) updateunchangeditems to true as well. In cases where the item state is modified in openHAB, the state might go out-of-sync (binding skips the item state update if polled value is unchanged, but does not check the current state of the item). Autoupdate in away is one way to protect against this.

Could you also share the modbus configuration, I hope that value type is int16 or uint16?

So I would check first with updateunchangeditems=true (restart openHAB, remember to clear configuration caches as well). If that does not help, try again with verbose logs, and see if that explains what is happening. Advice above to simplify configuration is always good practice with troubleshooting.

Best,
Sami

#15

Thanks a lot for your feedback. This is my log:

https://pastebin.com/XCgi7DME

and this is the modbus config:

> # sets refresh interval to Modbus polling service.
> # Value in milliseconds (optional, defaults to 200)
> poll=1000
> 
> # tcp.slave1.connection=192.168.0.112:502:60:0:0:50:100
> # tcp.slave1.start=32768
> # tcp.slave1.length=35
> # tcp.slave1.type=coil
> 
> tcp.slave2.connection=192.168.0.112
> tcp.slave2.start=32768
> tcp.slave2.length=35
> tcp.slave2.type=holding
> tcp.slave2.valuetype=uint16
> 
> # tcp.slave3.connection=192.168.0.112
> # tcp.slave3.start=32768
> # tcp.slave3.length=35
> # tcp.slave3.type=discrete
> 
> tcp.slave4.connection=192.168.0.112
> tcp.slave4.start=32768
> tcp.slave4.length=35
> tcp.slave4.type=input
> tcp.slave4.valuetype=uint16
> tcp.slave4.updateunchangeditems=true
#16

Could you please re-format the config using code formatting:

Also, could you repeat the test with updateunchangeditems=true set for every slave, just to be sure. Perhaps you could copy the item configuration here as well. Please use the slider to trigger command to dimmer item.

#17

Thanks for formatting the code, now it’s easier to see that some lines are commented. Can you please still do the remaining steps I asked?

#18

So in this run I first set the slider from 0 to 57 using the slider, afterwards I used the physical swithc to put it to 99 which did not reflect in the state of the slider. You can find the new openhab log output here:

https://pastebin.com/KpYsSEyB

modbusconfig:

# sets refresh interval to Modbus polling service.
# Value in milliseconds (optional, defaults to 200)
poll=1000

# tcp.slave1.connection=192.168.0.112:502:60:0:0:50:100
# tcp.slave1.start=32768
# tcp.slave1.length=35
# tcp.slave1.type=coil

tcp.slave2.connection=192.168.0.112
tcp.slave2.start=32768
tcp.slave2.length=35
tcp.slave2.type=holding
tcp.slave2.valuetype=uint16
tcp.slave4.updateunchangeditems=true

# tcp.slave3.connection=192.168.0.112
# tcp.slave3.start=32768
# tcp.slave3.length=35
# tcp.slave3.type=discrete

tcp.slave4.connection=192.168.0.112
tcp.slave4.start=32768
tcp.slave4.length=35
tcp.slave4.type=input
tcp.slave4.valuetype=uint16
tcp.slave4.updateunchangeditems=true

items config:

Dimmer Dimmer1 "Dimmer [%.1f]" (ALL) {autoupdate="false",modbus=">[slave2:1],<[slave4:1]"}

sitemap config:

sitemap default label="My first sitemap"
{
	Slider item=Dimmer1

	
}
#19

Actually, I can clearly see in the logs that 99 seems to come out fine:

2017-10-18 08:17:46.349 [TRACE] [inding.modbus.internal.ModbusBinding] - internalUpdateItem(Register): Updating slave slave4 item Dimmer1, state 99 (changed=true) matched ItemIOConnection ItemIOConnection@7fb78f83[slaveName=slave4,index=1,type=STATE,trigger=default,transformation=Transformation@38792f55[tranformation=default,transformationServiceName=,transformationServiceParam=],valueType=default].

It seems the binding can at least read values as expected, and correlate it with the correct item (Dimmer1). Since there is no transformation configured, the values should go as-is for the item (!)

So not fully understanding why you are not seeing the change in the slider… This is somewhat dummy questions but still: Have you tried simply refreshing the UI manually?

Unfortunately I think the log does not include ItemStateChangedEvent log lines – perhaps they are included in some other log file? That would be the final confirmation of state changes as openHAB sees them.

Best,
Sami

#20

Thanks for looking into this. Yes I have tried manually refreshing but that doesn’t help. In one of the posts above I copied the itemstatechangedevent and there you can see that status5 is updating but the dimmer1 is not…

#21

Do you still happen to have event log or similar with item state changes from the time of the last test?

Would help us to analyze if the issue is in BasicUI (as unlikely it sounds) or in the binding…

#22

Fortunately I still have it :). here you can see clearly that the 57 that is submitted via the BasicUI is updated but the 99 that was processed via the physical switch is not showing

2017-10-16 21:56:04.834 [ItemCommandEvent          ] - Item 'Dimmer1' received command 100
2017-10-16 22:02:38.630 [ExtensionEvent            ] - Extension 'package-standard' has been installed.
2017-10-16 22:02:40.962 [ExtensionEvent            ] - Extension 'ui-basic' has been installed.
2017-10-16 22:02:41.021 [ExtensionEvent            ] - Extension 'binding-modbus1' has been installed.
2017-10-16 22:02:41.022 [ExtensionEvent            ] - Extension 'ui-habpanel' has been installed.
2017-10-16 22:02:41.022 [ExtensionEvent            ] - Extension 'ui-paper' has been installed.
2017-10-16 22:02:45.527 [ItemCommandEvent          ] - Item 'Dimmer1' received command 62
2017-10-18 08:08:00.514 [ItemCommandEvent          ] - Item 'Dimmer1' received command 52
2017-10-18 08:08:03.032 [ItemCommandEvent          ] - Item 'Dimmer1' received command 28
2017-10-18 08:17:34.407 [ItemCommandEvent          ] - Item 'Dimmer1' received command 0
2017-10-18 08:17:35.406 [ItemCommandEvent          ] - Item 'Dimmer1' received command 28
2017-10-18 08:17:36.551 [ItemCommandEvent          ] - Item 'Dimmer1' received command 57
1 Like
#23

Thanks!

I could reproduce the issue myself. It seem that verbose logging is not very verbose by default openhab2 and that’s why we were missing critical information.

When setting debug level logging in core openhab:

log:set TRACE org.eclipse.smarthome

You can see the core reason

18:37:54.168 [DEBUG] [home.core.internal.items.ItemUpdater] - Received update of a not accepted type (DecimalType) for item Dimmer1

The reason is that internally the default transformation is not converting between DecimalType (not accepted by Dimmer) and PercentType (accepted by Dimmer). This is actually logged by the binding as well (I know, hard to miss and certainly unclear from docs)

18:49:01.619 [DEBUG] [nternal.ModbusGenericBindingProvider] - Item 'itemName' is of type 'DimmerItem'. Please make sure that transformation is in place to convert the polled data to a format understood by the item. Furthermore, make sure that commands are converted to DecimalType or any command accepted by Switch, Contact or Number items.

You can have working configuration as follows:

Dimmer Dimmer1 "Dimmer [%.1f]" (ALL) {autoupdate="false",modbus=">[slave2:1],<[slave4:1:transformation=JS(identity.js)]"}

where

identity.js:

(function (inputData) {
    return inputData;
})(input)

Now the “dummy” identity transformation is used to convert numbers to percents. In case numbers would exceed 0…100, the data will be ignored by openHAB.

Best,
Sami

2 Likes
[SOLVED] Modbus Dimmer item dividing by 100
Modbus TCP Dimmer slider jumps up to 100% OH3
Use Dimmer-item with modbus binding OH2
#24

This works :). Not sure I fully understand the logic of the JS :slight_smile:

The only thing that I get now is warnings as follows:

19:13:17.476 [WARN ] [.core.transform.TransformationHelper] - Cannot get service reference for transformation service of type JS
19:13:17.477 [WARN ] [nding.modbus.internal.Transformation] - couldn't transform response because transformationService of type 'JS' is unavailable
#25

I think that mean that you do not have JS transformation installed. Please install it using:

feature:install openhab-transformation-javascript
#26

again thanks, everything is working now. Hopefully I will also get the same help on the iOS App

1 Like
#27

@ssalonen: Everyting is running smoothly but if I have a look in the log, I see the following quite often:

connect try 1/50 error: connect timed out. Connection TCPMasterConnection@151e7816[socket=Socket[unconnected]]. Endpoint ModbusTCPSlaveEndpoint@1d19d742[address=192.168.0.112,port=502]

Do you know what this is causing? The whole setup is cabled so no wifi components.

#28

Nothing but guesses really . I would not mind if it connects eventually.

Some slaves cannot accept connection at all times, I get connection refused with my PLC but the second or third attempt goes through.

Timeout is a bit more weird though. The connection timeout is configurable if you want to play with that…