Worx Landroid Binding

Add-ons Bindings
, ,
729

Can you please file an issue so I don’t forget it ?

730

I was referring to @Bramante 's plugin shared here: Worx Landroid Binding - #716 by Bramante

I think this is a different one from yours, right?

731

I would like to bring up my issue with the second schedule again.

As a result, the next start and next stop are also incorrect

732

Thx a lot, tested with openHAB Snapshot #5380, works :+1:

733

Are you talking about Channels schedule#next-start and schedule#next-stop?
Those work fine in the official, now merged binding and are showing the correct time.
Note that you need a recent snapshot of openHAB to get rid of the above mentionend error.

Edit: Ah, you are talking about more than one timeslot. Can’t verify, I only have one time slot per day. If I have a lot of spare time, I will try to check that out …

734

Okay, I had a lot of sparetime now :smiley:: as I already assumed above, the times are correct:

Screenshot20260519-191521.Worx Landroid2
Screenshot20260519-191521.Worx Landroid21080×1132 60.4 KB

worxbasic
worxbasic1073×119 16.2 KB

735

Ok, I will wait for the next release.:slightly_smiling_face:

736

Outbound commands fail with “commandIn when connection is closed” – inbound status only works intermittently

Setup

  • openHAB 5.1.4
  • Worx Landroid binding 5.2 (the rewrite), installed manually as a JAR in addons/
  • Device: Worx Landroid (product PRM100), cloud / AWS-IoT connection
  • Thing reports ONLINE

Problem

Outbound commands are not delivered to the mower. Whenever openHAB tries to publish a command, the binding logs:

[WARN] [worxlandroid.internal.mqtt.AWSClient] - Tried to publish on PRM100/<MOWER_SERIAL>/commandIn when connection is closed

The command is accepted by openHAB (the item state changes) but never reaches the mower. This affects every outbound channel I tried (one-time edge-cut, the AWS poll/refresh channel, the START/HOME action).

Key observation: the connection is asymmetric

The inbound and outbound MQTT paths seem to fail independently:

  • Inbound status (commandOut) works intermittently – occasionally a status push arrives and updates the channels correctly.
  • Outbound commands (commandIn) are consistently refused with “connection is closed”.

Timeline from one evening:

  • ~18:00 the AWS session degraded; the status channel then froze on its last value (it showed MOWING for ~1.5 h while the mower was actually docked).
  • I restarted both the bridge (disable/enable) and power-cycled the mower.
  • 19:32:22 a single inbound status push arrived → status corrected MOWING → HOME. So inbound recovered briefly.
  • 19:35 I triggered the AWS poll/refresh channel → no response, immediately commandIn ... connection is closed.
  • 19:39:42.955 a one-time edge-cut command was accepted by openHAB → 19:39:42.958 (3 ms later) Tried to publish ... commandIn when connection is closed → command lost.

Restarting the bridge and physically restarting the mower did not restore the outbound channel.

Misleading indicators (FYI for others debugging this)

While commandIn is dead, none of the usual “is it connected” signals are reliable:

  • Thing status still reports ONLINE (false positive).
  • The aws#connected channel does not reflect the real send state.
  • The status channel freezes on its last value instead of going stale/UNDEF.

The only reliable “live” signal I found is data freshness: the config#timestamp channel advancing. If that timestamp stops moving, outbound commands fail – regardless of what Thing status / aws#connected report.

Also seen around reconnects

[WARN] [worxlandroid.internal.mqtt.AWSClient] - Tried to unsubscribe from PRM100/<MOWER_SERIAL>/commandOut when connection is closed

Questions

  1. Is this a known AWS-IoT session / reconnect issue in 5.2?
  2. When a publish fails, should the binding automatically re-open the MQTT publish connection, or is an external bridge reset expected?
  3. Are there any keep-alive / reconnect-interval settings that influence AWS session stability?

I have rolled back to the 4.2 JAR for now because the mower is a shared family device and needs to stay controllable. Happy to re-install 5.2 temporarily and provide full TRACE logs of AWSClient if that helps narrow it down.

737

I would not invest too much time in troubleshooting an 5.2.x binding on an older 5.1.x core.

I cannot answer your questions, but in openHAB 5.2.0.M5 the Worx binding (also 5.2.0.M5) is working fine.

Auswahl_001
Auswahl_0011063×850 88.2 KB

738

I’ve just tried out the new official binding in OpenHab 5.2, but I get the known error because I also have one regular Landdroid and one Landdroid Vision (WR20E) robot: Vision model not found · Issue #105 · nibi79/worxlandroid · GitHub

I found out that this was solved by a separate addon in the past. Could this now also be solved in the official addon?

739

Hi

have opened an issue

BR

mitch