Fairly major update. The code that parses the byte stream from the LCS Ser2 is paying off in spades. I've could echo received commands for a couple of weeks now. This means that no matter how the TMCC command was generated, via a Cab2, the Cab 3, another third-party vendor, or my Python code, I can capture it via the output stream from the LCS Ser2 and echo it to a console.
One of the issues with building control panels is keeping system state in sync. For example, if I have a light on a control panel that reflects if a power district is on or off, I want that light to reflect the correct state no matter how that state is changed. So, if a power district is on, and the corresponding led is lit, it should turn off if:
- I manually turn off the district via a cab2
- I manually turn off the district via a cab3
- It is turned off via a 3rd party app
- A TMCC Halt command is issued
For this to work correctly, you need:
- A way to maintain state on the PyTrain server
- A way to keep that state in sync on all PyTrain clients (the ones powering the panels)
- An understanding of the dependencies that exist between Lionel commands
This last item is particularly interesting. It's obvious that a power district led should turn off if it sees a "turn power district off" command (Accessory Aux2, in my case), but what about that Halt command? And when you do an engine reset, (the (R) button on the Cab2/Cab3) it sets the engine speed to zero, resets direction to forward, turns the bell off, sets RPM to zero, sets engine labor to 12, and performs an immediate startup, and I may still be missing some; phew!).
With this morning's checkin, the following is available:
- A state management system has been implemented that observes the command stream from the LCS SER2 and determines device states from it,
- Commands received on the server (the one with the LCS Ser2 connection) are now propagated to all clients; they in turn, using the same code, keep their own local state caches in sync,
- I've implemented a command listener system that listens for specific commands (scoped to device type, specific device, device command, and device command data) that calls callback methods in response, and
- I've started developing a dependency mechanism that understands the relationship between commands (e.g., Halt command should disable power districts)
Devices are engines, trains, switches, and accessories. There is still a lot more work to be done, but with these components, the system is now aware of events happening elsewhere on the layout and from other control mechanisms, and can maintain device state accordingly.
My next step is to wire these dependency-aware event listeners into the code to control LEDS so their state always reflects reality.
I am hoping that one day soon I will learn how to query LCS devices via wifi, but for now, you can do a lot with an LCS Ser2.
-- Dave
