OP
OP
Ya, I could see where that would be a trip-up. I suppose adding a time to a date/time tells the interpreter to blend these two but a straight add doesn't.
BruControl: Brewery control & automation software
- Thread starter BrunDog
- Start date
Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:
I modified the Code to change a Global to a DateTime 14 days in the future:
new datetime trigger
trigger = "Global 1" Value
print trigger
new time change
change = 14.0:00:00
new datetime future
future = trigger + change
print future
"Global 1" Value = future
if future > trigger
print "Yes"
else
print "Nope"
endif
stop "Test
OP
OP
Kinda quiet in here. Let's stir the pot.
Angus Grant
Well-Known Member
Data exchange????
Tell me more, sensei!
Tell me more, sensei!
OP
OP
The manual has what you seek!
- Joined
- Mar 24, 2016
- Messages
- 551
- Reaction score
- 60
Website shows 1.0 as the 5/7/19 update. I assume it should be 1.1.
Angus Grant
Well-Known Member
Awesome stuff Peter. I'll have a look at it later this week.
I should have it up and running fairly quickly. Is there any support for passing in bearer credentials? I'll have to code up a different API to allow BruControl posting and getting
I should have it up and running fairly quickly. Is there any support for passing in bearer credentials? I'll have to code up a different API to allow BruControl posting and getting
Die_Beerery
Well-Known Member
- Joined
- Aug 21, 2017
- Messages
- 842
- Reaction score
- 641
Data exchange you say!?!
[emoji41]
[emoji41]
RiverCityBrewer
Well-Known Member
There I was... about to go to bed... Pro license purchase incoming!
OP
OP
One big FYI for RTD users... since we moved away from a discrete "w/RTD" wiring map, this map will not exist any longer, which will render your configuration null. Please either use the legacy interface definition files included in the v1.1 distro, or email us your configuration, and we'll edit it to work with the new RTD integrated interface definition file.
OP
OP
While we're kicking up dust, here's an early look at a MEGA format UniShield (two piece design). 48 high power outputs!
OP
OP
Corrected - thank you for pointing it out.
RiverCityBrewer
Well-Known Member
FYI, the link for the ESP32 wiring map is dead... link looks malformed.
OP
OP
Fixed. Thank you for reporting!
Die_Beerery
Well-Known Member
- Joined
- Aug 21, 2017
- Messages
- 842
- Reaction score
- 641
A little more in depth look at data exchange.
OP
OP
Amazing! Great work!
Just a thought while looking over the v1.1 wiring map for the MEGA 2560. Please correct me if I am wrong but the wiring map states that interface pins 50, 51, and 52 are not connected (N/C). That is true unless you need to connect RTDs (perhaps via a RP2) as I understand it. As indicated in the RTD via SPI schematic, something actual IS connected to 50, 51, and 52. So why is the wiring map not reflective of this fact that to wire RTDs you need to connect to the SCK, MISO, and MOSI pins on the MEGA 2560 physically at pins 52, 50, and 51? This appears unnecessarily muddy.
OP
OP
Fair comment. In the classic "pin to wire" sense, you do not wire these pins. In the "expand your controller" sense, you do. This has been consistent since the beginning though - we say "don't use this pin" when it is used for something system related... e.g. pins 20 & 21.
That said, we can clarify that with something better than "N/C". Thanks!
I can't wait to play with the new stuff.
In the new v45 firmware for the ESP8266, is the counter issue that existed for GPIO0 fixed? I am starting to make a controller for my keg fridge and need 4 counter channels. I can use a MEGA or an ESP8266, and I'de rather use the latter if I can.
EDIT: Nevermind, I see in the new firmware's wiring map that GPIO0 is no longer a counter interface.
In the new v45 firmware for the ESP8266, is the counter issue that existed for GPIO0 fixed? I am starting to make a controller for my keg fridge and need 4 counter channels. I can use a MEGA or an ESP8266, and I'de rather use the latter if I can.
EDIT: Nevermind, I see in the new firmware's wiring map that GPIO0 is no longer a counter interface.
Last edited:
OP
OP
Typically when you reply to yourself, they think about locking you up... However, to offer up some self-help on this topic, for those inclined and who have .xml editing skills, you can edit your configuration file (.brucfg). To do so, we suggest you use an XML editor such as Notepad++ (thanks @Die_Beerery for turning me on to it).
Shut down BruControl then make a copy of your configuration file to have as an extra backup. Opening it in the XML editor, under tag 'Devices', you'll find a 'Device' tag which represents the interface you are looking to edit. The last line of that tag contains a 'WiringMap' tag. It will say "With RTD" but should be changed to "Default", as shown in the blue hazing below. Save it, then restart BC and you should be all set.
If you are not comfortable with this, as noted above, feel free to send it to us for the edit.
Angus Grant
Well-Known Member
I had a thought that might help setting up brand new interfaces.
With the genuine Arduino devices I bought for my client, it was easy enough to grab the MAC address from the shield. I purchased a "DuinoTech" (Aus Arduino clone) Mega R3 and their Ethernet shield does not have the MAC address on it. I had a little bit of fun finding it in my router DHCP lists.
Maybe you could write the devices' current IP address to the LCD screen if connected. BruControl won't be writing to it as it doesn't know about it yet. That would make it easier to find the device in the router DHCP lists and assign a reservation for it. Maybe write the MAC address to the LCD as well.
With the genuine Arduino devices I bought for my client, it was easy enough to grab the MAC address from the shield. I purchased a "DuinoTech" (Aus Arduino clone) Mega R3 and their Ethernet shield does not have the MAC address on it. I had a little bit of fun finding it in my router DHCP lists.
Maybe you could write the devices' current IP address to the LCD screen if connected. BruControl won't be writing to it as it doesn't know about it yet. That would make it easier to find the device in the router DHCP lists and assign a reservation for it. Maybe write the MAC address to the LCD as well.
OP
OP
Ethernet devices (Wiznet based) do not have a MAC address hard-coded into the chip or onboard. Therefore, the firmware cannot poll the address - it can only assign it. The units which have a sticker are simply there to tell the user that specific address was reserved for that board (they paid for it). The units which don't require you to generate one, and in doing so, could create a duplicate one, though the risks of overlap are small as most devices will be behind private networks like ours.
So while your idea is a good one, it would not be possible. You mentioned your router found the MAC address, but possibly it found the default MAC in the firmware of AB:BC:CD: DE:EF:FA and IP of 192.168.1.100. WiFi devices do have MAC addresses hard-coded, and those can be polled.
Gameface
Well-Known Member
Are you saying that if I have RTDs then the only way to make them work with 1.1 is to contact you for a special map or use a legacy map?
So If I use RTDs I should probably just stick with version 1.0 and not expect any further support in future updates?
Gameface
Well-Known Member
Using PIDS vs this is looking like the thing to do if I don't want to deal with headache after headache. This is moving further away from being an alternative to the mainstream approach and more and more looking like a hobby within a hobby for a select few.
OP
OP
Sorry, perhaps I didn't explain it correctly. We removed the need for a separate firmware and interface map to use RTDs. In the process, made essentially every digital pin RTD capable (thanks @clearwaterbrewer for the push). Because we removed the map, when you migrate to v1.1, BC will look for a map that doesn't exist. To fix that, we just need to redirect the map name in your configuration. We offered the service to it for you - and I posted instructions to do it yourself via a text edit sequence above. Or you can copy over the old map and use it (though we don't suggest this - we provided it for assured compatibility).
Sorry it's not automatic - we think this is a improvement, and forward movement sometimes needs some quick adjustments. I actually think we have made it a lot easier to adopt by consolidating maps and firmware versions.
I'm sincerely sorry you feel that way - can you expand on your "headache after headache" comment? I personally don't see how wiring discreet PIDs and their limitations is better than software based controls, but I can appreciate your opinion.
Well in a word, no. The three routes are to use the legacy wiring map included in the V1.1 distribution (it is in a sub folder) or you can send your config file to BrunDog so he can make a quick change. It's a one time thing and really at the request of the users to remove the RTD wiring map limitation of four (4) RTD sensors as I see it. Lastly, BrunDog later showed how simple the edit needs to be, check post #2420, so you can just do that yourself. I will say, that if making this change in the config file (which is a XML file) is not within your skill set, I would say perhaps BruControl is not for you and PIDs are a better fit. All of this is still not super "easy" stuff for most folks and I don't suspect it ever really will be.
It's like the iPhone. it is a great device, dead simple and part of that is because it hasn't always been super flexible due to the lock down required to make it simple. This is a PID. BruControl is like an Android device, it isn't locked down by the ghost of Steve Jobs, so it can be more flexible but at the cost of being more complicated and sometimes things are less robust that way. This of course is constantly evolving and so is BruControl, which will indeed change the dynamic of the product fit for some over time.
Last edited:
augiedoggy
Well-Known Member
The original version works as well as it always did. Theres no need to update unless you want to take advantage of some new upgrade feature or fix a bug that someone using scripts may have found. Its just like those who choose to replace their auber pids with the latest and greatest version of the EZboil only you dont have to pay to replace the hardware... aubers upgraded the ezboil what 3-4 times now?
Do you need to upgrade? That is always a question as advances can cause issues. You can stay where you are, but may miss out on cool things (like the Tilt support).
It can be frustrating when something like this happens but having the Arduino as the hardware will always cause this type of issue. Rather than having a "fixed" hardware solution like the BCS which has very limited upgrade (and slow coming and $$$$ upgrades), and this can be a concern in the future. For example, if Arduino comes out with Rev 4, it may (or may not) cause issues. Regardless, BruControl has the easy solution by editing one word in the Config file.
BruControl requires some knowledge of coding which is much more complex that changing one word in the config file.
On the other hand, where you were limited to a max of 4 RTD probes, you can now have almost unlimited with just one mega, and since you can add an another, the # is very very many. I have a lot of these probes that were just sitting around after I upgraded from Stand alone PIDs. PIDs are good if you want to control one vessels per PID, but they require fiddling before a brew and are almost impossible to change in a Brew. If you want some true automation, you need something like BruControl,
Is it a Hobby? Well it almost has to be. BruControl cannot be a "job". I doubt if anyone quit their day job.
Just look at what the program costs? Let's say you sell 100 a year, that would garner $19,900 maximum. Maybe a nice chunk of change for a hobby, but well below the poverty line for a living. And what about next year?
"Real" Automation Software (with probably less capability and customization) cost thousands and has support costs. This is a bargain!
OP
OP
My RTD on my test-bench with single RTD is working just fine with no changes or extra effort... <scratches head> I upgraded SW to 1.1, it worked, I upgraded FW to .45 on it, still works. I also upgraded a couple ESP32's via OTA with no problem (I have not done production Mega yet)
I am only having an issue upgrading a Feather M0 firmware (winc1500) with the 1,2,<comport>,3 sequence... it just sits at 'Send auto-baud'
I am only having an issue upgrading a Feather M0 firmware (winc1500) with the 1,2,<comport>,3 sequence... it just sits at 'Send auto-baud'
OP
OP
You need to double-click the M0 so the LED blinks bright and dim. Then it will take the FW.
OK, that got it to program, but now it seems dead... I can put back in program mode and program over and over, but if I try to do the network setup/debug, it never opens termite.. (I was able to revert to .v43 and program network and connect to it fine) maybe it is permissions of .v45 opening termite or something?
Die_Beerery
Well-Known Member
- Joined
- Aug 21, 2017
- Messages
- 842
- Reaction score
- 641
Keep trying. For some reason it takes me sometimes once to get termite to work, and sometimes 50. Not sure why. I do know it’s something with button clicks/combinations.
no luck, tried 20-30 times, even tried a dozen times with it in programming mode (did not think it took programming mode to set network, but tried just in case...)
for giggles, I did .v43, .v44j, and .v44k and they all program, bring up termite the first time, take a config and connect... but .v45 no termite...
for giggles, I did .v43, .v44j, and .v44k and they all program, bring up termite the first time, take a config and connect... but .v45 no termite...
OP
OP
Ok let me test it. Sounds like the installer might be mucked up.
OP
OP
Ok... tested, works correctly on my end. Are you saying Termite never starts when you select main menu option 2 and follow the prompts?
Gameface
Well-Known Member
My apologies. Thank you for the info. I've started working nights again and I have a tendency to be irrational and cranky when I work nights. Nothing to see here folks, please move along.
yes, it never seems to open termite, it just goes back to the main menu.
Here is a 45 second video of .v44L working and .v45 not working
OP
OP
If 45 is updating the FW, then use 44 to open termite. Or open it manually by running the termite.exe file in the resources folder.
Just an FYI -
in BC V1.1, I could use, but not add devices to my SonOff Dual interfaces. I loaded up the last RC version of BC and added the device I wanted and went back to 1.1 and it all worked... I will upgrade the FW on the SonOff, but they are mounted high up on a wall.
in BC V1.1, I could use, but not add devices to my SonOff Dual interfaces. I loaded up the last RC version of BC and added the device I wanted and went back to 1.1 and it all worked... I will upgrade the FW on the SonOff, but they are mounted high up on a wall.
Similar threads
