Closed k4kfh closed 8 years ago
This is probably remedied (at least for most decoders) by having a custom raw JSON string sent. If you needed to shut off F3, F4, and F7, it could be something like this:
{"type":"throttle","data":{"throttle":"CSX754","F3":false, "F4": false, "F5":false}}
That should, in theory, be sent in one DCC packet instead of several in such rapid succession that the infrastructure can't keep up.
It might be time for a rewrite of the function handler, or the addition of a new one. If we had a JSON-centric function that could take in up to all 28 functions, but also could do one at a time, it would be much less counter-intuitive than the current method.
Upon further testing, commands need to be sent at different times, with short breaks in between. So despite the rewrite of the function handler mentioned above, which is done, there is still work to be done before this issue is solved.
When operating the air dump, the air appliances (such as the bell) do not shut off. This is unprototypical since the bell runs off the main reservoir, which would be dumped with the dump valve's opening. The issue here is one of implementation: JMRI seems to have trouble receiving multiple DCC function commands at once, so if the air dump function tries to shut off anything, in combination with the air dump noise it causes JMRI to lose one or both commands.
JMRI should be able to accept multiple function states in a single WebSockets packet, but this will require a redesign of the
jmri
object's system for sending WebSockets commands. Ideally, this would be backwards compatible with the old way.Another option is to simply have the air dump function send the raw JSON string instead of relying on a middleman function; this would be the simpler option but could become spaghetti code over time.