Updating Application State from IO Devices
Specifically with information from the moisture level of soil from the HW-390 sensor
Information flows from place to place in a complex system
Application state, digital twin, and state machine, all represent the same sort of concept where you are creating a logical representation of what is happening in reality, inside the memory of a computing system.
The state of the soil monitoring system will actually be very simple because we are going to assume that this system is only going to be responsible for monitoring a single sensor. Let’s see see that code.
You can see that there are five properties of the enum that can be assigned to the state, and that the state has only one property, and that is for holding that output.
Why do this?
I could (and likely should) add the raw value of the sensor to the state as well for debugging purposes. I would be nice to know at any given time what that value is, as well as what the function that is generating the nicely named state name thinks it is.
But the real reason is because it’s quite difficult to commit to memory the behaviors and quirks of every individual piece of hardware on the planet. Conversely, it’s much easier to read the members and properties of an object and be able to derive a story from that.
Let’s compare:
Pure Technical
Meant for Humans
If I am inheriting a project I’d rather see #2 by leaps and bounds. Tell me what’s going on, please. I like the technical side some as it’s nice to know something about the sensors. However those can change over time, but the concept of dryness is not likely to change. That might break the universe.
But wait… Dryness?
yeah, it turns out the sensor I’m using (and likely other sensors of this type) have a value that increases when the moisture level in the soil decreases.
So I would actually say that this sensor is measuring the dryness of the soil in this case because the number seems to have a magnitude relationship that correlates with the concept of dryness. It’s probably indicating ‘resistance’ or some other lack of conductivity. Either way, if the number goes up when the soil is drier? That’s a Dryness sensor.
Conclusion
The biggest reason for implementing a state machine in an application is to manage complexity, and try to reflect reality as accurately as possible in a single location. The second best reason is to reduce the bar to entry on being able to understand what the system is doing. Naming properties and child properties accordingly can tell a develop a huge amount about what’s going on within a system, and is certainly worth the effort. Not to mention testability!
Recounting all the reasons here might be a deft effort so I’ll stop here, but I’ll definitely re-iterate, Be sure to understand how to build a clean system state!
