Web Server Some more ideas
#21
Posted 31 October 2022 - 07:59 AM
#22
Posted 31 October 2022 - 08:07 AM
#23
Posted 31 October 2022 - 09:01 AM
The idea is to control cabview controls with external hardware, not just limiting to RailDriver (say potentiometers, buttons, etc.)
#24
Posted 31 October 2022 - 09:15 AM
Custom-built, or factory-serial?
#25
Posted 31 October 2022 - 09:41 AM
https://kephost.net/p/2022/44/4337_f4dccf21987d.jpg
Version for raildriver. Made from disassembled V43 parts. It was originally created for the EU 07 Maszyna program, but can now also be used for OR.
Since then, the owner has also used 3D printing for the TAURUS locomotive.
Sincerely, Laci 1959
#26
Posted 01 November 2022 - 02:45 AM
Weter, on 31 October 2022 - 08:07 AM, said:
Yes something like that only in my case, visitors would use the drive-stand and me, with a side control on my smartphone, to play some tricks on them :rotfl:
#27
Posted 07 November 2022 - 12:15 PM
cesarbl, on 31 October 2022 - 05:17 AM, said:
Any ideas or suggestions?
This is going to be a significant extra functionality for Open Rails. Very happy to see it going ahead.
I am hoping that we can re-factor the code just a bit and pull some common code out of CabViewDiscreteRenderer.HandleUserInput() which can then be called by both the new API and HandleUserInput().
I'm hoping to take a look and see what's possible. Send me a PR if you want to discuss this in detail.
#28
Posted 07 November 2022 - 12:44 PM
I'm waiting before uploading the changes because I'm basing them on the cruise control branch, as CC creates a variety of new controls that would otherwise conflict with my changes.
Quote
Yes, my idea was to reuse it as much as possible to avoid duplications. Almost all the controls work with the HandleUserInput(), except precisely some of the cruise control levers. I also reused parts of the RailDriver code.
Another thing that might need discussion is the protocol. I'm currently using HTTP POST requests, and sending data in JSON format, which is not really fast. From my tests speed seems OK, but somewhere in the forum it was suggested to use WebSockets instead. Maybe both protocols can be implemented in the future, but I think that if speed is an issue then serializing and deserializing JSON every 50ms is not the best idea, so for WebSockets another protocol would be needed. I think we can stick to HTTP POST at the moment, which can be easily implemented using Python scripts.
#29
Posted 19 November 2022 - 09:29 AM
cesarbl, on 07 November 2022 - 12:44 PM, said:
I'm starting to look at this now. I've no objection to using WebSockets if speed becomes an issue, but I'm using HTTP POST and JSON for now, as you are.
#30
Posted 19 November 2022 - 10:23 AM