Update Values in App and BasicUI

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…

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

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

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

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

feature:install openhab-transformation-javascript

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

1 Like

@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.

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…