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:
- 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
- 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 https://github.com/openhab/openhab/blob/master/bundles/binding/org.openhab.binding.maxcul/src/main/java/org/openhab/binding/maxcul/internal/MaxCulMsgHandler.java, we’d perhaps change
logger.error("Transmission of packet " + qi.msg.msgCount + " failed 3 times");
to
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.