The FrogPad
 
A forum to get help or talk about Roastmaster…or anything else coffee.

Data Logging from DIY kit  (Read 3188 times)

rswift

  • (8 Posts)
  • *
  • Karma: 0
    • View Profile
Hello,

The app is great, I'm using a Gene Café CBR-101. I recently stumbled upon a web site called Roast Hacker, there are a couple of great articles about adding a thermocouple directly to the rotating drum: http://roasthacker.com/?p=529

I've built the probe and am hacking the software a little. I don't have the Data Logging feature of Roastmaster, I did wonder if I could mimic the Phidgets setup, but that's not looking easy...

So I'm wondering, is there an option for Roastmaster to have a Data Logging feature whereby either, you publish a specific API to poke temperature readings into (sensor placement [bean mass, ambient, whatever], temperature value etc.) and a means of discovering that service on a local WiFi network, or, a simple multicast message to a given (configurable) port could be implemented to enable anyone to code up any device to broadcast a trivial UDP packet to the local network, to be swept up by Roastmaster?

It'd break the dependence on a very specific set of devices, those of us who want to tinker with the growing number of things from people like Adafruit (the kit roast hacker uses) could easily integrate. Roastmaster would still make money from the Data Logger feature, a handful of config properties could make it very easy to customise and like I say, it breaks your dependence on a very specific hardware components :)

Thanks in advance - Robert...

rswift

  • (8 Posts)
  • *
  • Karma: 0
    • View Profile
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.

Danny Hall

  • (363 Posts)
  • *****
  • Karma: 4
    • View Profile
    • Rainfrog
Hi Robert

Short answer–yes, I’m very interested in building a open-source protocol for Roastmaster, whereby anybody so inclined could use whatever means they desire to broadcast simple readings. Your words “breaks your dependence” are spot-on, and exactly what I hope to accomplish.

I’m always amazed at folks’ DIY ambition, and skill set, and would love to offer something like this. I’ve been very hard at work over the winter building some new cupping software. Now that that’s done, I want to jump back into Roastmaster. I have some good plans for a number of different things, but I want to begin working on that fairly early int he development cycle.

If you’d be interested in beta-testing something like this, please shoot me an email at support@rainfroginc.com. At the very least, I would follow back up with you and let you know how things are coming along, and what direction I choose to take.

Thanks for the kind words, and for reaching out!!!

Danny

rswift

  • (8 Posts)
  • *
  • Karma: 0
    • View Profile
Hello Danny,

Sincere apologies for the tardy reply, I've been doing some tinkering but not had as much time as I wanted over the last few weeks.

I would be more than happy to beta test anything. I've put my Adafruit code up on Github (https://github.com/rswift/wifi-temperature-broadcast/blob/master/WiFiTemperatureBroadcast.ino) and I've prepared a basic iOS app to listen for the broadcast messages (https://github.com/rswift/iOS-WiFi-Temperature-Receiver).

I strongly suspect the payload is lacking in content and possibly finesse too?

It'd be interesting to know what Roasthacker thinks about integration with a native iPad app, I am sure it'd be an interesting avenue to explore! http://roasthacker.com/?page_id=65 is the latest, I'm going to post a link to this forum post up there.

Thanks again - Robert...

rswift

  • (8 Posts)
  • *
  • Karma: 0
    • View Profile
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...

Danny Hall

  • (363 Posts)
  • *****
  • Karma: 4
    • View Profile
    • Rainfrog
Hi Robert

Sorry, I was in Dublin for the SCAE last week, just now getting back to work this morning.

This is fantastic!!

I’ve downloaded both ZIPs. I just ordered 2 of the TC breakout boards, the WiFi kit, battery, charger and USB charger.

Yes, JSON makes the most sense - less verbose than XML - my head gets stuck on the database side of things.

I’ll start off to match your configuration (push from the probe). This more closely mimics Roastmaster’s existing structure. Which, BTW, should be VERY easy to adapt to this. I’m quite proud of the probe code, and I believe my OCD tendencies in designing it will pay off here. Anyway, this will be a good starting point.

Thanks for springing for the Data Logging option. Unfortunately, Apple doesn’t let us give out promo codes for in-app purchases, otherwise I would have given you one.

I’ll let you know when I have the hardware together. I’ve spent the last 6 weeks “modernizing” Roastmaster’s code. As you can imagine, it’s a massive codebase. Most of the UI code was legacy “pre-storyboard” code. The new interface is pretty sweet–master-detail style, with improved inline attribute editing. I’m just now wrapping up the deprecations, and am looking forward to the new stuff.

This will probably be the first “new” feature I begin, hopefully this coming week.

Thanks again!
Danny

rswift

  • (8 Posts)
  • *
  • Karma: 0
    • View Profile
Excellent stuff, and Dublin isn't a bad place for drinks other than coffee :)

I'll keep my eyes out for progress :)

Cheers - Robert...

rswift

  • (8 Posts)
  • *
  • Karma: 0
    • View Profile
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.

Danny Hall

  • (363 Posts)
  • *****
  • Karma: 4
    • View Profile
    • Rainfrog
It’s working great! Not bad for a day’s work.

There is now a new “Roastmaster Transfer Protocol” probe type that will poll a UDP port for JSON transmissions. Most of the bells and whistles are finished on the RM side. Though, I haven’t actually soldered the hardware yet–looks like I’ll need a breadboard for programming the breakout board, but that should be trivial. For testing, I wrote a quick Mac app to send packets with random temps. (See attachment).

About 80% complete code wise in RM. I had planned for expansion with probes, so I toiled over the class structure and class clusters when I designed the code, so it went quickly.

I’ll post more when it’s complete and we’ll discuss a beta. I’m hoping you’re on iPad. The dev version of RM is quite a different animal than the current iTunes version. Everything is storyboarded for size classes, but I don’t quite have those worked out yet for iPhone yet.

rswift

  • (8 Posts)
  • *
  • Karma: 0
    • View Profile
Hi Danny,

This sounds great, thanks for the update. I am using iPad (I do have an iPhone too, but don't use Roastmaster on it) so looking forward to being able to float some datagrams around and see the results appear :)

Cheers - Robert...

Danny Hall

  • (363 Posts)
  • *****
  • Karma: 4
    • View Profile
    • Rainfrog
I soldered the Huzzah and Max chip today, updated your sketch a bit and it's running like a champ. The only problem I have is that the WiFi only wants to connect once every four or 5 resets. Might be a timing thing. Not critical at the moment.

The protocol (RDP - Roastmaster Datagram Protocol) I settled on is a bit different than I originally anticipated. I added support for an epoch (or counter) key/value (optional) to make sure packets didn't process in the wrong order - out-of-order packets are discarded. And, since UDP is connectionless, the ability to send mini “keep alive” packets, for periods of inactivity. (I have plans for more than just temps with this).

Also added handshaking support. Roastmaster will accept a SYN request, and reply back with an ACK. So, you can do initial SYN broadcasts as multicast, listen for a response and glean the sender address from the ACK packet, and continue broadcasting with the actual Roastmaster address. That way, everything is dynamic.

I didn’t actually look at your JSON format post until just now. We followed a similar line of thinking, though. RDP datagrams start off with a little header info, then have a “Payload” key/value. From there, everything is grouped to conserve space. The protocol will support 16 Channels per broadcaster (client), and Roastmaster (the server) supports unlimited “listener” objects - 1 per serial number. Those are defined by the values entered into RM probes (serial and channel). This protocol will end up being used on more complex boards, so it needs to have some headroom.

I’m almost done with a data sheet, which defines the packet structure, SYN/ACK, and some other details of how Roastmaster interprets things.

Can we continue this conversation via email? If so, please contact me at support@rainfroginc.com

This is turning out to be quite fun.

rswift

  • (8 Posts)
  • *
  • Karma: 0
    • View Profile
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...