I’d also forgotten to attach the transformation map to the Modbus control item. It seems that you can control the bypass without switching to Modbus control, oddly, but not the ventilation flow rate.
I managed to set up a daily backup and copy it to a network drive by running the two relevant scripts in cron jobs. I realised that I need to use the root crontab to run both, the backup because it requires root, and the copy because it has to run under a different user.
I’ve swapped the hard drive for a USB stick to hold the logs. I got an ultra-slimline stick because cramming four USB devices into the four ports of the RPi is tricky. The Enocean and Z-Wave adapters are bulky and barely fit.
I’ll probably move the backups to the USB stick too, to avoid more SD card wear and tear.
Using this backup command you can specify the location of the backup file:
openhab-cli backup --full /my/alternative/backupdir/openhab2-backup-$(date +"%y_%m_%d-%H_%M_%S").zip
Now it would be nice to also relocate the tmp dir to the USB stick.
I think I’ll skip moving the tmp dir. Reading around, it sounds like a recipe for trouble.
I finally got around to make a couple of clones of the SD card using Win32 Disk Imager. I tested the first copy I made and it seemed to boot up OK, but my (one and only) rule didn’t load. It turns out that the “lock” tab had been moved down on the card - so quite how any copy was made at all, I don’t know. With this fixed, and running W32DI as admin just in case, I made two copies and tested them without problems.
At some point I’ll look into Amanda.
After beating my head against the wall for about an hour, I managed to filter out some garbage from openhab.log using this super-useful thread: openHAB - Filtering event logs. This is my filter:
log4j2.appender.out.filter.stuff.type = Filters
log4j2.appender.out.filter.stuff.Modbus1stConnectionRefused.type = RegexFilter
log4j2.appender.out.filter.stuff.Modbus1stConnectionRefused.regex = .*connect try 1/3 error.*
log4j2.appender.out.filter.stuff.Modbus1stConnectionRefused.onMatch = DENY
log4j2.appender.out.filter.stuff.Modbus1stConnectionRefused.onMismatch = NEUTRAL
Until I did it this way - which is intended to allow for multiple expressions to be added in sequence - I couldn’t get the filter to work. Doing it the other way:
log4j2.appender.out.filter.Modbus1stConnectionRefused.type = RegexFilter
log4j2.appender.out.filter.Modbus1stConnectionRefused.regex = .*connect try 1/3 error.*
log4j2.appender.out.filter.Modbus1stConnectionRefused.onMatch = DENY
log4j2.appender.out.filter.Modbus1stConnectionRefused.onMismatch = NEUTRAL
resulted in nothing appearing in the log at all.
I note Rich’s comment about filtering, but I continuously get this line in the log:
2020-06-12 02:07:29.649 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - connect try 1/3 error: Connection refused (Connection refused). Connection TCPMasterConnection@128737e[socket=Socket[unconnected]]. Endpoint ModbusTCPSlaveEndpoint@1c0cb5b[address=192.168.0.100,port=502]
and it’s 95% of the content.
Now I can move on to more productive things.
Of course, you might try to fix the underlying problem.
I’ll hazard a guess you are hitting your Modbus device too often with disconnect/reconnects.
Try holding the TCP connection open longer, try increasing time between reconnects
Modbus binding default settings should be considered “get you started”, not optimal for any given setup.
2 Likes
I could, of course, try to fix the underlying problem. The thought had crossed my mind. 
. Still, one thing at a time.
I tried augmenting the time the connection is held open to 10 seconds, and putting 5 seconds between reconnects, but it doesn’t seem to make any difference. 99.9% of the time, connect 1/3 fails, but the rest succeed. I’ll have a look at the tutorial and see if anything pops out.
In fact, even if I up the time to keep the connection open to a minute, and put 5 seconds between reconnects, I just get the error every minute+5 seconds.
Well, it is your slave actively rejecting the connection (as opposed to a no-response timeout etc.)
They can often be buggy, we have I think seen one before that never tidily closes a connection. Similar symptoms - always fails the next connection attempt, which prompts it to tidy up and succeed on the retry.
Unless there is anything you can change or update at the slave end, just tolerate it (the retry I presume always works)
Up the connection hold to hours, and reduce time between to a second or less (as we know it will always fail first time, there’s no point waiting)
Personally I’d tolerate the logging as well at that frequency, for fear of hiding real problems.
My reasoning is that, if there’s a real problem, there will be more failures after the first. So I prefer to remove that noise from the log.
I’m looking at my RTS blinds and awnings. It’s beginning to look as if there’s no way to recover the IDs being used by the Zipabox to pair with them, which means I’ll have to turn off the power to each one of the other (eight) blinds and awnings whilst pairing each of the nine with the RFXCom transmitter, which implies an all-or-nothing switchover from one controller to the other. I hope this isn’t the case, because far from being to play with the blinds and awnings to test them, I’d have to wait right until the end to move them. I’m wondering whether I could figure them out by trial and error - whether they’ll be easily guessable.
Unfortunately it looks as if, even if you could obtain the unit code/ID for each blind/awning, the RFXCom transmitter refuses to work with a code/ID that it hasn’t stored as a “remote”, which means you have to pair the device anew from the RFXCom using the “program” command… which means picking a new code/ID combination.
@marcel_erkel set me right. Apparently you can pair the same blinds multiple times with different remotes/controllers, and each pairing has different codes. I figured out the symlink stuff (to ensure the rfxcom has a consistent device identifier on each reboot) - read the tutorial! - and successfully added one of my blinds to openHab. I can now control it from both home automation systems. The ID.UnitCode that you need to put in the shutter thing configuration uses the decimal ID, not the hex ID. This tripped me up at first (although it’s in the tutorial!). You can see it in the rfxmngr output window, or just do the conversion on a calculator.
1 Like
Oh, there’s also some confusion about whether you need to cut the power to all other blinds and awnings before pairing one with rfxcom - you don’t, at least not with the Telis remote I have. You select the right one, and press the button on the back. Doesn’t interfere with the others at all.
Added all 4 blinds and 5 awnings to OH.
Now trying to work out how to add my Enocean sensors
Noticing that a lot has been going on in the Enocean binding, I decided to update OH to get the latest bindings. It turned out to be quite a bit more painful than expected. You get the choice of whether to overwrite the log config file with the new one or keep the modified version. I opted for the new one - I now keep a file with my modifications handy. My redirection of the logs to a USB stick was also overwritten, so I had to fix that. I have a file with a list of any modifications I make to files liable to be overwritten in a update. Then my one and only rule appeared not be working, but the problem turned out to be that the debug log is turned off by default for rules, whereas before it was turned on. This post describes how to modify the log configuration to turn debug logging back on, and also redirects the output to separate files, which is clearer:
Would be perhaps be a good idea to have a separate configuration file for custom additions and overrides to the log configuration, so that the default config can be updated without messing with these customisations?
It would also be a good idea if the update script would kick off the backup script for you 
! A persional custom logging configuration has been discussed and will likely be implemented in OH 3.0.
For the helper libraries, you can simply do this…
log:set DEBUG jsr223
… in the Karaf console, which is one of the entries from that post. I’ve also toyed with the idea of adding the log configuration to the Jython addon or into the default logging configuration file.
1 Like