Sending a command or posting an update to an Item happens asynchronously. This means if you are trying to log the state of the Item immediately after commanding it, it almost certainly will not be the new state.
What do you see in events.log? Do you see any errors in openhab.log?
I’m not sure where you found that syntax. You should be seeing an error in the logs saying something like Item has no method getTime(number) or something like that.
items.getItem('name') returns an Item, not a Date, DateTime or anything like that. See that link for what an Item does have.
You also misstyped isBefore.
If you want to see if the state of an Item is at least 15 minutes in the past.
Creation of event failed, because one of the registered event factories has thrown an exception: Error getting class for simple name: ‘$ProxType’ using package name ‘org.openhab.core.library.types.’.
java.lang.IllegalArgumentException: Error getting class for simple name: ‘$ProxType’ using package name ‘org.openhab.core.library.types.’.
at org.openhab.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:183) ~[?:?]
at org.openhab.core.items.events.ItemEventFactory.parseType(ItemEventFactory.java:158) ~[?:?]
at org.openhab.core.items.events.ItemEventFactory.createCommandEvent(ItemEventFactory.java:109) ~[?:?]
at org.openhab.core.items.events.ItemEventFactory.createEventByType(ItemEventFactory.java:78) ~[?:?]
at org.openhab.core.events.AbstractEventFactory.createEvent(AbstractEventFactory.java:53) ~[?:?]
at org.openhab.core.internal.events.EventHandler.createEvent(EventHandler.java:131) ~[?:?]
at org.openhab.core.internal.events.EventHandler.handleEvent(EventHandler.java:106) ~[?:?]
at org.openhab.core.internal.events.EventHandler.handleEvent(EventHandler.java:84) ~[?:?]
at org.openhab.core.internal.events.ThreadedEventHandler.lambda$0(ThreadedEventHandler.java:67) ~[?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.lang.ClassNotFoundException: org.openhab.core.library.types.$ProxType cannot be found by org.openhab.core_3.4.0.M4
at org.eclipse.osgi.internal.loader.BundleLoader.generateException(BundleLoader.java:529) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.internal.loader.BundleLoader.findClass0(BundleLoader.java:524) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:416) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:168) ~[org.eclipse.osgi-3.17.200.jar:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:522) ~[?:?]
at java.lang.Class.forName0(Native Method) ~[?:?]
at java.lang.Class.forName(Class.java:315) ~[?:?]
at org.openhab.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:179) ~[?:?]
… 9 more
it seems even the first part is not working ;(
in case of postUpdate:
First, consider whether the timestamp profile would be a viable alternative here.
Secondly, you will notice in the docs that sendCommand and postUpdate on Item takes a String and only a String.
Next, there’s a “bug” with internationalization right now that makes parsing a Joda ZonedDateTime not work properly so using a LocalDateTime and calling toString on that is recommended.
The call to getItem() also requires a String, the name of the Item. You must put the String in quotes.
There is a shorthand built into the library that will convert just about anything to a ZonedDateTime: time.toZDT(). It’s much shorter to type and read than time.ZonedDateTime.now().
Finally, it doesn’t make much sense to send a command to a DateTime Item. It’s not causing something to happen. It doesn’t need to cause a binding to cause a device to do something. postUpdate is more appropraite.