For what it is worth, I've developed a couple of strategies to get iSpindel to work with Brucontrol and I really don't think reflashing their firmware is the easiest way to accomplish this. iSpindel already broadcasts in html every 15 minutes or so (you can make this more frequent but it is discouraged) its information as recognizable json objects. So the easiest route I have found is to set the iSpendel to POST a generic HTML to node red with an identifier at the end of the HTML POST such as
http://127.0.0.1/ispindel001 (if you are running node red on your Brucontrol machine). Node red sees the tag at the end and grabs the information, then a simple function in node red puts the information into a form readable by Brucontrol such as:
What you decide to send to Brucontrol is then in a format that allows you to PUT the information to Brucontrol Data Exchange through a noded-red http request node:
http://127.0.0.1:8000/globals
Of course, you still have to create correctly named global elements for each json pair you are bringing in (which is kind of a pain, see my post above about the ability to use in-line quotes in a script) but at least it comes in dependably and you have not broken the ability for iSpindel to broadcast to other 3rd-party software such as Brewfather.
For me, looking around at other platforms, if Brucontrol were to embrace Node Red as a means to get things in and out of the fundamental platform (I believethere is a much earlier post that suggests making Brucontrol a nod-red node) it would open up a whole world of interface possibilities that from my perspective would make it absolutely first-in-class and go far to help market the ready-made solutions that Brucontrol is now bringing online. For example, if part of the value proposition for Uniflex was that you could automatically import your recipes and parameters from Brewfather and/or Brewsmith (which I and others on this forum are able to do using node red) I think it would be a significant advantage in selling Uniflex as something that builds and expands what you are already using out of the box. Of course this would require some standardization in element names, but it would also mean that scripts (and parts of scripts) could be more easily exchanged and understood. While the example of marketing may not match the primary goal of Brucontrol, I think everyone could agree that expanding the community and making the interface more user friendly could be.
Just my two cents, but I can see a lot of value in spending development time in opening up Brucontrol to much larger (and extremely helpful) development communities to accomplish things that might take much longer to develop as proprietary. Interested to see other opinions on this as someone who is in the middle of the Brucontrol learning curve.