toggle quoted messageShow quoted text
There has been a LOT of discussion in the MERG community regarding obtaining the known state of electrical switches, occupancy detectors and rail turnouts when the layout is first powered-up (as any of these could be changed manually whilst the power is off).
The usual approach is for a ‘Start of Day’ (SoD) event to occur - either by a timer or a push button - which the modules monitoring those devices reacts to, and sends the state of devices back to the ‘central’ point (usually a control panel, or JMRI), so that indicators can be correctly set, and not show ‘unknown’...
On 17 Jul 2020, at 18:05, Balazs Racz <balazs.racz@...
Unknown is a correctly supported state for JMRI Sensors, but if the user went to the length of configuring feedback with sensors, then having those sensors be in an Unknown state is arguably not very useful to the user.
For example turnout feedback or sensors in general might be watched by CTC logic. THat logic will not really know what to do if the sensors say unknown.
Therefore my suggestion would be to just read the state upon startup and not worry too much about the number of messages this takes. Make the reading as fast as possible. Through my interaction with large layout owners the feedback I've been getting is that they would like the state to be as consistent as possible between JMRI and reality. This is how they can ensure that the business logic functions correctly.
On Fri, Jul 17, 2020 at 6:23 PM emmanuel ALLAUD <eallaud@...
Thanks for your answers.
Just to precise things: the hardware I want to connect jmri to is
arduino based and has the ability to tell when the turnout is in
the requested position and also can be queried for the turnout
position if needed.
I will connect this through a jython script (the protocol I am
using is not known to jmri).
So if I dont send "events" to tell jmri about the turnouts
position or the sensors state, they will stay in "unknown" until
jmri gets a state for my hardware or, in the case of turnouts if
there is commanded state, right?
Any problem you can think of that this situation could create?
I have the solution to send all states on startup, it might
create a storm of events though for big layouts.
Le 17/07/20 à 11:38, Balazs Racz a
There is a hidden possibility to make JMRI request
the state of the sensor. You have to enable the state query
actions checkbox in the bottom of the sensor table. Then you
will have a button to press that will make JMRI trigger the
hardware specific implementation to request the state. (Internal
sensors don't have such an implementation of course as no
hardware is behind them.)
However, the expectation is that the sensor implementation
will automatically request the state once during startup, and
from then on when the sensor changes an incoming message from
the control bus will trigger the sensor to update its state
and JMRI's listeners. So generally a "sensor.query" is not
something that people run in a typical session ever -- this is
why the buttons are hidden by default.
> On 17-Jul-2020, at 05:10, emmanuel ALLAUD <eallaud@...> wrote:
> Hi all,
> a simple question: does jmri ever request the state of a
sensor? Same for turnout with feedback?
JMRI requests the state of a sensor if the connection protocol
(e.g. LocoNet, CMRI, OpenLCB…) allows it. The same is true for
Internal sensors do not request state, but typical these are
connected to buttons on panels or other scripted logic that
sets the state as appropriate.
> I have the impression that if there is a sensor set up in
jmri, it will be in "unknown state" until it gets the
information from whereever it is supposed to come from.
That is correct.