I have a weird issue: I want to close the rollershutters automatically when it gets dark outside. To not rely only on one sensor, I use the three outdoor sensors around my house, which I have grouped in a group called gLuxAUS:
Group:Number:AVG gLuxAUS "Helligkeit Aussen [%.1f Lux]" <sun> (gSensors)
As you can see, I want that group to provide me an average of the sensors, so I can do a simple
if (gLuxAUS.state < 10)
to decide that it’s dark (it’s actually not that simple and I have used as DecimalType.intValue but to keep it readable here).
However, the value is not reliable. Just now, for instance, I have the following entry in the log:
2017-09-01 08:57:15.856 [GroupItemStateChangedEvent] - gLuxAUS changed from 858 to 899 through LUM_AUS_UG_Terrasse
2017-09-01 09:06:24.423 [GroupItemStateChangedEvent] - gLuxAUS changed from 4.7 to 899 through LUM_AUS_UG_Terrasse
2017-09-01 09:13:15.818 [GroupItemStateChangedEvent] - gLuxAUS changed from 899 to 966 through LUM_AUS_UG_Terrasse
2017-09-01 09:29:15.810 [GroupItemStateChangedEvent] - gLuxAUS changed from 966 to 1000 through LUM_AUS_UG_Terrasse
which means that the group has gone to 1.000 but a log output of the group itself from a rule shows
2017-09-01 13:41:30.166 [INFO ] [.smarthome.model.script.ILLUMINATION] - Current group gLuxAUS: gLuxAUS (Type=GroupItem, BaseType=NumberItem, Members=3, State=899, Label=Helligkeit Aussen, Category=sun, Groups=[gSensors])
and so does the Text item=gLuxAUS entry in the sitemap.
So it’s stuck at the value before the value before the last value. Since the logs also showed that the value has changed, I wonder what has happened. Does anybody have an idea where the problem might be?
Thanks in advance.
Create a rule that triggers when gLuxAUS changes and log the state of the Item from there.
I want to separate the Rules from the sitemap for now.
See if the rule is triggering for each change or not. If not, see if this pattern (i.e. being two values behind) continues.
Are you using persistence anywhere?
first perhaps I should also mention I’m running OpenHAB 2.1.0 from the stable apt repository on a Core i3 Ubuntu machine.
I’ve been doing that what you suggest (hence my observation from the log entries above) and had the rule triggered by a change. I will do as you say and add more logging to observe the pattern of how it stays behind.
Another thing I’ve noticed though is, that at the moment there seems to be a problem with the propagation of changes to other groups in my setup as well. For instance, I have a group that is defined with Switch:OR(ON,OFF) for my lights and though I’ve turned all lights off, the Group stays on.
I’m not seeing any errors reported in the logs. I will report back once I’ve collected some more data (presumably over the weekend).
I’m using RRD4J and Influxdb for persistence. In this case influxdb is the one storing the values of the group members.
Have you restarted OH? There have been a number of Group related updates that have been made before 2.1 and several after. Maybe this is a bug that has already been fixed. Does it do the same in 2.2 SNAPSHOT?
it seems the problem has gone. I am not sure yet, but it might have been related to a change of the Z-Wave stick I used. I had an old Z-Wave stick in my machine, which I replaced with a new Z-Wave Plus stick and I included all devices from scratch as a consequence (I haven’t heard yet about a “transfer” from one stick to another).
Since I also had some other problems, I uninstalled the Z-Wave binding, removed all devices and the /var/lib/openhab2/zwave directory and did a hard reset to the new controller. Then I installed the binding again and added each device again and now it seems working.
I will report if this is not just by chance, and if I still observe the problem, but currently all works and groups update correctly.
Thanks again for your help and your hint with restarting actually made me think of the option to uninstall / reinstall the binding.
okay - problem is not gone. Might have disappeared due to reboot but came again tonight, that the sitemap, e.g., shows one value for the group though the chart shows a different (and the logs).
I will see if I get the time to install a snapshot 2.2.0 and how that behaves (though I’m not suer whether I’ll make that soon, as I wanted to stick to a stable OH as I had a lot of bad expereiences when using 2.1 snapshot vs. 2.0 stable and this time wanted to stick to the stable).
One thing I also did was a complete reconfiguration of my groups when I changed the Z-Wave stick. Is it possible that OH got confused by that? Can I somehow clear all configuration caches via Karaf?
Thanks for your help! Cheers!
You can try deleting the contents of /var/lib/openhab2/cache and tmp but I don’t think group and item stuffy is stored in the folders. But deleting those will give you as close to a fresh install as you can get without starting over from scratch.
You won’t lose any others it groups or other settings.
I think I found the problem: I had 2 rules named the same rule “name” (though in two files), where one did a calculation on the group members to set an item to the average value, while the second rule checked either the group or that value as trigger. It seems that same names of rules create problems (though this was not on purpose).
I though have to wait a day to see it will work reliably, but quick tests seemed to do so. If not, I’ll try your tip with deleting those folders.