Smart Switchboard

DESIGN

  • Network communication should be very light weight. In Json, keep string lengths to minimum and use numbers where ever possible.
  • While the client and esp are in local network, Communication flow will be like this: client -> esp -> cloud. Where as while client is on internet, client -> cloud -> chip
  • All the switch-appliance mapping will be maintained in esp. Why??

    • Multiple clients(mobile) should be in sync with this mapping. If one client changes the mapping, other clients should be notified. Maintaining this mapping in esp will help sending the notification to all the clients (through local network or through cloud)

    • No need to maintain the mapping info in every client. Info will be in one centralized location which is esp. All the clients can request this info instead of reimplementing this.

  • All the switch-state mapping should be maintained inside esp. Whyy??

    • Because state is an attribute of switch/appliance, not clients.

    • Client should first send request to switch board. Only when the request is successful, client will get ack-success and update the UI.

    • When a client send a req to change the state of an appliance, all the clients should be notified. This notification will be sent by the esp on successful change of the state (to cloud as well as local devices).

  • Direct point to point communication while in local network. And mqtt communication through cloud. Read the analysis below.

    • MQTT QOS will help atleast once notification to all the clients on the internet. You don't need to implement anything specifically for this purpose.

    • Easy to publish notifications from/to all the internet connected devices.

communication design