Manufacture 87, Hardware 0 , Firmware 1
This was after a "Read Full Sheet" on that page in Decoder Pro?
I don't understand the addresses we are looking for in TC.
LocoNet devices that SEND status to TC send an Event ID - which is just a unique number. It doesn't matter what the number is, it just identifies the sender of the event.
In this case it is an "occupancy event".
Now TC bases its entries for Contact Indicators on the Digitrax BDL16 family. With this product the BDL16x is assigned an Address. When an input is activated an Event ID is generated that is derived from the board Address and the active Input.
These are the values you see when configuring the TC Contact Indicator for the Block.
Instead of entering the raw Event ID (which is what is actually sent by the BDL16x), you enter the BDL16x board Address and the Input you wish the Contact Indicator to respond to. TC does the same computation that the BDL16x does to compute what Event ID the board is going to send.
All manner of these Event IDs arrive at TC. TC needs to know what Event ID corresponds to what piece of hardware, or in this case, what occupancy sensor. When TC sees the Event ID that is configured for a certain Contact Indicator it marks the Block occupied. Actually the Event ID is sent in such a way that TC can determine if the occupancy sensor is turning on (the block is occupied) or turning off (the block is unoccupied).
With the Digitrax BDL16x all of the Event IDs sent are going to be sequential, let's say 1 through 16, corresponding to Input 1 through 16.
Now the WatchMan simply sends an Event ID that is not in anyway associated with the WatchMan board address. This is the "Primary Event" value that you enter. They can be sequential, as the BDL16x does, or random. Since TC expects to see the Event IDs as a BDL16x would send them you need to enter Event IDs that match what the BDL16x would send for a given BDL16x board Address and Input.
This is the information I am not sure about as I have never used a BDL16x and have never examined the values it sends. I am assuming that it takes the board Address, subtracts 1 and then adds the Input number. So for a board with Address 1, Input 5 would generate an Event ID of 5 (1 - 1 + 5). For a board with Address 32, Input 3 would generate an Event ID of 34 (32 - 1 + 3).
I really need to track down the BDL16x documentation and see what it actually does.
I didn't think we needed to do this here as I fully expected TC to find the active coil and simply tell us what Address and Input it "found" for the "Primary Event" value we entered for a given WatchMan input.
Now that is a lot of information so let me try to sum up.
You configure a TC Contact Indicator with an Address and Input. From these two values TC computes the Event ID that a BDL16x would send. When TC receives this Event ID (with the ON or OFF modifier) it marks the Block as Occupied or Unoccupied.
The WatchMan simply sends the Event ID that you enter for each input, independent of the Watchman board address. As long as this Event ID is the same as a BDL16x would send then everything works as if TC was receiving Event IDs from a BDL16x.
Contrast this with the situation when TC is controlling a loco. You configure a TC Engine with a certain Address. TC send commands to this address to control the loco. When loco decoder sees it's own address it responds to the commands from TC.