MONITORING documentation?

Is there anything that breaks down the full range of what the different MONITORING levels will emit to the console? Which in my situation happens to be a serial port on a main repeater.

For example, when using #MONITORING,1,1 I got this line when pressing a Pico button:

When updating from a client (after editing a timeclock event time) it sends FLASH WRITE, two times. Will it always send it twice? I tried this from both an Android and an IOS client.

When using Inclusive it sends

Code:

---

Autodetect received : <LUTRON=1>
LUTRON received - 1

---

And then proceeds to march through what appears to be setting a bunch of defaults for DEVICE and OUTPUT integration IDs. Sometimes it sends the above snippet twice, other times three?

Is there a defined "end" to the transfer that would get sent out the serial port? I ask this particularly because of the unpredictable delay that can occur when trying to do a transfer. Sometimes the transfer gets hung up at 97% or 99% "for a while" before either completing (or not). Leaving the Transfer tab does not lead to anything being sent to the console. With #MONITORING,255,1 I'm not seeing anything that looks like an end of transfer.

Here is a link to our integration protocol guide, http://www.lutron.com/TechnicalDocum...ary/040249.pdf , you can use this to see what the monitoring command can be utilized for.

Yes, I'm aware of what the documentation indicates, thanks for the link. I've had it open in a PDF viewer for a quite some time now. I try not to ask questions regarding things that are already clearly documented.

I'm specifically asking is there an output stream that will come from the repeater to indicate there has been a change made by the PC software? If there's not, then please forward a feature request for something that would do it.

While they're at it, how about something that reveals from WHERE the action was initiated. Right now I've got an RS232 window open to the main repeater. I have no Lutron software open. I have no apps running on any clients. But the repeater just sent out:

Code:

---

FLASH WRITE
FLASH WRITE
~SYSTEM,02/22/2016,13:41:43

---

Um, Ok... why?

I launched the app on an Android device and checked my timeclock events and nothing's set to fire anytime around this.

I'd very much like to create a reliable interface. I'd very much to avoid constantly polling the repeater. I'd hoped to be able to use the monitoring stream to maintain an on-going state for devices. Were I seeing just what's documented in the PDF I wouldn't really be asking these questions. I'm running across data being emitted that's NOT documented and isn't formatted similarly to documented output, or even predictably. So I'm either looking at undocumented output or bugs. I'd gladly file a bug report if there's a way to do so.

Thank you for your suggestion. I will pass this to our System Development team.

That ~SYSTEM,TIMESTAMP line which you observed, you stumbled on a known issue in the 9.2 software. If you read the 9.3 release notes, it is acknowledged there.