text: Thread: With two main repeaters will the console report the same data on both?
  02-19-2016, 01:18 PM #1
  I have a setup with two main repeaters (using Inclusive 9.2 and more than 100 devices).
  Will the serial ports on them both report the same data?
  It appears they each have their own MONITORING states, which is convenient.
  However, when they're both set to the same MONITORING states, one emits different data than the other.
  Specifically, when a Pico sends a command the console on the second repeater (the one that appears second in the list within Inclusive) reports:
  ~DEVICE,182,2,3
  ~DEVICE,182,2,4
  Preset ID:     7da5 does not pertain to a device on link 0. Do nothing
  The italicized line does not appear on the other (1st?) main repeater.
  The Pico is paired to the second repeater. The device the button is controlling is on the first repeater. I take it this message is telling me the device command isn't relevant to this repeater? Am I going to see other messages like this when there's cross-repeater programming set up?
  It's pretty inconvenient having hex values here, but not in the xml dump. That '7da5' is hex for 32165. However, the device in question (182) does not have that in the DbXmlInfo dump.
  <DeviceGroup Name="Bill&apos;s Desk" SortOrder="0">
  <Device Name="Bill&apos;s Pico" IntegrationID="182" DeviceType="PICO_KEYPAD" GangPosition="0" SortOrder="0">
  <Component ComponentNumber="2" ComponentType="BUTTON">
  <Button Name="Button 1" ButtonType="SingleAction" PrimaryActionType="3" SceneSaver="false" CycleDim="false" AllowDoubleTap="false" StopIfMoving="false" ProgrammingModelID="32164" LedLogic="2" ReverseLedLogic="false">
  <Action Name="Press" ActionType="3">
  <Preset Name="Press">
  <PresetAssignments>
  <PresetAssignment AssignmentName="GOTO_LEVEL" AssignmentType="2">
  <Delay>00:00:00.00</Delay>
  <Fade>00:00:00.00</Fade>
  <Level>100.00</Level>
  <IntegrationID>127</IntegrationID>
  </PresetAssignment>
  </PresetAssignments>
  <Component ComponentNumber="3" ComponentType="BUTTON">
  <Button Name="Button 2" ButtonType="SingleAction" PrimaryActionType="3" SceneSaver="false" CycleDim="false" AllowDoubleTap="false" StopIfMoving="false" ProgrammingModelID="32170" LedLogic="2" ReverseLedLogic="false">
  <Level>75.00</Level>
  <IntegrationID>120</IntegrationID>
  <Component ComponentNumber="4" ComponentType="BUTTON">
  <Button Name="Button 3" ButtonType="SingleAction" PrimaryActionType="3" SceneSaver="false" CycleDim="false" AllowDoubleTap="false" StopIfMoving="false" ProgrammingModelID="32172" LedLogic="2" ReverseLedLogic="false">
  <Level>0.00</Level>
  <Component ComponentNumber="5" ComponentType="BUTTON">
  <Button Name="Button 4" ButtonType="SingleSceneRaiseLower" PrimaryActionType="3" SceneSaver="false" CycleDim="false" AllowDoubleTap="true" StopIfMoving="false" Direction="Raise" ProgrammingModelID="32166" LedLogic="4" ReverseLedLogic="false">
  (...I'd include more but the forum software complained)
  On the other repeater I see the same kinds of messages, but the hex numbers don't seem to coincide with anything.
  It's almost as if the conversion to the ProgrammingModelID for these isn't being converted properly? Either in the logging or in the XML dump. I can't tell.
  02-22-2016, 02:05 PM #2
  Good Morning, when monitoring the system you should only be logged into 1 Main Repeater to monitor the system.
  02-22-2016, 02:32 PM #3
  Should, because of what side effects? I get why you'd probably want to avoid using more than one port to control devices, but for monitoring? Is there some aspect of load on the repeater or something that would make simultaneous monitoring a bad idea?
  This, of course, leads to the question of "only one main repeater via just serial OR ethernet at the same time?" Is there something that would make it a 'bad idea' to monitor from both IP and RS232 simultaneously?
  I'm asking now as a means of avoiding surprises later.
  02-22-2016, 03:18 PM #4
  Preset ID: 7da5 does not pertain to a device on link 0. Do nothing
  On the other repeater I see the same kinds of messages, but the hex numbers don't seem to coincide with anything. It's almost as if the conversion to the ProgrammingModelID for these isn't being converted properly? Either in the logging or in the XML dump. I can't tell.
  Are there answers forthcoming on these questions? Or is there a 'no comment, you're on your own to work around' scenario involved here?
  02-23-2016, 02:18 PM #5
  If monitoring 2 Main Repeater at the same time, the Repeaters may send feedback with different priorities which could cause incorrect feedback to a 3rd party system.
  02-23-2016, 06:03 PM #6
  Ok, that makes sense. They're "pretty close" in their times when sending, but as I've noticed with cross-repeater instructions (as in Preset ID: 8812 does not pertain to a device on link 0. Do nothing) there's a slight delay. None of this it time critical, certainly not beyond the speed of a 9600 baud link).
  I have no intention of running both at the same time for the purpose of interfacing with the same external solution. But it sure does make debugging a whole lot easier having two live and stable serial outputs.
  Most importantly it's shown there are going to be messages sent from the repeaters that aren't in the documentation for the protocol. Some of which might be important enough to warrant paying attention if they happened with any kind of frequency.
  02-27-2016, 01:49 PM #7
  You should ignore debug output produced by repeaters. You receive this debug output because you chose the wrong MONITORING parameters.
  02-27-2016, 06:36 PM #8
  Seeing as how the extraneous output is not documented anywhere it's hard to know what should or shouldn't be ignored. I prefer not to assume.
  As for 'wrong' parameters, where did I indicate which mode I wanted to use?
  I believe in trying to be thorough when making use of a vendor's interface. If only because many times the documentation and firmware for devices (from various vendors) doesn't necessarily cover what could be significant problems. Pardon me if that's somehow a problem for you, it wasn't my intention.
  02-27-2016, 07:12 PM #9
  LOL, that's not a problem for me, and not even my problem at all! If you look in the integration document, MONITORING,1 is documented as "Diagnostic Monitoring", so that is what you get - diagnostic output. The only things you really should be focusing on are those which start with #~? and end with one of the command names.