I’ve been developing the farmbot-py client that connects through MQTT. It works pretty well, but the one thing that is holding back a solid implementation is a good way to get at “live” data, and specifically the status of the mounted tool.
Currently there are two ways to get status information through MQTT: through the status tree in the status channel, and through the log messages in the logs channel. The problem is that the status channel is mostly sending configuration information - which hardly changes and is very uninteresting to send over and over - and that the logs channel is for logging, not an official interface. Therefore I propose the following:
Make a distinction between configuration data and “live” data, and send each through their own channel.
Define “live” data to send, which consists of:
- x, y, z location,
- a way to determine if x,y,z is unknown, mostly due to a reboot, and a homing is needed,
- status of sensors,
- status of readable pins,
- overall readiness status (live, e-stop, etc)
- ID of mounted tool or no tool mounted
Define configuration data to send, which is most of the current data in the current status tree
Split off jittery data, notably the wifi strength and raw encoder values, since these two make diffing two statuses guaranteed to produce a difference.
Create a new “/live” (or whatever name is deemed appropriate) channel to send the dataset of 3) through.
Decide on a timing for the live data to send. My preference is using a correlation ID that corresponds to a “please send me a new set of live data” request in the from-clients channel. (I know that that correlation ID would already be used in the rpc_ok message, but this is another channel so will correlate nicely)
Gradually deprecate sending “live” data through other channels