State

Data is represented in MudPi as state. State can be anything like a string, integer or even an object. MudPi provides a state_manager to manage all the state for the system in a thread safe manner. Typically components are the main items that store state but technically anything can interact with the state.

Here is an example of state for a moisture sensor reading:

{   
"component_id": "moisture_sensor_1",
"state": 88,
"updated_at": "2021-03-14 09:34:33",
"metadata": {
    "unit": "%"
}}

State Changes

The state manager will check if the state being set is different from previous state. If the manager detects change it will store the new state and emit an event. The best way to interact with new state is listening to this StateUpdated event. While you can manually set state it will likely not be detected if you don't use the set() method on the manager.

Metadata

MudPi mainly cares about the actual state value. However in many supporting resources like the dashboard it can be useful to have more information on the state. This is where metadata is useful. Metadata is an additional dict of data that is stored with the state to help describe the state in more detail. For example some useful metadata that may be included is a unit of measurement, an icon and maybe a short description.

Fetching State

There are a few ways to get state from the system. The first and most direct method is to use the state manager on the MudPi core instance. The state manager has a get() method that takes a component id (key) and will return any state found. An example of getting state for a component with an id of example_1 would look like the following: mudpi.states.get('example_1')

Another method of getting state is to listen on the state topic of the event system for state events. The state event will contain the state and component id. You can provide a listener to respond to these events and gather state for components you are interested in. This is a more indirect way of dealing with state but still another option to consider.

The last way to get state is to pull from the backups kept in Redis. MudPi manages the state internally but will keep a copy of the state in Redis. This is done as a backup in the event the system crashes so that previous states can be restored to components. In order to get state from the redis backups you need to query redis with a GET command for the component state you are after. The state is stored under a key with the format {component_id}.state. So in the example of a component with a key of example_1 the key would be example_1.state. If you are curious about all the components that have state backups a key of state_keys is stored in redis with a list of the component ids (keys).

Here is an example of using redis in python to get the state for our example component:

import redis
r = redis.Redis(host='127.0.0.1', port=6379)
state = r.get('example_1.state')

Remember that state in redis must be stored as a string so all data gets json encoded before its stored. When you pull state from redis manually you will need to json.decode() it. If you access state from the state manager this is done for you already.