Space state via MQTT

[renzenicolai]

Some dutch hackerspaces (Revspace, TkkrLab, Bitlair) have started providing their spacestate over MQTT, in addition to the spacestate in the spaceapi json file. The added value is that MQTT is push based instead of polling.

We've added the details of our MQTT spacestate service to the state object in the spaceapi json file as follows:

  "state": {
...
    "mqtt": {
      "host": "mqtt.tkkrlab.nl",
      "port": 1883,
      "tls": false,
      "topic": "tkkrlab/spacestate",
      "open": "1",
      "closed": "0"
    },
...
  }

The "mqtt" optional object contains the following required properties:

• "host": the hostname or IP address of the MQTT server (string)
• "port": the TCP port of the MQTT server (number)
• "tls": weither or not the MQTT server uses TLS encryption (boolean)
• "topic": the topic to subscribe to (string)
• "open": the message value published when the space is open (string)
• "closed": the message value published when the space is closed (string)

It would be extremely awesome if this addition could be added to the SpaceAPI json schema as an optional extra method for publishing the space state.

[dbrgn]

Is this space state standardized in some form? This "open=1" and "closed=0" seems a bit awkward, and a bit inflexible. What if additional details are published along with the state, e.g. people present?

[clonejo]

What about allowing to push a SpaceAPI-conforming JSON object at an arbitrary MQTT topic, and then referencing that? In my mind there would be no obligation to provide all fields provided via HTTP also via MQTT though. Eg. just providing the open/closed state via MQTT and more fields via HTTP is fine.

upside: simpler specification, while keeping a lot of flexibility downside 1: clients need to parse JSON downside 2: The MQTT topic gets an update for any change of the fields contained in the JSON; making the implementation of simple clients harder.

Regardless of that proposal, as long as MQTT and HTTP provide the same data, there is an open question about precedence. Does MQTT take precedence over HTTP? Or vice-versa? Are clients supposed to poll regularly, in case the MQTT data becomes stale? Imagine MQTT and HTTP being fed by different processes or threads, the MQTT messages being send with the retain bit set and the MQTT one crashed without being restarted. Clients would need to handle the retain bit on incoming messages correctly to discard old data.

Maybe i'm just overthinking this though :)

[rnestler]

downside 1: clients need to parse JSON

Well the clients need to parse the original SpaceAPI JSON anyways to get the MQTT endpoint.

So I think it makes stuff easier if the MQTT endpoint provides the same / similar data than the SpaceAPI JSON. Maybe allow to query individual sensors / fields in the MQTT topic?

tkkrlab/spaceapi                            -> the whole spaceapi json
tkkrlab/spaceapi/state                      -> just the `state` object
tkkrlab/spaceapi/sensors/people_now_present -> just these sensors
...

[renzenicolai]

Is this space state standardized in some form? This "open=1" and "closed=0" seems a bit awkward, and a bit inflexible. What if additional details are published along with the state, e.g. people present?

No, spaces are free to choose the value they publish. This is what the "open" and "closed" fields are for: they tell you what value to expect per space state.

What about allowing to push a SpaceAPI-conforming JSON object at an arbitrary MQTT topic, and then referencing that? In my mind there would be no obligation to provide all fields provided via HTTP also via MQTT though. Eg. just providing the open/closed state via MQTT and more fields via HTTP is fine. ... Maybe i'm just overthinking this though :)

The whole idea is that you send an easily parsible value to a topic, not big JSON objects :smile:

So I think it makes stuff easier if the MQTT endpoint provides the same / similar data than the SpaceAPI JSON. Maybe allow to query individual sensors / fields in the MQTT topic?

For other sensors it might be a fun idea to add an MQTT topic field to each sensor so that the value can also be queried over MQTT for each of the sensors in the spaceapi.

For the spacestate however I'd like it more if the topic and values were to be specified together with the spacestate section of the spaceapi document.

[Juerd]

Here's a +1 for the MQTT feature as proposed by @renzenicolai, and -1 for getting JSON into MQTT.

At RevSpace we already implement this MQTT spec, and we've had our space state available in MQTT since 2014 in exactly the same form. In our case, we don't use "0" and "1", but "closed" and "open", and I like that this spec is flexible enough. Changing that to JSON would be annoying, as would adding additional topics with JSON. As an old-time MQTT user, we publish a single value per topic, not JSON objects. Both options have advantages and disadvantages, but for a state indicator, the simple raw value seems to make more sense.

We're using "mqtt":{"topic":"revspace/state","closed":"closed","port":1883,"open":"open","tls":false,"host":"revspace.nl"}

Hackalot is another Dutch hackerspaces that already have their space state available over MQTT as simple string values on a static topic. Brings the total number of spaces that could use this to at least 4 :)