Just wanted to say thank to Danny for his work in the background moving my request forward... I never expected such interest, very excited to see things move to a version that my custom hardware can transmit temperature readings to

Cheers - Robert...

I posted some ideas about the JSON structure here: https://github.com/rswift/wifi-temperature-broadcast/wiki/JSON-Payload-Format

Hope it is useful

Robert.

I've been thinking more about how to link up DIY kit via the Data Logger feature. The broadcast app I've written uses JSON, but equally could have used XML. I think a text based format makes sense over binary, there isn't much data so little/no need to compress the data itself.

The format I've used is:

{
  "celsius":" 123.45,
  "fahrenheit": 254.21,
  "probeName": "Gené Cafe Bean Mass"
}

and I have an optional "debugData" (broadcast rate, some internal data etc.) if debugging is enabled within the broadcasting app:
{
  "celsius":" 234.56,
  "fahrenheit": 454.21,
  "probeName": "Gené Cafe Bean Mass",
  "debugData": {
    "key": "value", ...
  }
}

So, I'm thinking that within the probe setup, a "DIY" probe could be added, a push/pull data collection (in my current code it'd be a push from the probe, but I've already started to think about a pull whereby the probe broadcasts details of itself including properties such as "serverPort" so a client can then make a basic HTTP GET request to pull the data on demand).

I can see from the data logger feature you have the concept of ports, so mapping the DIY probe could be via a given UDP broadcast port number, or preferably a unique identifier such as the probe name (two reasons, firstly I may have multiple probes from one ESP8266 broadcast unit, and secondly there will probably only be a few probes at most, and logical naming makes a great deal of sense).

Then all it'd need would be a simple mapping of metrics that Roastmaster needs to fields in the text based payload, so "celsius" to a °C curve for example.

BTW: I've splashed out the £10.99 to buy the data logging feature to see what it provides, even though it is useless to me at the moment, so I do hope all this comes to fruition

Logically this could be taken a step further too, things like fan speed, voltage, even ambient temperature could be logged.

It'd make sense to structure the payload to permit multiple probes, so maybe more like:

{
  "readings": [
    {
      "probeName": "Gené Cafe Bean Mass",
      "reading": 234.56,
      "scale": "C"
    },
    {
      "probeName": "Gené Cafe Air Inlet",
      "reading": 234.56,
      "scale": "C"
    }
  ],

  "systemInformation": {
    "someKey": "someValue",
    "aDifferentKey": someNumericValue
  },

  "debugData": {
    "debugKey": "debugValue", ...
  }
}

Cheers - Robert...

I should have added, there is always Bonjour/Zeroconf too - basically any means of the app running on iOS to find the host server. The API would then be implemented there, so Roastmaster would HTTP GET the value and expect a response in an appropriate format.

Just a thought.

Robert.