¿ªÔÆÌåÓýWhat you describe is what I'd expect to see.?
With MQTT, the report will only change if the reporting hardware sends a new message indicating the section is empty.? That's a decision you need to take about your hardware (and how it interacts with software such as JMRI).? ?The hardware
I've built will report when it detects nothing, so a new MQTT report of "empty" is sent when the reporting hardware has nothing to report - there is a delay in sending the "empty" to deal with false-reads in the hardware, and to prevent a rapidly repeating
intermittent read of "locoA, nothing, locoA, nothing, locoA, nothing" - the delay of the return to "nothing" seemed the best option to avoid such repeated messages.? ?
(My main MQTT detection hardware is for RailCom, so is monitoring a length of rail, rather than a RFID spot reader).?? I'm not sure about your second paragraph, with the referenced reporters persisting.? That may just relate to the reports stored in the ID-Tags table, but I'm guessing a bit about that detail.? ? (And no time this week to setup a test
to look at it, day job calls first !).??
You may also have effects around the persistence of messages in the MQTT broker.? There's usually a setting in the broker software about what happens for older messages - particularly relevant if a client connects after the initial report
was made.? ? Its another factor to think about; there won't be a "right" answer, but only an appropriate setting for how you are using the information.??
- Nigel
------ Original Message ------
From "JerryG via groups.io" <jerryg2003@...>
Date 07/05/2023 16:19:48
Subject [jmriusers] Populating Reporters via MQTT messages (Was Re: JMRI / RFID / Ethernet) #rfid #MQTT
Nigel? (and any others knowledgeable about use of Reporters) -? |