I think the point is that if your logging was working you would likely have seen this as soon as you looked for a problem.
I don’t know what that is about, my random fix would be to stop openhab; delete (or rename) all log files; restart and let it create anew.
You are right about correct logging.
I have tried variations of deleting openhab.log and I think it never came back. I had to pull it from Trash to get it back updating.
I’ll do something but later.
Thanks again for all the hand holding and help.
The above has a serious error. You cant have a Number element type in your sitemap.
Please take a few minutes to look at the docs for Elements types and examples:
https://www.openhab.org/docs/configuration/sitemaps.html
Thanks.
I wasn’t really using misc. It was something I started and decided wouldn’t be useful.
But thanks for pointing out the folly of my attempt.
These random characters may indicate an issue with the Pi’s power supply or SD-card… 
They are not random. events.log inserts about 800KB and openhab.log inserts about 2.5MB. All the bytes are 0x00, call it the blast.
It seems that if a report is going to be added to either log, and if the blast of 0x00 is already there, the new report is just tacked on after the last entry just like it should be. Of course all the entries are after the blast.
If I delete the blast and leave the entries at the front of the log, then when a new entry needs to be added something checks and says, “this file doesn’t have the blast, time to blast it”. I will end up with the old entries at the front followed by the blast followed by the latest entry. Subsequent entries will just be tacked on (no more blasts) after the last entry.
Unfortunately to see the entries at the end, I use the LibreOffice writer which takes a few minutes to load all the blast. I’m not good enough with Vim to page on down 526 pages to see the end.
rossko57. It worked. I stopped openhab. renamed the files and restarted.
Both events and openhab are back to reasonable size and new entries just get tacked on after the last one.
I believe what was happening was, for each log there was a counter keeping track of how many bytes were written to the file. When I kept deleting big chunks the counter didn’t “know” about it. So when it came time to append an report it just wrote the report at where the counter pointed. The result is the space from byte 0 to byte (counter-1) was blank=0x00…
Anyway you solved two of my problems in one thread.
Over the top!
Thanks,
Pete