@DL7BJ / @sven-e I dont have the specs at hand but perhaps the mid-event can also tell something about directionality of the move?
eg
- event MID → on when servo goes to thrown and passes “mid move”
- event MID → off when servo goes to closed and passes “mid move”
I think i have seen that behavior above and might be useful for some use-cases?
( thinking of changing frog polarity based on events seen )
But that would probably need more logic than we have today.
Unless someone tells me otherwise: obscure use-case on a rarity.
Servo + frog polarity switch? ¯_(ツ)_/¯
@reinder
If you are thinking of adding sensors for turnouts:
Would it be an idea to gather [ create ] a table of all turnout sensors
and present that “sensor-name” as a pick list when you set up the turnout?
Lets say: create turnout-sensors for turnout East1 [ referencing earlier screenshot ]
Name:CANMIO-SVO101-East1 ( below referenced as $name to keep the table readable)
| EVENT ID | FCU name | FCU State | Traintastic state | inverted? |
|---|---|---|---|---|
| 25610 | $name->Thrown |  |
|
|
| 25611 | $name->Mid |  |
|
|
| 25612 | $name->Closed | |
|
|
| -------- | — | ---- | ---- | — |
Name:CANMIO-SVO101-East2
( below referenced as $name to keep the table readable)
| EVENT ID | FCU name | FCU State | Traintastic state | inverted? |
|---|---|---|---|---|
| 25610 | $name->Thrown | |
|
|
| 25611 | $name->Mid | |
|
|
| 25612 | $name->Closed | |
|
|
| -------- | — | ---- | ---- | — |
After that linking this as a “sensor-bundle” would be easy for normal turnouts:
grab the entire “bundle” by name ( resp. CANMIO-SVO101-East1 and CANMIO-SVO101-East2. ) and assign it’s representing turnout.
Deliberate choice: setup the logic first and consider that a complete configuration. Also allow to invert if need be in the GUI when setting up the sensors.
IrDA’s are kinda notorious in by book for needing it.
For the wye turnout it would be slightly trickier →
unless you can break that down again to 2 individual turnouts…
Which it ultimately is..
Double-slips could also be tricky no matter what solution you choose
Both wye and double slips are probably less common so..
Special treatment for these 2 and make the rest as easy pick-able as possible?
Bonus points:
Filtering
- not used [normal colors]
- used [ greyed out ]
- ID or Name
Sidenote:
Based on an Example from jmri setup:
JMRI used to have a grand overview of all (CBUS) nodes and items
[ servo / sensor / Train on track / IrDA end of track ]
On multiple occasions i found myself staring at that screen why bleeping thing was not working.
Ultimately my fault somewhere → 1 board flaky until it corrupted it’s firmware multiple times 
Not sure if you are interested or if it is feasible. But i can see a use-case where a filtered overview might be very handy.
And as long as things have nice pick-able/ readable names → happier days
( but perhaps split this discussion into sensors + new feature: reports ?)