Maxcul retry logic: proposed extension

I have my setup largely working with MaxCul. I have 12 valves, 2 thermostats, and a reasonably large single level house. I’m getting quite a few timeouts when sending to the valves which I presume is due to distance (although to be fair the valves giving errors aren’t far from the dongle), and I’m considering options to improve this.

At present my valves are organised into zones, and the valve setpoint is set when the zone ticks over to a new time period. I let people adjust the valve temperature between these times - so if my setpoint is 21, they can adjust to 22 or 23, and when the zone setpoint next changes it will return to the programmed value.

When I get a timeout, I get one of two results:

  1. It silently fails (message in the log “Transmission of packet xx failed 3 times”), and Openhab thinks that setpoint is different than what is written on the device, OR
  2. The device reports its setpoint (perhaps because a valve opening changed), so we know it’s wrong, but nothing happens about it.

The combination of situation 1, with the desire to let people override the temperature setting, means I cannot just blindly retransmit the setpoint every half an hour to try to overcome it.

My first question is whether anyone knows of tips/tricks to stop the send failing - perhaps there’s a configuration option I could change. My suspicion is that there isn’t, but it’d be great if there were.

Ignoring that option, I’d like a way for my code to know that the send failed. I’m thinking of a few options.

First option, write a better log message, and do something outside openhab to read the log and make decisions. So, at line 278 of, we’d perhaps change

logger.error("Transmission of packet " + qi.msg.msgCount + " failed 3 times");


logger.error("Transmission of packet " + qi.msg.msgCount + " failed 3 times sending to device: " + msg.dstAddrString + " of type: " + msg.msgType );

Then I’d know which device failed, and what message we were sending to it, and could write some code to retransmit just that device’s setpoint. The main disadvantage here is that I’d need to write logic outside Openhab to process this.

The second option is more complex, and would involve introducing a new feature that we can bind to an item - perhaps along the lines of:

DateTime lastErrorTime { maxcul="WallThermostat:JEQ1234567:feature=lastErrorTime" }
String lastErrorType { maxcul="WallThermostat:JEQ1234567:feature=lastErrorType" }

This would get set to the current date time whenever a timeout error happened. A user could reset to null when they’d processed the error - so then my rules could have a when changed lastErrorTime and/or when changed lastErrorType.

This feels like a more complete solution, but I think my java skills would be quite stretched to actually code it (very many years since I coded anything in Java, and I recall it being exceptionally fiddly…so whilst I could in theory make the first adjustment because it’s a one line change, the latter one would be quite large and involve me spending a lot of time installing and IDE and remembering how to even code java)

Thoughts or advice would be welcomed.

One option would be to just extend the number of retries - rather than having an error flag that I can then look at and probably manually initiate a retry anyway Obviously this would involve making the retry threshold configurable. Any thoughts on how best to do that?

And, after more reading and thinking, obviously the answer is to not have the CUL dongle drop packets. So, after looking more closely at the hardware and the website I bought it from, I see I can fit an antenna to improve the range. With hindsight I should have bought one with an antenna in the first place. I’ve ordered a 7dbi 868Mhz antenna, and will solder on an SMA socket. We’ll see if that fixes the problem.

I tried fitting an antenna to my existing dongle, which improved things a little, but not enough. I decided that might be my soldering at issue, so I bought a new dongle with a factor fitted large antenna. I’m still getting a lot of dropouts, even for valves in the same room as the dongle.

Has anyone had this issue with MaxCul devices? I’m starting to think the valve hardware may be faulty, or perhaps the hardware is not particularly reliable.