v0.1.0 was a prototype with next to no error handling. This is essentially a rewrite taking some clues from mini-redis as to how to architect a tokio app. There is definitely more to do here to make it more resilient and recover from errors and gracefully shutdown tasks, but this is a huge improvement.
Breaking changes
topic structures changed (where you configure connections and where states are published)
Regrettably, this will change again, as I continue to think through the scenarios. Register descriptions will also change in the future.
CLI arguments have changed to accepting MQTT URL instead of individual components
Known issues
Re-defining an existing register will create two competing tasks. I need to create a kind of registry or have internal MQTT subscriptions have an ID, so the Sender for replaced subscriptions is dropped (currently, the new one is appended to a list).
Re-defining a TCP connection config seems to just break the TCP socket underneath and require a restart.
Occasionally, the TCP connection to a Modbus device gets an UnexpectedEof error ("unable to fill buffer" or something) and stops working. Gracefully recovering from this should be possible, but the underlying cause is an issue to be identified and hopefully fixed. My first thought was that I am select!ing on a Future which is not safe to be used in that way, but I can't spot how yet, if that's the reason at all.
Future
Setting holding registers by subscribing to modbus-mqtt/$connection/$register/set and un-parsing the value according to our parse rules.
Push the register input type ("input" or "holding") into the Register type and remove the input/holding level in topics and configuration. input should be the default if unspecified, as it'll be the most common for most usages.
Some kind of register value cache or intermediary between Register and modbus::Connection/modbus::Handle such that the values can be shown in other ways (a web interface, console output, etc)
Home Assistant sensor auto-discovery: essentially a homeassistant module which independently subscribes to some of the same topics so that it can re-publish to Home Assistant's homeassistant topic with the appropriate metadata so that Home Assistant can create sensors based on monitored Modbus registers.
v0.1.0 was a prototype with next to no error handling. This is essentially a rewrite taking some clues from
mini-redisas to how to architect a tokio app. There is definitely more to do here to make it more resilient and recover from errors and gracefully shutdown tasks, but this is a huge improvement.Breaking changes
Known issues
Senderfor replaced subscriptions is dropped (currently, the new one is appended to a list).UnexpectedEoferror ("unable to fill buffer" or something) and stops working. Gracefully recovering from this should be possible, but the underlying cause is an issue to be identified and hopefully fixed. My first thought was that I amselect!ing on a Future which is not safe to be used in that way, but I can't spot how yet, if that's the reason at all.Future
modbus-mqtt/$connection/$register/setand un-parsing the value according to our parse rules.Registertype and remove theinput/holdinglevel in topics and configuration.inputshould be the default if unspecified, as it'll be the most common for most usages.Registerandmodbus::Connection/modbus::Handlesuch that the values can be shown in other ways (a web interface, console output, etc)homeassistantmodule which independently subscribes to some of the same topics so that it can re-publish to Home Assistant'shomeassistanttopic with the appropriate metadata so that Home Assistant can create sensors based on monitored Modbus registers.