@Rossko57
There are a couple of rules. One checks the time the sun is coming up and going down. Another one check the cloudiness at the moment of the sun going down. The third one switches the lights on ( 8 total in steps of 20 seconds) based on the sun going down and the cloudiness at that moment. The fourth one switches the lights off (in steps of 20 seconds). But these rules were running fine in OH2 and OH3. Also 4 temperature sensors could be read without out a problem. Rules 1 to 4 don’t use MQTT but a zigbee controller. The temperature sensor (SonoFF) flashed with Tasmota, use MQTT and gave no problems in OH2 and OH3. When I started with the Smart Meter the problem started. I have disabled the Smart Meter, but the problem consists. In /var/lib/openhab/persistence/rrd4j/ are in total 117 files present. That is in my opinion not much. The system is a MacMini I3 with 16 GB ram running Linux. Its the same system that was running OH2 without any problem at 4GB. So I don’t see that these rules are messing anything up.
Your environment is the unusual factor here. What Java version are you running?
I’m running linux Mint Mate 20.3, OpenHAB 3.2.0. Java =
java -version
openjdk version “11.0.14.1” 2022-02-08 LTS
OpenJDK Runtime Environment Zulu11.54+25-CA (build 11.0.14.1+1-LTS)
OpenJDK 64-Bit Server VM Zulu11.54+25-CA (build 11.0.14.1+1-LTS, mixed mode)
With regard to
what is the output of
sudo ulimit -aH
and
sudo cat /proc/sys/fs/file-max
@Wolfgang S
Thanks for the intererst in this problem. Below the output.
ulimit -aH output:
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 63291
max locked memory (kbytes, -l) 65536
max memory size (kbytes, -m) unlimited
open files (-n) 1048576
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 63291
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
sudo cat /proc/sys/fs/file-max output:
9223372036854775807
This seems to me very large!!
seems to be the maximum ( unlimited ) value on 64 bit systems.
OK,that should be the explanation. I looked at that before and I was convinced that that couldn’t be the problem.
Thanks for all the help and suggestions so far. They didn’t unfortunately stopped the malfunctioning of OH3.
I have started to install Openhab 3 at new, including defining things, items, rules and so on. After the declaring the first items and things, defining the first rules everything seems to work out quit normal without an automatic stop every day during the past 48 hours.
Hi,
after a couple of days the same behavior started again. I now have made an USB connection to P1 port of the smart meter. I have also installed the DSMR binding. with the standard setting. I’m able to read all channels of the smart meter. But after a couple of days the same behavior started again. Persistence service for RRD4J is installed and activated. I’ve made no rrd4j.persist in /etc/openhab/persistence/. So everything should be standard, out of the box. If I do in the terminal window sudo systemctl stop openhab.service and when the prompt returns sudo systemctl start openhab.service, everything works fine for a couple of hours. Some one any ideas what should/could be done to stop this behavior?
I made the next solution. As I’m using Linux Mint Mate 20.3, I modified crontab, that only openHab restarts every 12 hours. The modified crontab is now running for a week. Since the modification, I haven’t had any errors so far. So it looks like that this solved the problem. But for me it is strange that I’ve to use this workaround, where others don’t seem to have any problems with using a Smart Meter whether by using the DSMR binding nor by using the Smart Meter by Wifi. Will keep you informed the next weeks. Thanks for all the suggestions made.
The modified crontab is now running for several weeks without any stop. This seems to be the solution.