Any interest in using STC-1000 as a Brew Pi device?

[alphaomega]

With the recent development of STC-1000+, the possibility to have bidirectional communication opens up some interesting prospects.
I was thinking it could be a good idea to have the benefits of both projects.
Now I'm not too familiar with Brew Pi, but the idea would be to have the STC-1000+ able to operate stand alone, and Brew Pi being able to read temperature, log, graph and all that, and possibly also 'override' thermostat control of the STC. Should communication fail, then it would fall back to thermostat control.
So, the STC would replace the Arduino and surrounding hardware.

Is this something there would be any interest in? If so then, then I'd much appreciate help with the BrewPi side of things, if there is anyone experienced around.

 

[FuzzeWuzze]

What kind of communication are we talking about on the STC-1000?

The BrewPi communicates to the arduino through JSON, so if you could set up the STC1000+ to decode and create those messages and do the appropriate things i dont see why it wouldnt work, the web server is pretty simple i think in that respect(from what i understand). Assuming you could get an open TTY port from the RPI to the STC1000 as that is what the BrewPi RPI is coded to look for.

The bigger question though is what is to gain from doing so? The STC is larger, and more expensive than buying an Arduino Uno for $10 on Amazon...I could see it being useful for those with STC1000+ setups already i suppose especially those with Blackbox's etc...but its also a ton of work on your part probably to get it implemented

FWIW Elco/mdma_ are really good about answering on IRC. Especially with you being in the Euro area it would be easy to talk to them.

I can help with what i can if you need anything let me know.

 

[alphaomega]

Well, the communication obviously won't be able to handle the JSON paradigm of BrewPi, so there would need be additional logic on the Pi for the protocol.
The gain would be that the STC-1000 has all needed parts in one convenient package and are pretty cheap. This would make it easier to add more units to a setup. An UNO or a pro mini can definitely be had for cheap, but you need to add relays, LCD and stuff and a big mess 'o wires to get it running and it adds up.

Though, I have been looking through the BrewPi source a bit since I posted this, and it seems all regulation stuff is done on the arduino, only profile stuff happens on the Pi.
This makes it not really worth while to try to adapt BrewPi to what I am doing, if anything, I think I'd rather try to build my own solution.
But there hasn't been an awful lot of interest, and maybe rightfully so. If you want logging and a web interface, you're probably running BrewPi already.
Still, this is what I enjoy doing, so maybe I'll give it a go, if/when I get some time for it

 

[Brewster]

I think this would be an awesome feature to have!

Would you plan to try and use RF to transmit and receive or a direct connection? I would be up for helping with the web side of the Raspberry Pi if you decide to not go with BrewPi and build it yourself. Setting up my STC-1000+ this weekend and have lot of extra time recently.

Cheers!

 

[alphaomega]

@Brewster: Well, I have a working RF implementation to transmit temperature, but that can only transmit. But I also have a 'single wire' communication implementation to read and write, so I think that would be a better way to go.
I have ordered a bunch of current limiting resistors and 3.3v zeners, to use as a cheap level shifter between the stc and raspy. Once I have that, I will try to see if I can write some C code for the raspy that can meet the timing constraints (otherwise I might have to slow it down on the STC as well).
If I can get that working, then it would be really nice to get a web interface going, and I would appreciate any help. I'd like to keep design (as in architectural, not graphical) simple and robust and not use more dependencies than absolutely required. Ideally, I'd like a standalone server written in C (libmicrohttpd), so it can all be contained in one autonomous package and be pretty efficient.
Feel free to shoot me a PM if you have any ideas