Skip to content

Outsource inbox/outbox #44

@AtosNicoS

Description

@AtosNicoS

Hi,
I really like the concept of Crouton. The describing of the GUI "cards" make a lot of sense to me. However the current layout (topic structure) implies the mqtt device was designed to be used with crouton.

Have you ever thought about decribing existing mqtt topic structures? I will give you an example. Lets asume you have the following mqtt topic structure in your home:

home/livingroom/door/lock -> "true"
home/livingroom/door/cmd <- "lock=true"
home/livingroom/music/title -> "Queen - Dont stop me now"
home/livingroom/music/next <- "anything"
home/livingroom/lights/ledstrip/red -> "255"
home/livingroom/lights/ledstrip/set <- "red=255"

You could then build a crouton interface around those existing topics:

"backDoorLock": {
  "labels":{ [optional]
    "true": "Locked",
    "false": "Unlocked"
  },
  "icons": { [optional]
    "true": "lock",
    "false": "lock"
  },
  "setter": {
    "topic": "home/livingroom/door/cmd",
     "payload_on": "lock=true",
    "payload_off": "lock=false"
  },
  "getter": {
    "topic": "home/livingroom/door/lock",
  }

  "card-type": "crouton-simple-toggle", [required]
  "title": "Employee Door" [optional]
}

This is just an example. A better structure with better names should be considered. Have you thought about this option? It would make the whole thing a bit more complex at describing the device, but can make the mqtt topics more flexible and simpler in its use. Especially if you have an existing mqtt topic structure.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions