Re-transmit binding?

Add-ons Bindings
1

Is there such a thing like a re-transmit binding for wireless communication ?
When I send a command, it keeps sending it every x seconds until the state changes accordingly. (no autoupdate)

Example: I set the rollershutter level to 50 with a command. The state remains until the shutter reports back the new state. Thats how it is already. What I miss is an automatic re-transmit of that command if the state does not change within x seconds.

I would love this to be similar to the expire binding. When it still was a binding that is.
Rollershutter “Bathroom” … {channel=" …", retransmitt =“10s,3,updatedItem”}

Yes, I know how to do this in python or with Timers. I just thought this may be a nice thing to support out of the box since wireless or other lossy forms of communications do happen :wink:

2

Something like this would have to be implemented in core I think because the bindings do not really have access to Items in OH 2.x+ architecture. That’s why Expire was moved into core.

Ideally, this should be built into the add-on because retrying isn’t really applicable to all technologies.

It also gets complicated when an Item is linked to multiple channels and if profiles get involved.

This would be a great candidate for a rule template though. Put all the Items into a group, add the “retransmit” metadata to those Items and one rule can do this. Published to the marketplace, and it becomes installable like an add-on.

My Debounce [4.0.0.0;5.9.9.9] is a similar concept.

Of course, autoupdate would need to be disabled for this to be meaningful.

3

If you can compile an addon yourself; I implemented exactly what you’re looking for, but I never published it on the marketplace:

Switch valve {channel="xxx" [profile="basic-profiles:redeliver-command", numRedeliveries=3, redeliverDelayMillis=1000] }

4

Perfect, many thanks!

5

Ok, seems compiling an addon is not so easy after all. If its not too large, maybe you could add the jar to the repo ?

Edit: forget it. It would probably not work for some version/depenency reasons. Man, that is some rabbit hole. I will probably brick my installation if I continue down this path.

6

I have a rule for that now but it is very messy. Multiple items per rollershutter and constructing their names with string operations. Poor mainainabliity too.
I wanted a cleaner solution. Really a pity that doesn’t exist.

I have so many transmit failiures all over the house:

  • rollershutters (homematic 868 MHz)
  • Heater (Viessmann IR interface)
  • Multiple ESP8266 wifi devices
  • Hue

Actually, these failures happpen to all my actuators, with variying intensity though. Rollershutters are the worst and most noticable.

7

If you want help making the rule less messy I can help with that. Using the “Associated Items” design pattern with an Item naming scheme is not the only way to achieve this. There’s the semantic model, Item metadata. It might be possible to do something from a profile to help.

One major way to avoid a lot of these transmission errors in the first place is to make sure commands to Items using these technologies gets spaced out so there are not too many all at once overwhelming the transceivers. The Gatekeeper design pattern (available through openhab-rules-tools) can be used to help make sure commands get spaced out and do not overload the transmission so that some commands get lost. There’s no need to retransmit if the messages don’t get lost in the first place.

You can of course create an issue in core and see if someone volunteers to implement it.

Or you can write issues on the individual bindings that show these problems and see if the maintainers of those bindings are willing to implement a retransmit in the binding itself.