TCP&UDP binding in a loop with MAP transformation

Add-ons Bindings
, ,
1

Hi,

I’m having a little nuisance with the TCP & UDP binding when using a map. ( https://www.openhab.org/addons/bindings/tcp1/ )

My item is configured as follows:

String Clipsal_command "Command" { tcp=">[*:192.168.0.2:23:MAP(clipsal.map)]" }

This is a generic channel to send commands to Clipsal through an AMX controller over Telnet

The map is configured as follow (I even tried to add a default empty value):

KIISU_LAGI_ON=send_command 33001:1:0, 'K:L:[00:01:02]:ON'
KIISU_LAGI_OFF=send_command 33001:1:0, 'K:L:[00:01:02]:OFF'
=

It does switch the lights, when I send it a command KIISU_LAGI_ON for instance, and I’m happy with this, but in the log I see it’s looping by first receiving the send command by me KIISU_LAGI_ON, then it transforms this to the send_command blabla… And after this it also tries to transform this value with the map, and if it did,it probably would start tranforming that as well, so I’d like to be able to just have 1 intended transformation attempt and that’s it.

The log:

2019-03-30 08:54:32.330 [ome.event.ItemCommandEvent] - Item 'Clipsal_command' received command KIISU_LAGI_ON

2019-03-30 08:54:32.354 [vent.ItemStateChangedEvent] - Clipsal_command changed from send_command 33001:1:0, 'K:L:[00:01:02]:OFF'

> to KIISU_LAGI_ON

2019-03-30 08:54:32.724 [WARN ] [rm.AbstractFileTransformationService] - Could not transform 'send_command 33001:1:0, 'K:L:[00:01:02]:ON'

>' with the file 'clipsal.map' : Target value not found in map for 'send_command 33001:1:0, 'K:L:[00:01:02]:ON'

>'

2019-03-30 08:54:32.743 [vent.ItemStateChangedEvent] - Clipsal_command changed from KIISU_LAGI_ON to

2019-03-30 08:54:32.747 [vent.ItemStateChangedEvent] - Clipsal_command changed from to send_command 33001:1:0, 'K:L:[00:01:02]:ON'

>

2019-03-30 08:54:33.873 [ome.event.ItemCommandEvent] - Item 'Clipsal_command' received command KIISU_LAGI_OFF

2019-03-30 08:54:33.885 [vent.ItemStateChangedEvent] - Clipsal_command changed from send_command 33001:1:0, 'K:L:[00:01:02]:ON'

> to KIISU_LAGI_OFF

2019-03-30 08:54:34.236 [WARN ] [rm.AbstractFileTransformationService] - Could not transform 'send_command 33001:1:0, 'K:L:[00:01:02]:OFF'

>' with the file 'clipsal.map' : Target value not found in map for 'send_command 33001:1:0, 'K:L:[00:01:02]:OFF'

>'

2019-03-30 08:54:34.249 [vent.ItemStateChangedEvent] - Clipsal_command changed from KIISU_LAGI_OFF to

2019-03-30 08:54:34.271 [vent.ItemStateChangedEvent] - Clipsal_command changed from to send_command 33001:1:0, 'K:L:[00:01:02]:OFF'

>

Hope someone has good insights or ideas for me, as I’m out of any… Been messing with this for a day now.

Cheers,

Alari

2

Bindings docs say

<command>: can be omitted or have the value ‘*’. Omit the command if using generic mapping via transformations, or if no mapping is needed.

Sounds like you may accidentally configured for both raw command and transform?

Try

String Clipsal_command "Command" { tcp=">[192.168.0.2:23:MAP(clipsal.map)]" }
3

Hi,

Thanks for your reply. As I understood the doc, having ‘*:’ in front can be omitted because if it’s not there it makes the same result.

Regardless, I’ve tried it with and without and tried once more just in case, but still get the same warnings and the same loop.

Best,

Alari

4

Did you experiment with a rule before this? Something changes the Items state, and the binding should not be doing that at all with use of >.
Autoupdate can do that of course, but only in response to commands.

Suspecting a ghost rule, deleted but lingering. Subtle changes in Item configs seem to be missed in caching sometimes.
I would recommend an OH reboot before digging further.

5

Nope, no rules have ever touched this item or binding in general.
I got this as soon as I got it working properly with mapping.

What seems to happen to me is:

  • from HABPanel I send command like KIISU_LAGI_ON to the item
  • the item state therefore get’s changed to KIISU_LAGI_ON, from getting the command
  • this due to the transformator’s presence, this value is sent to the MAP
    • which in turn set’s the item’s value to the mapped equivalent command of “send_command blabla…”
  • since the item state is changed by the map, this value get’s sent to the map again, which in this case doesn’t have a valid mapping, but in other would again set the state
6

That is accomplished by an openHAB feature called autoupdate.
Commands and states are two completely different things.
In an idealized openHAB, commands to Items get passed out to a real device - the state is not updated by that.
The device eventually responds with a status change, the binding puts into Item state.

In real life, many Items have no binding, many devices respond tardily or not at all, so autoupdate intercepts commands and performs an in-house update to emulate a real device quickly.

I mention that, because you can disable the feature.

String Clipsal_command "Command" { tcp="&gt;[192.168.0.2:23:MAP(clipsal.map)]" , autoupdate="false" }

Send as many commands as you like, the state will not update as a direct result. The commands still arrive at the binding - in your case for passing onward via TCP

I think that would be a useful exercise here. It will at least remove one source of unexpected updates.

See, this is a bit that should not happen. MAP should not set it’s result back into Item state, any more than say using a MAP in a label to translate language for display would.

I’m really curious about where the “send_command” part of that text comes from.

Then after that, this new state should not get sent for mapping again - the binding is listening for commands, not states. That’s two separate things that shouldn’t happen.

It might be a binding bug in transform support. I think I read you as saying everything works, you just get annoying logs and a nonsense state that you don’t use anyway?
MAP works for other TCP users - but maybe they don’t notice the logs.