Item:Number change is not updated in binding

Setup, Configuration and Use Items & Sitemaps
1

Hello,

I have a simple item (type: Number) which is linked to Simatic thing channel. Channel type is chNumber (uint32). Link profile is default. No unit.

When I change value in PLC => item is updated in OpenHab.
When I change value on item (directly in semantic model UI) or in Widget (oh-button Action:command) => value in PLC is not updated. Only value in item itself is changed. What am I missing?

I have also another item with linked channel, but the type is Rollershutter. This works.

I checked source code for the binding and ThingHandler has a override for method handleCommand. First line is a debug message:

public void handleCommand(ChannelUID channelUID, Command command) {
        logger.debug("{} - Command {}({}) for channel {}", thing.getLabel(), command, command.getClass(), channelUID);

If this method is not called from OpenHab, no data will be written to PLC.

When I control Rollershutter in OpenHab, I can see this debug message in the OpenHab Log.
But when I try to change my item of type Number. The message is not there.

Why Number item does not send update to Binding?

I already tried to change item dimensions or add “Setpoint” tag or set Auto-Update to true/false but with no success.

Thanks for help.

2

I understand something about OpenHab wrong.

How is it possible, when I send REFRESH command to the Number item, I can see that Binding handling method is called:

RefreshCommand
RefreshCommand1663Ă—247 27.6 KB

But if I send DECIMAL command, then Openhab does not even bother to call binding with the new value:

ValueCommand
ValueCommand1642Ă—253 23.6 KB

(No DEBUG message from the binding is in the log)

3

Since this is not an official binding you might also post an issue of the binding developer’s repo.

Any command sent to an Item linked to a Channel should be picked up by the binding. Do you see the command event in events.log? If not the issue is the command is not being sent properly for some reason. If you do see it there than the binding is not picking up the command for some reason.

4

I think the same. If you look at the logs, I can see there CommandEvent when I send REFRESH command and also CommandEvent when I send value (in this case 655).

But since there is only one method that handles all the events coming from OpenHab to the binding, called handleCommand() and the first line is the logger.debug(), it must be in the log in both cases (now it is only for REFRESH).

I will try to raise the issue on GitHub as well.
I am not 100% sure that the source code that is on GitHub is also running in the OpenHab. Is there any way to compare them?

The last option is to try to build the OpenHab and debug it.

Thanks.

5

Screen shots are basically worthless. It’s always better to post the text using code fences.

```
code or logs go here
```

Unless I’m on a desktop/laptop I can’t read them.

The event bus doesn’t distinguish between command events. There has to be something in the binding that is missing that event.

Only if the binding is in debug level logging. By default all binding only log at the info level.

I don’t know. Usually an add-on author will document which version the add-on was compiled for. As a general rule a binding for a different version of OH will not work. There are of course exceptions to that but most of the time the add-on must be built for the version of OH you are running.

6

Hi.
Thanks for your time.

I am in contact with the author of the binding. But we have not found any problem yet.

Item has type “Number” with no additional tags or class to test with. I am using the Slider to change the value of the item.
There is a new message: “Not delegating command '31”…:

17:10:05.795,"DEBUG","org.openhab.core.thing.internal.profiles.ProfileCallbackImpl","Not delegating command '31' for item 'OfficeBlind_angle' to handler for channel 'simatic:generic_device:HomePlcBridge:OfficePlcThing:BlindAngle', because it was not possible to convcert it to an accepted type)."

Item Link/Channel profile is set to “Default”.
The message type is “DEBUG”, so maybe it is not important?

17:10:05.792,"INFO","openhab.event.ItemCommandEvent","Item 'OfficeBlind_angle' received command 31"
17:10:05.793,"DEBUG","org.openhab.core.thing.internal.profiles.ProfileCallbackImpl","Delegating command '31' for item 'OfficeBlind_angle' to handler for channel 'simatic:generic_device:HomePlcBridge:OfficePlcThing:BlindAngle'"
17:10:05.795,"INFO","openhab.event.ItemStatePredictedEvent","Item 'OfficeBlind_angle' predicted to become 31"
17:10:05.795,"DEBUG","org.openhab.core.thing.internal.profiles.ProfileCallbackImpl","Not delegating command '31' for item 'OfficeBlind_angle' to handler for channel 'simatic:generic_device:HomePlcBridge:OfficePlcThing:BlindAngle', because it was not possible to convcert it to an accepted type)."
17:10:05.797,"TRACE","openhab.event.ItemStateEvent","Received event of type 'ItemStateEvent' under the topic 'openhab/items/OfficeBlind_angle/state' with payload: '{""type"":""Decimal"",""value"":""31""}'"
17:10:05.798,"INFO","openhab.event.ItemStateEvent","Item 'OfficeBlind_angle' shall update to 31"
17:10:05.799,"TRACE","openhab.event.ItemStateUpdatedEvent","Received event of type 'ItemStateUpdatedEvent' under the topic 'openhab/items/OfficeBlind_angle/stateupdated' with payload: '{""type"":""Decimal"",""value"":""31""}'"
17:10:05.800,"INFO","openhab.event.ItemStateUpdatedEvent","Item 'OfficeBlind_angle' updated to 31"
17:10:05.800,"INFO","openhab.event.ItemStateChangedEvent","Item 'OfficeBlind_angle' changed from 35 to 31"

I have binding log set to DEBUG. I see the binding “DEBUG message” (command received) in the log for other channel types.

7

What is the type of the Channel? That debug warning is saying that the command is being supporessed because the Channel doesn’t support that type. For example, sending 31 to a Switch Channel will produce a similar error.

Right and it’s the default profile that’s generating the log.

This is the root cause. For some reason OH thinks the Channel doesn’t accept Number as a command. That’s problably based on what the binding is telling OH what type of Channel it is.

Note, the issue isn’t that the value is out of range. It’s that it thinks the Channel won’t accept DecimalType as a command.

8

I dont think there is any way that the binding tells which command will accept which channel. At least I didnt find it in the source code of the binding.

There is property acceptedItemType in Channel class (this is then used in converter) in OpenHab source code. But I didnt find from where it is set yet.

Out of curiosity I tried to add JS transformation to the profile (item to thing direction), and it started to work. Funny thing is that this transformation does nothing with the data:

(function(data) {
  var log = Java.type("org.slf4j.LoggerFactory").getLogger("org.openhab.model.script.SimaticIssue");
  log.info("Data is " + data)
  return data
})(input)

After that, the opposite direction stopped working, so I need to add another “empty” transformation in the opposite direction as well.

9

It would be in the XML file. I think that’s where the Channels for each Thing are defined.

Actually it does. It converts the data from a Number to a String. The output of all transformations are Strings. For a Script transformation, even if you return a number it gets converted to a String for you. Then the Channel pickes it up and parses it abck into a number.

Because you are using a transformation profile you are skipping that check in the default profile since you are not using the default profile any more.

That is kind of weird. I wouldn’t think that it would impact both directions that way.

This can certainly be a temporary work around but there is still something wrong going on.

If you didn’t want to create a separate noop transformation, you could use an inline transformation:

js: | return input
10

You are right. I found it as it is described in the documentation:

It is an XML file, and channel type I use is described this way:

<!-- Thing Channels -->
	<channel-type id="chNumber">
		<item-type>Number</item-type>
		<label>Number Value</label>
		<description>Supported Simatic data types are Bit, Byte, Word, Dword, Float</description>
		<config-description>
			<parameter name="stateAddress" type="text">
				<label>State address</label>
				<description>Simatic address to get item state. If empty, no data will be received.</description>
			</parameter>
			<parameter name="commandAddress" type="text">
				<label>Command address</label>
				<description>Simatic address to command item. If empty, no data will be sent.</description>
			</parameter>
            <parameter name="unit" type="text">
                <label>Unit</label>
                <description>Received number unit. If specified, unit is send into openHAB together with new value. No validation against data type is provided.</description>
            </parameter>			
		</config-description>
	</channel-type>

Which seems to be fine.

I enabled logging for CommunicationManger, and get this message:

22:12:04.253	DEBUG	org.openhab.core.thing.internal.CommunicationManager	Received not accepted type 'DecimalType' for channel 'simatic:generic_device:HomePlcBridge:OfficePlcThing:BlindAngle'

From the code I can see that command type “DecimalType” is not in the HashMap/List acceptedCommandTypeMap. Because acceptedCommandTypeMap.get(channel.getAcceptedItemType()) method return null.

1 Like
11

Update:

  1. I tried to uninstall/install the binding again → no change
  2. I created a new installation of OpenHab + installed binding → works as it should.

So sadly I will have to rebuild my 300+ item / 30+ thing Openhab by hand again.

12

Why? Uninstalling and reinstalling the binding should not break the Things. Once the binding is reinstalled it should recognize the Things that exist that are related to it and handle them again. When the binding is uninstalled or disabled the Things remain but in a “no handler” state.

When/if you recreate the Thing, if the Thing ID is set to be the same as the old one the Links to the Items will still work. That’s why there’s the “add-thing with custom id” option when accepting Things from the inbox.

And even if the Thing IDs did change therefor breaking the Links to the Items, you just need to fix the Links. You do not need to recreate the Items.

13

Correct. Reinstalling the binding did not break the thing. But it still cannot write the number to the PLC. I also find that I cannot create a new Thing for this binding. It just says “No Thing types can be added with this binding”.
image

Everything works fine in a fresh OpenHab installation (with just a few items).

So I think the problem is somewhere in my current configuration (json DB). Because the only thing that is different between the working and non-working version is my configuration.

Another symptom that I’ve been noticing for a while now is that after every OpnHab update, I have to manually reinstall the Binding to get it to work.

14

Update. It happened to me again.
Everything was working, but when I changed the type of item and the type of channel from rollershutter to number, it failed again.

The only way to fix it is to delete all items and all things of the binding + reinstall the binding.

Should I try raising the issue on GitHub openhab-distro?

15

If it’s just this binding that behaves this way it points to the binding as the source of the problem. So the issue should probably go there first. If the developer there can point to an issue with core the issue will need to be filed in openhab-core. But I suspect enough info will need to be presented there so the maintainers can reproduce it.