Update Values in App and BasicUI

Hi All,

I’m currently setting up openhab and connecting it to my Beckhoff. To test I have the following in items:

Switch SwitchKeukenSchuifraamLight "Switch Light KeukenSchuifraam" <light> {autoupdate="false",modbus="<[slave3:0],>[slave1:0]"}
Dimmer Dimmer1 "Dimmer [%d %%]" (ALL) {modbus="slave2:<2:>1"}
Number status0 "status0 is [%d]" {modbus="slave2:2"}

in sitemap:

Switch item=SwitchKeukenSchuifraamLight label="Switch Light KeukenSchuifraam" mappings=[ON="On!"]
Setpoint item=Dimmer1 minValue=0 maxValue=100 step=5
Text item=status0

For the lights, this is working perfect in BasicUI and I’m getting updates to the state when a physical button sets the light. In the Iphone App it is not working as expected. When I press the On button to activate the light, the button reamains active and I have to press it twice to deactivate the light (see pic 1)

The dimmer is working also as I can set my desired level easily. However, when I dim the lights with my physical buttons, the openhab dimmer is not reflecting the change:

In the second pic you can see that the dim value is 33% but in status0 you can see the real value 0. shouldn’t it read that value from the item definition: {modbus="slave2:<2:>1"}

any advice how to fix this or what I’m doing wrong?

Any advice?

I don’t know anything about Mobus so don’t really have anything to offer.

You can check events.log to see that status0 is updating but since the binding config is different between Dimmer1 and status0 there is no reason for me to think that they should have the same value.

I also don’t use the iOS app but if it is not behaving the same way as the web page sitemap then you should file an issue on github.

Thank you very much for the reply!

on the events.log I see the following when I’m changing the value in the app or WebUI:

2017-10-14 19:37:00.485 [ItemCommandEvent ] - Item ‘Dimmer1’ received command 9
2017-10-14 19:37:00.565 [ItemStateChangedEvent ] - Dimmer1 changed from 49 to 9
2017-10-14 19:37:00.695 [ItemStateChangedEvent ] - status0 changed from 49 to 9

if I do it with the physical switch:

2017-10-14 19:52:45.331 [ItemStateChangedEvent ] - status0 changed from 9 to 13

so indeed the dimmer1 is not getting the change… which is in my view strange as both status0 as Dimmer 1 get the same input Slave2:2 or do you see this differently?

The iOS app is indeed a different issue, could you help me where I need to exactly report this?

thanks again!

I don’t know this binding so can’t say anything for sure but the two others are configured differently so I would expect them to behave differently.

If they are to behave the same, why have two items to represent the same state?

Search Google for “iOS openhab GitHub” and you should find the repo to report the behavior.

1 Like

Even if I create an item like:

Dimmer Dimmer2 "Dimmer [%.1f]" (ALL) {modbus="<[slave4:1]"}

If I update the value of slave4:1 via the beckhoff console, the slider is not updating at all. Shouldn’t the item dimmer be acting on a change of Slave4:1 or how do I need to see this?

Like I’ve said, this is all specific to that binding.

Agree, but still strange that my switches are defined in the same way and are acting normally (except for the iOS issue)

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

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

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

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

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

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

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

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.

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?

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

	
}

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

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…