{"action":"created","issue":{"url":"https://api.github.com/repos/JMRI/JMRI/issues/5143","repository_url":"https://api.github.com/repos/JMRI/JMRI","labels_url":"https://api.github.com/repos/JMRI/JMRI/issues/5143/labels{/name}","comments_url":"https://api.github.com/repos/JMRI/JMRI/issues/5143/comments","events_url":"https://api.github.com/repos/JMRI/JMRI/issues/5143/events","html_url":"https://github.com/JMRI/JMRI/issues/5143","id":308260252,"number":5143,"title":"Loconet Stationary Interrogate - Turnout Sensor Report (Feedback) handling issue","user":{"login":"n3ix","id":14222051,"avatar_url":"https://avatars0.githubusercontent.com/u/14222051?v=4","gravatar_id":"","url":"https://api.github.com/users/n3ix","html_url":"https://github.com/n3ix","followers_url":"https://api.github.com/users/n3ix/followers","following_url":"https://api.github.com/users/n3ix/following{/other_user}","gists_url":"https://api.github.com/users/n3ix/gists{/gist_id}","starred_url":"https://api.github.com/users/n3ix/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/n3ix/subscriptions","organizations_url":"https://api.github.com/users/n3ix/orgs","repos_url":"https://api.github.com/users/n3ix/repos","events_url":"https://api.github.com/users/n3ix/events{/privacy}","received_events_url":"https://api.github.com/users/n3ix/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":31,"created_at":"2018-03-24T12:55:39Z","updated_at":"2018-03-26T21:35:58Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Problem Overview - When JMRI receives a Loconet INPUT LEVELS Turnout Sensor Report for a turnout not yet in the Turnout Table it creates the Turnout but leaves the State set to UNKNOWN, ignoring the feedback information in the Turnout Sensor Report.\r\n\r\nBackground\r\nWhen JMRI starts it performs the Stationary Interrogate sequence on Loconet connections.  The Interrogate sequence is also performed by Digitrax Command Stations whenever track power is turned On.  Loconet Stationary decoders respond to the Interrogate messages with Turnout Sensor Reports (Feedback) for each physical turnout.  There are 2 forms of the Turnout Sensor Report message that the decoder could use - OUTPUT LEVELS and INPUT LEVELS.  The results in JMRI are different depending on which form of the Turnout Sensor Report it receives.  Consider the follow cases:\r\n\r\n1.  Panel file not yet loaded and the Turnout is not yet in the turnout table.  JMRI receives a Output Levels Turnout Sensor Report.\r\nResult:  The Turnout is created, the feedback mode is set to MONITORING, and the State is CORRECTLY set per the data in the Output Levels Turnout Sensor Report.\r\n\r\n2.  Panel file not yet loaded and the Turnout is not yet in the turnout table.  JMRI receives an Input Levels Turnout Sensor Report.\r\nResult:  The Turnout is created, the feedback mode is set to MONITORING, and the State is set to UNKNOWN.\r\n\r\n3.  The Turnout is already in the turnout table with feedback mode set to MONITORING.  JMRI receives a Output Levels Turnout Sensor Report.\r\nResult:  The Turnout State is CORRECTLY set per the data in the Output Levels Turnout Sensor Report.\r\n\r\n4.  The Turnout is already in the turnout table with feedback mode set to MONITORING.  JMRI receives an Input Levels Turnout Sensor Report.\r\nResult:  The Turnout State is NOT CHANGED.\r\n\r\n5.  Panel file has been loaded and the Turnout is already in the turnout table with feedback mode set to EXACT.  JMRI receives a Output Levels Turnout Sensor Report.\r\nResult:  The Turnout State is NOT CHANGED.\r\n\r\n6.  Panel file has been loaded and the Turnout is already in the turnout table with feedback mode set to EXACT.  JMRI receives an Input Levels Turnout Sensor Report.\r\nResult:  The Turnout State is CORRECTLY set per the data in the Input Levels Turnout Sensor Report.\r\n\r\n\r\nSuppose a user has configured their physical Loconet Stationary Decoder to provide EXACT (INPUT LEVEL) feedback.  \r\n\r\nA) If the Decoder responds with an INPUT LEVEL feedback message during Interrogation, JMRI will not use the feedback to set the State in case (2) above.   \r\n\r\nB) If the Decoder responds with an OUTPUT LEVEL feedback message during Interrogation, JMRI will not use the feedback to set the state in case (5) above.\r\n\r\nSo how to ensure that JMRI properly initializes the Turnout state during Interrogation when the physical stationary decoder is configured to provide EXACT feedback?  To handle this scenario I took the approach in the QuadLN decoders of sending both the OUTPUT LEVEL and INPUT LEVEL forms of the feedback message during Interrogation.  This covers both case (1) and case (6) above and JMRI always initializes the Turnout state correctly.  \r\n\r\nThe downside of this solution is that Interrogation results in two feedback messages per turnout instead of one.  In almost all cases this has not been a problem.  However on very large club layouts the high number of responses to Interrogation can already be problematic due to collisions.  In this environment doubling the number of feedback messages just makes things worse and increases the chances that some Turnouts will end up in the UNKNOWN state.  Since UNKNOWN Turnouts cause problems in layout operation, other measures are then required to resolve all the UNKNOWN Turnouts (and to resolve all the UNKNOWN Sensors, since excess collisions can also result in missed Sensor feedback messages during Interrogation).\r\n\r\nWhat I'd like to propose is a change in the way JMRI handles case (2).  When the Turnout does not yet exist in the Turnout Table and JMRI sees an INPUT LEVELS feedback message, can JMRI initialize the Turnout State per the feedback message?  If so, the decoder could just send the EXACT feedback message during Interrogation. \r\n\r\nThanks for your consideration.\r\n\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/JMRI/JMRI/issues/comments/376319894","html_url":"https://github.com/JMRI/JMRI/issues/5143#issuecomment-376319894","issue_url":"https://api.github.com/repos/JMRI/JMRI/issues/5143","id":376319894,"user":{"login":"devel-bobm","id":13856693,"avatar_url":"https://avatars0.githubusercontent.com/u/13856693?v=4","gravatar_id":"","url":"https://api.github.com/users/devel-bobm","html_url":"https://github.com/devel-bobm","followers_url":"https://api.github.com/users/devel-bobm/followers","following_url":"https://api.github.com/users/devel-bobm/following{/other_user}","gists_url":"https://api.github.com/users/devel-bobm/gists{/gist_id}","starred_url":"https://api.github.com/users/devel-bobm/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/devel-bobm/subscriptions","organizations_url":"https://api.github.com/users/devel-bobm/orgs","repos_url":"https://api.github.com/users/devel-bobm/repos","events_url":"https://api.github.com/users/devel-bobm/events{/privacy}","received_events_url":"https://api.github.com/users/devel-bobm/received_events","type":"User","site_admin":false},"created_at":"2018-03-26T21:35:58Z","updated_at":"2018-03-26T21:35:58Z","author_association":"CONTRIBUTOR","body":"@bobjacobsen,\r\n>_Except_ for the case of mis-configured hardware, is there any reason to believe that this is not a good thing to just do?\r\n\r\n_That is exactly the problem_ - hardware IS mis-configured (well, un-configured, really) in the original use-case presented in this issue. From the initial post (bolding added):\r\n\r\n>**Panel file not yet loaded** and the Turnout is not yet in the turnout table. JMRI receives an Input Levels Turnout Sensor Report.\r\nResult: The Turnout is created, the feedback mode is set to MONITORING, and the State is set to UNKNOWN.\r\n\r\nPerhaps I've missed something somewhere along the lines, but I think that the issues I present below add up to plenty of reason that this \"simple\" solution is not \"the right thing to do\".\r\n\r\nSpecifics:\r\nPer @n3ix, in the troublesome cases, the .XML hasn't been loaded (or is not completely loaded) at the time that the LocoNet message is seen that causes `Turnout` creation.  Because of this, the `Turnout` object is created with a default (wrong) feedback type.  In my analysis, this is one of the root causes of the problem!\r\n\r\nI'm trying to avoid changes to the logic of how we treat `Turnout` objects when <OPC_SW_REP> is received.  I see that as risky, at best, as it is difficult to predict the effect on other JMRI users.\r\n\r\nIf we go ahead with logic changes, then the changes I see would require being able to tell that the object was just created, and be able to _infer_ the correct feedback type, solely from a single LocoNet message.  There are feedback modes which can be uniquely inferred from some interrogate reply messages.  But there are also interrogate reply messages which can be used by either of two \"feedback\" modes, so it is impossible to guess which one applies.  The \"guessing game\" is as likely to be wrong as right.  What difficulties will this cause?\r\n\r\nThe logic changes are also entangled with the `knownState` versus `commandedState` problem.  Since the `knownState` and `commandedState` values are set at the event occurence (in this case the reception of a LocoNet message), and are \"feedback-mode-dependant\",  if you have guessed \"feedback\" mode incorrectly, you are stuck with the \"bad\" state data until you have changed the \"feedback\" mode (i.e. XML evaluation finally gets to the turnout) and the a subsequent event occurs which causes re-evaluation. \r\n\r\nA secondary problem, also reported by @n3ix, is that when Logix and Signalling and SSL are loaded while the \"interrogation\" process is ongoing, internal state is constantly changing, and this \"floods\" LocoNet with messages to drive signal aspects based on those ever-changing intermediate states, which have to compete with the \"interrogate\" reply messages, which means some get lost due to excessive retries, which means unknown sensor and turnout states which means incomplete states for signal logic, which gives misleading and/or meaningless signal aspects, ...\r\n\r\nI'd really like to avoid all of this complexity!  \r\n"}}
{"actor":{"display_login":"devel-bobm"}}