Parts of the home control system.

Real Devices

Zigbee2mqtt is the "provider" of real devices that exist on the zigbee network. These are basically inflexible.

Real devices fall into a few categories:

• controllable devices such as lights, fans
• buttons which only emit state (can't really be "read")
• status devices (sensors etc), which emit state but which may be read

The nodes involved are:

• path/to/device/get - writing to this node causes state to appear on naked node
• path/to/device/set - writing to this updates the device
• path/to/device - state is emitted here

Devices which can't be controlled ignore /set, devices which can't be read (buttons) ignore /get.

/get is a bit special/broken in zigbee2mqtt. It needs you to read a key that is reported by the main node (commonly but not always state), but all data is returned every time anyway.

Google Assistant Bridge

This tells Google about a bunch of IDs and what type of device plus traits they have.

• Tell Google what devices we have (SYNC)
• Need to semi-regularly tell Google the state of things (push)
• Need to respond to intents (e.g., turn light on)

This doesn't require any direct connection to devices. It doesn't even really care about zigbee/mqtt, but this is the point of a "bridge" at all.

Virtual Devices

Houses will have devices that are not provided by zigbee2mqtt. For ease-of-use, we can write virtual nodes which emulate the way zigbee2mqtt works.

These could run in-process but don't need to, they can run anywhere, even on different machines, as long as they play nice with mqtt.

Control Layer

Eventually, the point of these systems is to allow buttons etc to do interesting things.

This is similar to but disjoint to Google, which is really trying to be a bridge to devices.