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
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
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.
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.
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:
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.
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…
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
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.
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.
This works :). Not sure I fully understand the logic of the JS
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
