Mobile RCP Rocmouse

Dagnall
Posts: 278
Joined: 15.05.2015, 14:41

Re: Mobile Rocmouse

Post by Dagnall » 22.12.2018, 14:14

Rob,
With respect, Its you who does not understand this problem, as you are explaining an issue I do not have.. or are possibly making incorrect assumptions about what my system has :wink: ..
Sorry therefore that this message has to be quite long to give more precise information. I know you prefer short questions, but here we need a long text to make sure we get the answer to the (real) question. I have tried to use smilies to emphasize the key points...

:!: I do not physically have a Rocnet PI04 throttle. :!: (perhaps the forum topic name could have been better?)
I DO have a mobile throttle of my own design, connected and subscribed to Rocview via the service MQTT, listening (and able to send) to both service/client and service/Info topics.
  • My throttle currently has these (FULLY WORKING !) abilities:
    • It can send the "lcprops" message to Rocrail
    • From watching the response to the lcprops message, it can get lots of information about the locos, their names, functions etc. and build an internal loco list
    • I can select ANY loco from this throttle internal loco list and send Speed or Fn commands to any selected loco.
    • Rocrail accepts these commands and sends them to the appropriate CS to control the loco
    • The Loco moves and the sounds sound
    • :!: At the moment, my code DOES work with "dispatch loco", BUT ONLY by sensing an "<exception text" message including "dispatch"
    • If I have seen the dispatch message, the throttle then acts as a single loco throttle, and when I release the loco in rocview/rocrail, my throttle sees the <lc id="E03" cmd="release ..>" message and then waits for a lcprops reponse to build a new internal loco list, or wait for a new "dispatch" command
:!: I am trying to make it "more" compatible with Rocview by adding the ability to work "properly" with the "dispatch loco" capability.
  • :!: Jan and I have discovered that Rocrail (/Rocview?) can send the "<exception text" message for "dispatch" in at least two different formats: (::roll:) , so we would like to have a solution that works "properly"
  • :!: I think/understand that to get Rocrail to send the <lc id="E03" cmd="dispatch" ..> message we FIRST need to tell Rocrail that we HAVE a throttle available
From the previous forum answers, I have deduced that :
  • Rocrail/rocview will only accept "dispatch for throttle" (AND SEND THE "CORRECT" <lc id="E03" cmd="dispatch" ...> MESSAGE) if Rocrail knows that a throttle IS available.
  • BUT IF THERE is NO Throttle available, then rocrail sends the exception text. (I hope I have this correct) :?:
  • A throttle is NOT a command station, there may well be throttles connected to command stations, but you can easily have throttles as part of other hardware. For example, Rocview includes throttles..
This leads to the "real" questions:
  • :?: If you have a (or ANY) throttle that is only connected to Rocrail by a MQTT service interface, how do you expect Rocrail to know that the throttle exists ?
  • :?: WHAT message should a MQTT service connected throttle send to Rocrail to inform rocrail that it exists so that RR does not need to treat the rocview dispatch command as an exception -- It may be that you need to add this command to rocrail?? :?: -- This is not a "cs library" issue, as the throttle is not a cs! --
  • :?: Lastly.. WHY does rocrail NEED to know throttles exist?.. what can you do if it does not exist??
  • Finally: :?: Could you just send the <lc id="E03" cmd="dispatch" ...> over service/info MQTT whenever Rocview sends the dispatch :?:
Thanks for reading this far.
Dagnall!

rjversluis
Site Admin
Posts: 41680
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Re: Mobile Rocmouse

Post by rjversluis » 22.12.2018, 14:30

Rocmouse is using the RCP:
https://wiki.rocrail.net/doku.php?id=ro ... ripting-en

To catch commands send from other clients like Rocview, and the mouse is connected to the MQTT service of the server
https://wiki.rocrail.net/doku.php?id=ro ... tt_service
(the mouse sends its command to the client topic)
, the mouse must subscribe to the MQTT client topic. It would probably also sees its own commands.

<exception/> messages are TRACES which CANNOT/SHOULDNOT be used for catching commands from other client; Ignore them. (::roll:)

If the mouse is connected by TCP/IP you will have no chance to catch a command from another client.

As I already proposed: I can let the loco object broadcast its commanded dispatch, but this is the wrong way. (::roll:)
YOur mouse is acting like a client and does not need a dispatch command; Those commands are for low level throttles like FREDi & Co.

rjversluis
Site Admin
Posts: 41680
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Re: Mobile Rocmouse

Post by rjversluis » 22.12.2018, 14:44

andRoc is also a RCP client, and also does not need a dispatch.
This would be ridicules because an RCP client knows everything.
A hardware throttle is stupid and needs a dispatch.

Your Rocmouse seems to be a client; Then it should behave like one, and not trying to intimidate a stupid hardware throttle.

Dagnall
Posts: 278
Joined: 15.05.2015, 14:41

Re: Mobile RCP Rocmouse

Post by Dagnall » 24.12.2018, 12:47

Rob, Thanks for persevering with this thread (and I see you have changed the Title?) :
For anyone else following it, I would like to just add a few comments to bring this thread up to date:
The project actually started as a combined Rocnet/RCP Mobile tool to help adjust the turnout positions on my Rocnet based remote garden railway servo operated points because I got frustrated with having to take a full wifi laptop physically to the points to adjust their left and right positions. The tool I built was "SwitchTool" (https://github.com/dagnall53/SwitchTool), and it is a very very crude Rocrail RCP client &Rocnet Node that reads Switch characteristics via Rocrail RCP SWlist commands and then changes the Pi03 settings for the discovered servo positions via Rocnet protocol over MQTT. The code for this is constructed "badly" and probably illogically, but does work.

The hardware platform I used for this was interesting and cheap, so from this beginning I thought it would be nice to emulate a simple dumb throttle like the Pi04, but with a MQTT connection and using pure Rocnet commands. However, decoding the Rocnet PI04 command structure and sequence of commands proved very difficult. So I ended up making a Client based RCP protocol, MQTT connected device that picks up the loco list from Rocrail, and allows one to select any loco and then control it. This is a bit like andRoc, but without the nice graphics!!. Its only advantage is that it is a dedicated controller and the hardware, with 18650 battery and charger and 0.96"OLed only costs about 12 euro.

This was fine, and "RocClientThrottle" code worked OK for me, but I thought I would try and improve it by making it respond to the "release for throttle" command in Rocview, :oops: and this is where a lot of problems started :roll: . I now accept that this "release for throttle" command is only for "dumb" throttles, and it is not really needed for the Client throttles like mine. So I am currently re-writing my code to avoid using exception messages, and to pick up the loco function names to improve display when using functions. I will update the software on Github to V006 as soon as I have this working.

Lastly, thanks to Rob. I really appreciate when you take the time to write the longer comments that allow me to fully understand all the complexities of the issues. ... and I could not resist this commenting on this:: :wink: ...
and not trying to intimidate a stupid hardware throttle.
.. Well I might have originally been trying to imitate some dumb hardware, but I had not appreciated that you felt that I was bullying your system! :wink:
Happy Christmas...

drblack
Posts: 81
Joined: 10.05.2008, 13:02
Location: Quickborn, S-H

Re: Mobile RCP Rocmouse

Post by drblack » 18.01.2019, 22:04

Hi Dagnall,

I just found your finalised version of RocClientThrottle. Very well done!
It works smoothly in my test environment.

Thanks for such a nice add on.

Post Reply

Return to “DIY Hardware”