Via the request on endpoint monitor/reversers, we should be able to get status information on the reversers. For this, the startup command must've been sent before, and there must exist at least one reverser on the track and in the config.
On our SWTbahn-Full, we only get the expected reply (containing the reverser status) iff a train is on the segments related to/wired to the reverser. If a train is somewhere else on the track, we get OCS_NOT_IMPLEMENTED (i.e. line 432) and the server logs Request: Get reversers - unable to request state update. In other words, the reversers_state_update call returns true.
From looking at the reversers_state_updateimplementation, the way that the return works does not reveal where exactly the error occurred. Either bidib_request_reverser_state returns the error, or all queries that succeed have the state value BIDIB_REV_EXEC_STATE_UNKNOWN.
My suspicion is that this is either due to libbidib, or the protocol working in a different way than expected.
eyip002
commented
1 year ago
Via the request on endpoint
monitor/reversers, we should be able to get status information on the reversers. For this, thestartupcommand must've been sent before, and there must exist at least one reverser on the track and in the config.On our SWTbahn-Full, we only get the expected reply (containing the reverser status) iff a train is on the segments related to/wired to the reverser. If a train is somewhere else on the track, we get OCS_NOT_IMPLEMENTED (i.e. line 432) and the server logs
Request: Get reversers - unable to request state update. In other words, thereversers_state_updatecall returns true.From looking at the
reversers_state_updateimplementation, the way that the return works does not reveal where exactly the error occurred. Either bidib_request_reverser_state returns the error, or all queries that succeed have the state valueBIDIB_REV_EXEC_STATE_UNKNOWN.My suspicion is that this is either due to libbidib, or the protocol working in a different way than expected.