Platform information: Linux openHABianPi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l Release = Raspbian GNU/Linux 9 (stretch) Kernel = Linux 4.14.98-v7+ Platform = Raspberry Pi 3 Model B Rev 1.2 openjdk version "1.8.0_152" OpenJDK Runtime Environment (Zulu Embedded 8.25.0.76-linux-aar…

It’d be helpful to see the events.log for a working caldav-command update of your “min” Item [image] meingraham: And “[ItemStatePredictedEvent] … predicted to become” aren’t always there when a “received command” takes place. That’s correct. That comes from autoupdate, and (a) it only appe…

caldav.log (118.4 KB) The file I uploaded is every events.log entry associated with these Items since I implemented the CalDav binding a few weeks ago. Yes, the names are long… but this can’t be the reason as Min is the same length. UOM - yup. I am confused by this as well. But I defined them as …

I guess that’s a filtered log. It contains not a single instance of any openHAB Item state change.. Based on that, neither of your Items is working - but I expect its just a filtering thing? All I wanted was to see the expected events - command to min Item autoupdate prediction for min Item m…

I didn’t explicitly implement any log filtering myself. Is there somewhere I can look to clear any filters? This “filtering” is system wide as I don’t have any messages of that sort in my log for any Items, regardless of binding. I think that capturing the information you mention would be a good ne…

[image] meingraham: I didn’t explicitly implement any log filtering myself. Is there somewhere I can look to clear any filters? That’s weird then. Beyond my knowledge I’m afraid, hopefully someone else can help. Just to confirm, it is events.log we’re looking at. As for configuration, yes …

[image] meingraham: Yes, the names are long… but this can’t be the reason as Min is the same length. I don’t think we can be so sure. If the name gets truncated somehow, then it’s possible that only the first long Item matches. What if you made the different part between the two be at the fro…

Yes, events.log. Let’s see if anyone can weigh in on how I can get more detailed logging. As you can tell, I’m not relishing rolling name changes throughout all the Calendar entries. What we’re not discussing regarding reconfiguring or changing the naming convention is headed in that direction. Ca…

[image] meingraham: Yes, events.log. Let’s see if anyone can weigh in on how I can get more detailed logging. Have you modified your logging config? The missing lines we are talking about should just appear there as of OH 2.4. [image] meingraham: As you can tell, I’m not relishing rollin…

Can someone point me to where I can grab the original logging config file that came with 2.4 (release)? BTW, I uploaded my customized logging config in this post ( Item State not Updating - #10 by meingraham ) a couple of posts ago. The interesting thing is that the Max Item was receiving updates wh…

Out of curiosity, I used REST API to command plain numbers to an existing Number:Temperature UoM Item. (OH 2.4 release) Seems to work, accepting the value as being in the “current” dimension, °C in my case. events.log 2019-02-27 22:33:22.504 [ome.event.ItemCommandEvent] - Item 'nmt_CurrentTempera…

Item State not Updating

Setup, Configuration and Use Runtime

rlkoshak (Rich Koshak) February 28, 2019, 3:14pm 21

Good test and good to know.

I assumed the default would depend on your system settings.

There should be no differences.

It might help to shunt the logging for the CalDav binding to it’s own file. See Log4j2 Sample Config for an example.