Z-Wave - Filter REFRESH command logging

I recently added fairly aggressive REFRESH commands to a Z-wave light switch to work around its slow polling interval for controlling a set of LiFX lights. This solves the slow response problem, but its cluttering my event log with entries like the following:

2018-01-06 10:23:02.025 [ome.event.ItemCommandEvent] - Item ‘Living_Room_Light_Switch’ received command REFRESH

I don’t really need to see REFRESH commands in the event log, but I can’t figure out if its possible to filter them out. Is there any way to do this?

I used this thread to get my Z-Wave logging under control: Taming openHAB 2 Logging

specifically, I modified org.ops4j.pax.logging.cfg (which is located in different places depending on your OS) and added this to the end. I can’t recall if the modifications I made earlier in the file were necessary to activate logging this to a different file (in my case, zwave.log wherever openhab.log usually resides):

Z-wave custom logging

log4j2.logger.zwave.name = org.openhab.binding.zwave
log4j2.logger.zwave.level = INFO
log4j2.logger.zwave.additivity = false
log4j2.logger.zwave.appenderRefs = zwave
log4j2.logger.zwave.appenderRef.zwave.ref = ZWAVE
log4j2.appender.zwave.name = ZWAVE
log4j2.appender.zwave.type = RollingRandomAccessFile
log4j2.appender.zwave.fileName = /var/log/openhab2/zwave.log
log4j2.appender.zwave.filePattern = /var/log/openhab2/zwave.log.%i
log4j2.appender.zwave.immediateFlush = true
log4j2.appender.zwave.append = true
log4j2.appender.zwave.layout.type = PatternLayout
log4j2.appender.zwave.layout.pattern = %d{dd-MMM-yyyy HH:mm:ss.SSS} [%-5.5p] [%-50.50c] - %m%n
log4j2.appender.zwave.policies.type = Policies
log4j2.appender.zwave.policies.size.type = SizeBasedTriggeringPolicy
log4j2.appender.zwave.policies.size.size = 10MB
log4j2.appender.zwave.strategy.type = DefaultRolloverStrategy
log4j2.appender.zwave.strategy.max = 10

Do you mind elaborating a bit on the use of REFRESH commands (especially in the context o Z-Wave devices). I was not aware that such a command existed…

Sure, although I worked around it by changing the device in question. The use case was a GE z-wave dimmer switch that didn’t necessarily report the dimmer state immediately to the controller. I didn’t have it directly controlling the lights, I was using its setting and set setting the (Always on, Wifi controlled) lights based on that setting. By sending a frequent refresh, I could update the light state from OpenHab, rather than waiting on the switch to send its state which would take minutes and was useless.

I abandoned the dimmer switch in favor of an on/off switch that instantly updated state, and I controller dimming via OpenHAB, the LiFX app or Alexa instead.

OK, then I understand your use case. I don’t fully understand how the REFRESH command works, though.

I assume that the ‘Living_Room_Light_Switch’-item in your original post is supposed to be updated when someone operates the physical switch, right? As I understand it, this did not happen as quickly as you wanted (immediately), and you could solve (or rather, work around) this by sending a REFRESH command to the item to “force” the device to update the item/channel. Is this correct?

In my setup, all my Z-Wave switches/dimmers seem to send immediate updates (as they should IMO!) when someone is operating them, however, when I restart my openHAB server it may take quite some time for the system to get a correct state of the switches - unless someone happens to operate them.

I suppose this could be a case for using the REFRESH command, i.e. at “System started”. What do you think?

The system internally does a refresh on restart, so there’s no need to do this.