Additional Accessory Definition Commands (Sensors)

[Asbelos]

We already have the facility to define a sensor essentially as a single pin test. This has a few limitations, for example:

• Forced continuous polling to transmit all changes to JMRI... (This is good for event-driven automations but not for route-following automations or RMFT)
• No direct support for inverted sensor (e.g IR detector converted to break-beam instead of reflection-detection.)
• No support for I2C extended pins
• No support for current detection sensors on analog pins.
• No support for LCN or remote sensor managers.

By extending the < S > command we could improve the range of sensor connection possibilities :

< S id PIN pinno [PULLUP] [INVERT] > < S id I2CPIN pinno [PULLUP] [INVERT] > < S id ANALOG pinno triggerval [INVERT]> < S id LCN >

Original command retained for compatibility so < S 5 20 1> is equivalent to < S 5 PIN 20 PULLUP >

Automatic polling of sensors should only be enabled when it is certain that JMRI (or similar) is operating the automation externally... RMFT will effectively switch this off.

[FrightRisk]

The output code interestingly has more options already. Those could be implemented into sensors. Since we are already using iFlags for outputs, why not use them for sensors? It is more complicated to explain I understand, but it is consistent:

IFLAG, bit 0: 0 = forward operation (ACTIVE=HIGH / INACTIVE=LOW) 1 = inverted operation (ACTIVE=LOW / INACTIVE=HIGH)

IFLAG, bit 1: 0 = state of pin restored on power-up to either ACTIVE or INACTIVE depending on state before power-down. 1 = state of pin set on power-up, or when first created, to either ACTIVE of INACTIVE depending on IFLAG, bit 2

IFLAG, bit 2: 0 = state of pin set to INACTIVE upon power-up or when first created 1 = state of pin set to ACTIVE upon power-up or when first created

This accounts for restoring the state of an output on power up. That is not necessary for sensors AFAIK. Technically the polling checks for a state change high to low or low to high (and a transistor feeding off the emitter or collector can invert that anyway) But it is true that the software would have to know which tranistion is the one you want. I love all the expanded capabilities!

[FrightRisk]

Chris, if you could take a look at how Rocrail supports outputs and sensors, that may be good to know. We probably don't want to break that. https://wiki.rocrail.net/doku.php?id=dccpp:dccpp-en

[Asbelos]

Wiki suggests rocrail only TEMPORARILY defines output and sensors inside Cs (so i presume it doesnt depend on eeprom) I have not suggested removing existing commands so there shoukd be no incompatibilities