Welcome to pressuremon Discussions!

[mp-se]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[nzbrewer]

Hi Magnus. I was thinking about building a wireless pressure transmitter for logging to BrewBlox and implementing something similar to what we did with the iSpindel back in 2022. I see you started down this path almost 4 years ago. Did you ever get a prototype working? My initial approach to the hardware would be to mount a transducer on a triclamp fitting and then build an interface out of an ESP32 enclosed in a 3D printed case with probably a 18650. The power would need to last for 4 - 6 weeks (for pilsners) as we brew in unitanks.

All the best for the new year mate, cheers.

[mp-se]

Hi, yes I got a prototype working measuring pressure at intervals but when I started 4 years it was very hard to find adequate pressure sensors. I did a lot of tests and you really need a digital pressure sensor to get the accuracy needed and a sensor that is tuned to the range needed for beer brewing. At time i could only find the Honeywell senors which worked well but was a tad expensive.

My other challenge was to have some software to collect and store the data and that I could combine with other data from my brews. This part is now sorted out, I ended up building my own software for handing data from my other projects and its prepared for handing pressure data.

Then there was a number of other projects that took priority but now I have most of them done so I have started to work on the pressure sensor project again. I have most of the base code in the gravitymon project that I intend to use as a base for this one as well, its just the measurement that is different. I have just recently updated all my projects to use my base esp framework and vuejs for the user interface so most of the basic work is done.

I started to look for pressure sensors this autumn and found some new ones on aliexpress that I'm currently testing out. They seams to work fine (cheaper clones) and the next step is to do the 3d model so I can hook it up to a keg for real testing.

I plan to use the esp32 mini boards as a base for this project (esp32s2, esp32c3, esp32s3) and find a good hardware design that fits all those boards. These are the main features that I'm aiming for:

• Web based UI for configuration
• Pushing data to various targets (http post, http get, mqtt, influxdb) using format templates (as in gravitymon)
• Support for various digital pressure sensors (Honewell APB Gauge sensor, CFSensor Gauge I2C)
• Operating on Battery or constant power
• PCB Design
• 3D model for case and connector to standard JC adapter (quick connect)
• Documentation and build instructions
• A way to force the device into configuration mode (switch connected two GPIO pins)

[nzbrewer]

That all looks great, essentially what I was looking at as well based on the approach you developed for GravityMon. I found a few options on Aliexpress that seemed promising, I2C interface, BSP mount and range options as low as 0 - 0.2 Mpa. We carbonate our beer in the fermenter (unitank) and having remote readout capability would be quite useful. For our setup, I would install a tee where the analogue pressure gauge is mounted and have both installed, at least initially. These are triclamp fittings so we wouldn't be using a 3D printed mount for the sensor.

I'm happy to purchase a transducer(s) from Aliexpress, build your prototype for the electronics and test the software here as well if that would help. Besides BrewBlox, I also have Fermentrack on another pi I could test.

[mp-se]

This is the first option I tested a few years back which performed well, but a little expensive; 25-50 USD each. https://automation.honeywell.com/us/en/products/sensing-solutions/sensors/pressure-sensors/basic-abp-series.

I'm currently trying to get these working https://www.aliexpress.com/item/1005005279474582.html?spm=a2g0o.order_list.order_list_main.22.41231802nBoJKz which is a much cheaper alternative. They appear to be a clone of a CFSensor.

If you find some other options i would be happy to try them out as well.

I need to do some 3d mount for connecting this sensor to the keg which is the next step.

Once I have the basic running I will probably see how I can reuse the codebase from gravitymon to avoid a lot of double maintenance.

I used fermentrack in the past but since there was no real interest to add pressure support I created my own software so you can check out the brewlogger project as well. I'm not that far away from releasing the 0.8 version.

[nzbrewer]

The sensor options I have been looking at are already enclosed in a stainless housing with a threaded bsp fitting that can be mounted directly to a tri-clamp. They are available with various output and sensor range options, similar to this: https://www.aliexpress.com/item/1005005514909464.html in the 0-0.2Mpa range with the I2C interface.

The claimed accuracy is ±1% of full scale which is ~0.3 psi if correct. The G1/4 connection is the same as a 1/4" BSPP fitting and a tri-clamp of that size isn't readily available here but is on Ali - https://www.aliexpress.com/item/1005006702414156.html. With the exception of a corny keg, most other fermenters capable of pressure fermenting will have tri-clamp fittings.

This is just an initial search and I haven't done any research on what library options exist for communicating with these types of sensor. Any thoughts?

[mp-se]

Thats a really good option, would save me a lot of time if this is doable. This will work with corny kegs as well since it has the standard fitting. Will look into this further

[mp-se]

This is a combo that would be cheaper than the one you are suggesting, then I could connect that to a standard beer line on my corny kegs. I was also thinking about supporting multiple pressure senors on one device. This sensor has a 1/4" NPT which fits the John Guest NPTF 1/4 thread, this can the connect to a standard 3/8" gas line.

https://www.johnguest.com/us/en/od-tube-fittings/acetal-white/threaded-connectors/female-adapter-nptf-thread + https://www.aliexpress.com/item/1005007391851603.html?spm=a2g0o.productlist.main.7.7c7c63997YYZlC&algo_pvid=c36c96e5-5c92-436f-b1b9-87a602a6a2fb&algo_exp_id=c36c96e5-5c92-436f-b1b9-87a602a6a2fb-3&pdp_npi=4%40dis%21SEK%21217.58%21184.91%21%21%2119.18%2116.30%21%40210385a817362546370412885e30e9%2112000040581948083%21sea%21SE%21144234077%21X&curPageLogUid=Wnzq0WCMuUox&utparam-url=scene%3Asearch%7Cquery_from%3A#nav-specification

[nzbrewer]

Presumably the I2C communication is the same for all of their sensors and the library addresses all of the available pressure ranges.

It looks like the key difference between the 300 and 400 series is the steel used with the XDB401 being SS316L. The Aliexpress listing only shows the 401 with the G1/4 connector but their website does show it with the same connector options as the 302 in your link. I see the info on the page is confusing with some of the 401 text also included but I think this is the XDB302. Regardless, they both should work fine. I'll order the 402 and the tri-clamp adapter and should have it here for testing by the end of the month.

[mp-se]

Have not been able to find any info in an driver or specification on that i2c protocol. Probably need to contact the manufacturer for that

[nzbrewer]

I'll look as well, there appear to be several manufacturers with similar offerings.

[nzbrewer]

The manufacturer of the example above state here they have a library and examples available for use with an arduino - https://www.xidibei.com/en-nz/blogs/news/unleash-the-power-of-xidibei-pressure-sensors-in-your-arduino-projects.

[mp-se]

I have emailed them, lets see if they respond

[nzbrewer]

The XDB401 model specifically made for espresso machine use is essentially the same model we have been looking at. Here is a library and some code for using it for that purpose - https://github.com/jorticus/lupa-espresso/blob/cb8c7a66d705ca89d758153fef2f4d339645b364/src/PressureTransducer.h.

I didn't have any luck finding the library mentioned in the news post link in Arduino IDE.

https://www.xidibei.com/en-nz/products/xdb401-pro-coffee-machine-ss316l-pressure-transducers.

[mp-se]

Good to know, I would want some response / confirmation from the manufacturer before ordering some sensors.

[nzbrewer]

Another query, would your gateway software be compatible with this?
https://www.aliexpress.com/item/1005006715794302.html

It appears to be similar to the Lolin S3 Pro you reference but with an integral IPS capacitive touch display. I have one here waiting on the updated XTouch interface software for our 3D printer (unknown eta). I realise this screen would require a different library and updated display code but I'm willing to attempt the modification.

I also have a Tiltbridge that is now surplus to requirements but the screen is pretty small.

[mp-se]

Not sure, it does not say how the pinout nor what drivers are needed for the touch screen and lcd. The resolution is also different so it would require some modification to work. I have used a similar combo from waveshare for some of my projects.

The library probably supports it but the pins have been different on the boards i have tried out.

The tiltbrdige based on the lolin esp32 pro would work.

[nzbrewer]

I found the libraries and example code for the 5" display in an XTouch fork developed for this display. However, it still uses the 2.8" board UI so I'm waiting for the original developer update before switching.

I built the Tiltbridge in late 2020 and it is the esp32 pro version so I'll use it to try your gateway.

Cheers.

[mp-se]

I got the specifications for the sensors today so I will look through their offer and order a few for testing and evaluation.

[mp-se]

I have updated the dev stream with the documentation i got from the vendor and also implemented a driver based on their code, will test that once i get the sensors which would take a few weeks.

I plan to share the codebase with gravitymon since 80% of the code is common, this will simplify future maintenance.

[nzbrewer]

Interesting, quite a bit different than the example I found for the coffee machine. It appears this one uses a K value from a data sheet to correct for the device's pressure range where the coffee machine example appears to get the full range value from the sensor itself to use in the calculations. Have you encountered sensors where the full scale value is stored on the device (i.e., when multiple ranges are available for a sensor model)? I don't know enough about the I2C interface to know if any configuration information can be stored on the device.

I'm looking forward to experimenting with this, my unit should be here in 2 - 3 weeks.

[nzbrewer]

Thanks, I'll let you know when my unit arrives. It is the 0 - 0.2Mpa version (max 29 psi).

[mp-se]

It looks like the reading process is the same, the difference is that the XIDIBEI sensor uses the max pressure for the calculation and not a k value but the i2c part looks the same. Will confirm when i get my samples.

I guess some devices have nvram to store parameters but these seams to be quite simple. You can find the data sheets under the /cad folder in the dev branch, one of the docs describe the reading process.

There is also a class in the src folder with an implementation of that code for arduino but i need to test that.

[nzbrewer]

Thanks, I'll have a look, much appreciated.

[mp-se]

I got my sensor on friday but I have no luck getting them to work.. I connected according to the schematics but I cant get it to respond to the i2c scanner even. I know the driver works since I've tested it on the CFSensor I have which has the exact same read sequence and address, the only thing is the calculation and the value used for that.

When you get your sensor it would be great if you can test them and see if you get it to work. I might be that I have got a bad sensor.

[nzbrewer]

I think I read somewhere on a post that the address 0x6D didn't work but 0x7F did. I noticed that the library used for the espresso machine mod set the address to 0x7F as well. Maybe a review of the .h and .cpp files in this implementation will help (for an ESP32)?

https://github.com/jorticus/lupa-espresso/blob/cb8c7a66d705ca89d758153fef2f4d339645b364/src/PressureTransducer.h

Yours came fast, I don't expect delivery for another week. Did you test on an arduino or an ESP32 D1 mini?

[mp-se]

I think I read somewhere on a post that the address 0x6D didn't work but 0x7F did. I noticed that the library used for the espresso machine mod set the address to 0x7F as well. Maybe a review of the .h and .cpp files in this implementation will help (for an ESP32)?

https://github.com/jorticus/lupa-espresso/blob/cb8c7a66d705ca89d758153fef2f4d339645b364/src/PressureTransducer.h

Yours came fast, I don't expect delivery for another week. Did you test on an arduino or an ESP32 D1 mini?

It should reply when doing a scan for device (sending a command to the adress) but that does not work. I think the example code uses the 6D. I'm suspecting my sensor is broken. I use an esp32s3 for the testing and reduced the 12c speed to 100kHz (think max is 400kHz) according to datasheet.

[nzbrewer]

OK, thanks. I'll let you know when mine arrives.

[nzbrewer]

The sensor arrived today, which code do you want me to try? I don't have a bare ESP32, just one with a 2.8" screen and an S3 with the 5" screen. I also have several Arduinos and some Lolin D1 minis as well as a TiltBridge.

Well, interestingly, the bag says XDB401 which is what I ordered. However, the etching on the unit says it is a 308 series with a manufacturer date that matches the shipping date. The key difference seems to be the 401 has a ceramic sensor and the 308 has a piezoresistive sensor. It does however have the other specs I ordered, 0 - 0.2 Mpa and I2C (3.3V) interface.

[mp-se]

The current code in the dev branch contains only the basic i2c communication and sensor reading so any esp32 version should work (just change the board to match what you have). The screen will not be used so that does not really matter.

The code is written to use the standard SDA and SCL pins (you can check the pins_arduino.h how that is mapped).

If you use this code for main.cpp then that should scan the default i2c bus and you should get a response on 0x6d which is the default adress according to data sheeet, if you get a different adress you can change that in the XIDIBEI.hpp file.

Then is should print the pressure and temp readings on the serial console every 2 seconds.

#include <Wire.h>
#include <pins_arduino.h>

#include <config.hpp>
#include <looptimer.hpp>
#include <main.hpp>
#include <pressure.hpp>

SerialDebug mySerial(115200L);
PressConfig myConfig;
PressureSensor myPressureSensor[MAX_SENSOR_DEVICES];

void scanI2C(TwoWire *wire) {
  for (uint8_t i = 1; i < 127; i++) {
    wire->beginTransmission(i);
    if (wire->endTransmission() == 0) {
      Log.notice(F("Main : Found device at %X." CR), i);
    }
  }
}

void setup() {
  Log.notice(F("Main: Starting up." CR));

  int clock = 100000;

  Log.notice(F("Main: OneWire SDA=%d, SCL=%d." CR), SDA, SCL);
  Wire.setPins(SDA, SCL);
  Wire.begin();
  // Wire.setClock(clock);

  Log.notice(F("Main: Scanning Wire. Clock=%d, Timeout=%d." CR), Wire.getClock(), Wire.getTimeOut());
  scanI2C(&Wire);

  myConfig.setPressureSensorType(
      PressureSensorType::SensorXidibeiXDB401_I2C_KPa_400, 0);
  myPressureSensor[0].setup(0, &Wire);

   Log.notice(F("Main: Setup completed." CR));
}

LoopTimer timer(2000);

void loop() {
  if (timer.hasExipred()) {
    timer.reset();

    myPressureSensor[0].readSensor();
    Log.notice(F("Loop: Pressure 0 %F psi, Temp %F C." CR), myPressureSensor[0].getPressurePsi(), myPressureSensor[0].getTemperatureC());
  }
}

[nzbrewer]

Thanks, I'll set it up today. I had noticed in config.hpp that the sensor range I ordered isn't included (0 - 0.2 Mpa). However it appears that is just used to set the maxPressure value so will only impact the calculated pressure. If communication works, I'll edit the 0 - 0.3 Mpa line to reflect this unit and will change PressureSensorType in main.cpp.

[mp-se]

I will add that type then, i have also ordered a new sensor, lets see when it turns up

[nzbrewer]

When running debug in Platformio (under Visual Studio Code), I get these error messages:

Compiling .pio\build\press32s3-release\lib5d5\ESPmDNS\ESPmDNS.cpp.o
*** [.pio\build\press32s3-release\src\pressure_xidibei.cpp.o] Error 1
*** [.pio\build\press32s3-release\src\pressure.cpp.o] Error 1
*** [.pio\build\press32s3-release\src\pressure_analog.cpp.o] Error 1
*** [.pio\build\press32s3-release\src\main.cpp.o] Error 1

I don't see any errors (dependency or otherwise) when I check the files so I have no idea why they failed.

Also, I see there is an Arduino.h file in C:.platformio\packages\framework-arduinoespressif32\cores\esp32 folder but I couldn't find out how to confirm that is the dependency being linked to in the project. I do need to edit it as the SDA and SCL pins of my board are 22 and 27 respectively (using esp32dev as the board).

There are also a lot of error messages associated with RESET commands but I don't know if they were fatal.

Am I missing something fairly obvious?

[mp-se]

i guess you are not that familiar to platformio... You need to edit the platformio.ini file and change the line that refers to the target board:

board = lolin_s3_mini 

Use the that is defined for your board and platformio will select the right compiler and set the PINS correcly. If you are using the default pins for that board then when you right click SDA and chose go to defintion then the pins_arduino.h for your board should be open.

A list of boards can be found here; https://docs.platformio.org/en/stable/boards/index.html

When you save the file then platformio should download the correct dependecies and you need to wait for it to complete before starting a build. The errors are probably related to that it has not downloaded the correct compiler (or dependecies)

[mp-se]

Debug will not work out of the box, you need special setup and jtag interface for that.

Do a release build, upload, open a serial terminal and check the result in the console

[mp-se]

there is an option to do a verbose build, that might give some more input to what the issue is

[nzbrewer]

I did do that first, the board was changed to esp32dev in platformio.ini which is what the documentation said to use for the Espressif ESP32 Dev Module on the board list. I found the board to use in documentation and platformio code examples for the board I have. The chip is the ESP WROOM 32.

But you are correct, my familiarity with Platformio is limited and I was sure I missed something even after having a good look through the documentation. I am fairly experienced with Arduino IDE and only switched fairly recently. Thanks.

[mp-se]

I have got it to work. But I had to multiply the pressure value by 10 to get a correct range compared to the datasheet but i dont really trust that part... I have also removed the dependencies that is not needed for the test case...

[nzbrewer]

I spent some time last night trying to follow the calculations from the sensor readout and couldn't figure out how the static_cast section was doing the math identified in the documentation to get rawPressure and rawTemperature. I see you have changed that and added a log output, great.

The other query I had was in 2 instances of convertPaPressureToPsi, the one in pressure_xidibei.cpp looked incorrect (changing kPa to Pa?).

Having to multiply by 10 is an interesting issue. As I understand it, the pressure calculation just converts the rawPressure to a percentage of full scale.

I think the mistake I made when modifying platformio.ini for my board is I only changed the board type but see you also changed one of the build_flags from ESP32S3 to ESP32 when you added the new target. Could that have caused the issue?

Sadly, I have to go overseas shortly (unplanned) so will lose the capability of testing with a pressure source for a couple of months. I can take the sensor and board and test the code if needed. I'll upload the new test code this morning to see how it is working with this sensor.

[nzbrewer]

I'm had a build error:

*** missing SConscript file 'script\copy_firmware.py'
File "C:.platformio\penv\Lib\site-packages\platformio\builder\main.py", line 180, in

I noticed you removed this from the ESP32S3 target so I removed it from the target for my board which fixed it.

[mp-se]

Yes the copy_firmware is not needed right now. I will remove it from the esp32 target. And yes the esp32s3 define would have caused issues by including the wrong headers.

static cast is used to convert between different data types in a standard way. But i changed that to match the datasheet.

I also noticed that the temp readings was quite low so i will need to check that. Also sometimes i get strange values from the sensor (way off) so there are still some issues to dig into.

I got 2 different datasheets from the manufacturer and there is some quite big differences there so it will take some time to figure this out

[nzbrewer]

Thanks. Let me know if you would like something tested on my unit. It doesn't state the actual model on the unit, just the series so i can't confirm if they sent the pressure type I ordered (01 for gauge) but based on the current readings, it looks like they did..

[nzbrewer]

Hello Magnus, did the sensors and ESP32-C3 units arrive? In the interim, I bought a digital gauge with supposedly 0.2% of full scale accuracy (https://www.meokonint.com/rotary-bluetooth-digital-pressure-gauge-product/). I have no way of testing it here but will as soon as I return home. I bought it locally so didn't have to order from China (and it appears to have been cheaper here as well).

My plan is to set up a double tee and connect this 'precision' gauge, an analogue gauge that came with the fermenters, and one of the Xidibei sensors for testing while connected to a CO2 source with a Taprite gauge I have downstream of the regulator as it appears to be more accurate than the one on the regulator. I have a total of 4 analogue gauges and intend to have 4 Xibidei ones as well so intend to obtain quite a bit of data.

Disregard my comment above about Pressurmon (dev) reporting 2 orders of magnitude low. Following the code sequence through the serial logging, I see you had added zero correction and the reported psi pressure after the calibration steps is the corrected value and therefore hovers around zero at ambient pressure. I initially missed that and will disable the correction when doing the testing so we can determine if the error is simply a zero calibration or non-linear over the range. Hopefully it is the former. The one I bought to use as a standard just zeros on startup.

I never did get the pressuremon version in gravitymon to compile correctly with the board I am using. I've added the board as a new target per your instructions and copied over the files you mentioned from pressuremon.ui but still get errors in modules I wouldn't think pressuremon would use so I must have missed something else that needs updating. Regardless, I can wait until you test and update the code for the Lolin C3 Pico as we intend to buy them as well if they work for you.

Thanks again for your work and help with this project.

[mp-se]

Got my pcb's in the mail yesterday and im testing those now, i found that i made a misstake with my custom component (its mirrored) so i will fix that in the design. I will test the software features in the next few days to see that it works properly

[nzbrewer]

I'll be back home in less than two weeks and will test the zero offset, linearity and stability of the Xidibei sensors. Hopefully the zero set code you have already implemented will be all that is needed. As our sensors are the 0.2 MPa version, I can only test to ~30 psi.

[mp-se]

I did some changes to the PCB and software and it seams to work fine now. Will do some battery testing to the lifespan on the current setup. Once the software seams stable I will do some real testing on one of my kegs to see the stability of the pressure sensor

[nzbrewer]

Great, I'm looking forward to doing some testing as well. The additional hardware should have arrived by the time I get back home.

[nzbrewer]

How has the LiPo battery testing gone? Is the 1800 mAh size suitable? The ones available here are much lower capacity so I will revert back to a 18650 if it needs more than about an 650 - 800 mAh size.

[nzbrewer]

Back home and all but the additional tri-clamp bsp fittings have arrived. I have the one I bought previously so can start testing this week. I'll test using a slightly modified version of the pressuremon code as I just need to obtain readings from the serial output (without the zero correction) but I wouldn't mind having a look at the latest C3 Pico build with the web interface as well once you are happy.

[mp-se]

Its the same build, there is no difference in the pins. The pico does not exist in arduino 2.x yet

[nzbrewer]

Ah, I had found it here - https://github.com/espressif/arduino-esp32/blob/master/variants/lolin_c3_pico/pins_arduino.h. The differences I saw at the Lolin website were associated with the SCK/MISO connections and the inclusion of the VBAT connector:

PICO
VBAT = 3
SCK = 1
MISO = 0
MOSI = 4
SS = 5

MINI
SCK = 2
MISO = 3
MOSI = 4
SS = 5

I see VBAT isn't actually used in your circuit board and the MISO/MOSI connections are used for the second sensor so I did think the mini build would work but wanted to double check.

Thanks, I'll upload the C3 Mini build.

[mp-se]

You also need to put some solder on the led and vbat connectors on the back of the board to activate connections for the LED and battery sensor. Its not connected on the schema since its an internal connection

[mp-se]

You can try the firmware flasher which helps to set the wifi setting for the device. You can find the first beta build here; https://gravitymon.com/flasher/test.html?beta

[nzbrewer]

Thanks, the flasher does work and I can set the wifi passwords however it doesn't appear to connect after the reboot (I had the same issue previously using platformio). As a test, I installed gravitymon (using platformio) and it did work, I was able to access the webserver. (edit - never mind, I finally got it to work, may have been an issue with the router).

Sadly one of the C3 picos stopped communicating with my windows 10 machines after a few attempts the install (no longer recognised while connected to usb). Fortunately I had ordered a spare just in case one was faulty.

[nzbrewer]

Question, the XDB401 sensors came with a note that they include 4.7K pull up resisters internally on the I2C sensor and stating 'there is no need to increase the resistor'. I have been connecting the sensor directly to the two ESP32 boards I've been using to date and they have worked fine. So are the 3.3K pull up resisters connected to the SDA and SCL pins on your board needed?

[mp-se]

I missed that note, if that the case then the sensors are not really needed for this brand. There might be others that will need that. Normally 4.7k pullup is for 5V and 3.3k is more reasonable for 3.3V

I have been using the external pullups without any issues so far, but I will check the notes again.

[nzbrewer]

It wasn't in the first unit I received but it was included with each of the most recent 3 sensors. I can scan one for you in the morning. The note is a bit confusing because if we add an external pull up resister, it wouldn't increase the resistance as it would be in parallel with the internal one. I suspect the translation from Chinese wasn't perfect.

[mp-se]

If you have paralell resistors the resistance will be less, around 1.9k, they would need to be in serial in order to increase. Please send a photo of the note you got

[nzbrewer]

That is what I calculated as well. Possibly this note has been included because of issues from some buyers.

[mp-se]

I got the 302 version which had the fittings i needed. I measured one of my sensors and it has the 4.7k pullup included. But i could not find anything in the docs about that fact.... could be that they have updated their material. Good to know for the assembly instructions. I got my new pcb's yeasterday so I will try to assemble one and make some instructions as I go.

[nzbrewer]

Well, it turns out the Lolin C3 pico I2C JST connector pins are reversed from the other two ESP32 boards I was testing with. I thought I had confirmed they were the same orientation from the documentation (but in a different order) but they aren't. Pin 1 is to the right where it is on the left of the other boards. So my fault for not checking with a multi-meter before hooking up the sensor. That is why the first board quit working but fortunately, the sensor was undamaged.

All good now. My remaining issue is I haven't figured out how to add the topic/path to the MQTT push to BrewBlox so it goes to the correct location. For the iSpindel we added brewcast/history: to the start of the data string which I believe was inserted after the port (no user name or password is required). I haven't figured out how to do that from the Pressuremon MQTT configuration page. I've tried a few options but none have worked. Any suggestions? The latest version of the GravityMon docs and data format is a bit different from what you had back in June 2022.

The push test appears to be successful with the different options I tried but the data isn't available in BB.

[nzbrewer]

Understood, I was trying to just modify the mqtt predefined format you provided in the ui which is different than what we did using the older gravitymon ui. For that we had:

brewcast/history:{"key":"${mdns}","data":{"Temperature[degC]": ${temp-c},"Temperature[degF]": ${temp-f},"Battery[V]":${battery},"Tilt[deg]":${angle},"Rssi[dBm]":${rssi},"SG":${gravity-sg},"Plato":${gravity-plato}}}|

where brewcast/history was the topic_name value. I was presuming the new ui created the json document from the entries in the Data format window because of the statement below it (Format template used to create the data sent to the remote service). So one of the things I tried was changing the data point from pressuremon/${mdns}/temperature:${temp}| to brewcast/history:pressuremon/${mdns}/temperature:${temp}|. This of course is missing the {} amd quotes for the data name but I figured this was done in the background but it didn't work. Not knowing how the entries in the data format window is modified to create the json file I thought I'd just ask for guidance.

I did look at the /pressuremon2.json file using the file explorer tool and saw the entries for mqtt target, port, user and password but nothing for the push data in the required format. /mqtt-p.tpl just as the entries in the data format window.

This entry doesn't appear to work as well - brewcast/history:{"pressuremon":"${mdns}","data":{"pressure": ${pressure}}}.

[mp-se]

I havent used brewblox so I dont know what data format it would require. The example that you shared will push a json payload to the topic. You can always use MQTTExplorer to verify the data sent to mqtt so it looks ok.

Do you have any documentation on what data and format is expected ?

[nzbrewer]

Yes, if you remember, we did this for GravityMon back in June/July 2022 and that worked fine. The format I showed above is what we came up with. I have used MQTTExplorer to confirm nothing has been successfully pushed to brewcast/history from pressuremon. There is ongoing data from the Spark controller but nothing else (Tilts are handled differently with their own service).

What is interesting is I have been monitoring with the MQTT Explorer for about an hour and a new pressuremon target showed up about 15 min ago with the default data plus an entry in the brewcase.history folder with the entry I added at the end of my message above (i.e., formatted like we did with the iSpindel). So the default format in the UI works but BrewBlox can't access it (not sent to the correct topic name) but the last effort apparently has. This implies I can just put the previous format in the data format window and it might work. I'll try that now, I should be able to get this to work.

[mp-se]

According to this page (https://brewblox.netlify.app/dev/tutorials/pubscript/) the payload should probably be this:

brewcast/history:{"key": "${mdns}", "data":{"pressure": ${pressure}}}.

[nzbrewer]

Agreed, I did figure that out. The only addition is I've modified the target to brewcast/history/pressuremon as that matches the other format from the spark. It appears to be logging correctly but I haven't seen it as an option to add to the graph yet but I've seen that delay before with the Tilt. I'll let it run for a bit and will let you know.

Thanks for your help.

[nzbrewer]

I've done a bit of checking and testing. I pulled out a couple of iSpindels with the Gravitymon 1.0 firmware and configured them the same way in the UI as pressuremon. Both log to brewcast/history correctly as follows:

iSpindel = {"key":"m_iSpindel02","data":{"Temperature[degC]": 22.5,"Temperature[degF]": 72.5,"Battery[V]":4.05,"Tilt[deg]":63.31,"Rssi[dBm]":-76,"SG":1.0717,"Plato":17.3}}
pressuremon = {"key": "pressuremon1f4498", "data": {"pressure": 0.015, "pressure-unit": PSI, "battery":4.31, "interval": 900, "RSSI": -46}}

The iSpindel data is available in BrewBlox but the pressuremon data isn't. The only difference I can see is when I select the iSpindel topic in MQTT Explorer and look at the values in the right window, I get this (which is the same format as the spark data - formatted JSON?):

{
"key": "m_iSpindel02",
"data": {
"Temperature[degC]": 22.5,
"Temperature[degF]": 72.5,
"Battery[V]": 4.05,
"Tilt[deg]": 63.31,
"Rssi[dBm]": -76,
"SG": 1.0717,
"Plato": 17.3
}
}

But with the pressuremon data I get this (i.e., in the same format as what was pushed to mqtt - raw?).:

{"key": "pressuremon1f4498", "data": {"pressure": 0.016, "pressure-unit": PSI, "battery":4.32, "interval": 900, "RSSI": -46}}

Both data sources were configured in their respective UI interfaces with exactly the same mqtt format but the Explorer handles the value display differently. Does Pressuremon handle the mqtt push a bit different than what was done in Ver 1.0 of Gravitymon? Something is preventing the pressurmon data from being stored properly in the BB database where there isn't a problem with the iSpindel.

Any thoughts?

[mp-se]

You are missing the "" around the PSI value.... thats why. If you use the preview feature in pressuremon it will show a correct json in well formatted way and a faulty one as a line. Perhaps I can do some work to show this better in the editor

[nzbrewer]

Interesting because this is what is configured in the UI:

brewcast/history/pressuremon: {"key": "${mdns}", "data": {"pressure": ${pressure}, "pressure-unit": ${pressure-unit}, "battery":${battery}, "interval": ${sleep-interval}, "RSSI": ${rssi}}}|

and this is what the format preview shows:

brewcast/history/pressuremon: {"key": "pressuremon1f4498", "data": {"pressure": 0.02, "pressure-unit": PSI, "battery":4.30, "interval": 900, "RSSI": -46}}|

Is that because PSI is not a number and therefore needs quotes like the "key" result? Apologies, I didn't realise that was a requirement. My mistake.

[nzbrewer]

Well, that was it, thanks yet again Magnus. In all of my research, I hadn't seen that as a requirement but it is obvious now.

Cheers.

[mp-se]

Will add this to the next version to simplify json troubleshooting..,

[mp-se]

I finally managed to get the prototype built and the PCB v1.2 works fine but i need to do some more adjustments to it.

• Add a power off button
• Move the force config jumper
• Add the mounting holes that was lost

The version 1.3 that is in the repository has the needed changes I just need to verify that the on/off featuere works as intended.

Once this is done I will do some battery tests to see how well it works.

[nzbrewer]

Thanks. I measured 25mA average when powered up with a usb power brick. Of course this isn't a good representation because some additional circuitry is also powered (but with no battery connected). The test unit is now powered with a freshely charged 3300 mAh 18650 but I do not have a way to accurately measure the small power draw so will monitor the battery voltage from within the UI and BrewBlox.

Should also mention I do not have the DS18B20 installed (not needed in our use case).

[mp-se]

I have been doing some battery testing now with a 1800mAh battery and its still on 3.78V and it has reported more than 11500 pressure readings every 10 seconds on wifi. So I'm quite happy with the performance. On gravitymon I could get 5500 reports on bluetooth with a larger battery (2600 mAh).

If you do reporting every 15 min thats around 120 days and still counting... And you could fit a larger battery as well.

[nzbrewer]

I've also been testing the Xidibei sensor o-ring seal and I have been getting about 1 psi leakage a day (starting at 20 psi). I'm going to try some silicone lubricant to see if it seals better and, if not, a different o-ring. My setup is using a bsp parallel to tri-clamp fitting so the gasket is the seal and it didn't look like it was quite thick enough.

Regardless, I'm keen to get this on a fermenter so will be designing and printing a case that just fits the bare C3 Pico and battery for now with penetrations for the PH2.0 and USB connectors, an on/off switch, and a reset button. Let me know when you have another version of the firmware to test.

Thanks again.

[mp-se]

I will have a beta 2 release done as soon as i have had the time to test it a little.

I also had problems with leakage but i used some plummer tape to fix that and I havent had any leaks.

Just ground the EN pin and that works as a off switch for the device. I would also recommend to expose the TX/RX pins since those are used to force the device in to configuration mode.

[nzbrewer]

Thanks, yes I saw that on the circuit diagram. Presumably the TX and RX pins are momentarily shorted to go into configuration mode (e.g., with a non-latching push button switch)?

[mp-se]

Yes, it only needs to be on during startup (first few seconds). It also can be used for serial output/debugging if needed

[mp-se]

Im up to 18000 readings now which amounts to 6 months when using 15 minutes interval. So with an 800mA you should get around 2.5 months

[nzbrewer]

I've designed and printed my case and just about have it built (I'm waiting on a JST crimper to finalise the build). A couple of comments:

• I wasn't able to get the forced configuration mode to work by shorting the TX and RX pins while powering on the unit.
• The I2C connection numbers on your circuit diagram (and pcb board) are reversed from the C3 Pico circuit diagram, that is what caught me out and caused the first unit to fail. I think yours is correct as I'm used to Pin 1 being to the left when looking at the socket and you have that listed as VCC where the Wemos circuit diagram has Pin 4 as VCC (and Pin 1 as ground). The Wemos diagram has the pin labelling of the battery connector reversed as well (Pin 1 GND is to the right). If you agree, you might want to mention this in the instructions.

Other than that, all is good. Getting back into the configuration mode is a bit tricky if the battery calibration value and/or battery setting for the force configuration mode are set incorrectly but turning the battery off and powering through the USB C connector is the solution (or re-flashing the unit).

Thanks.

[nzbrewer]

Thanks, beta 4 now installed..

[mp-se]

I found one issue with the force config in the beta 4 release, that has been fixed now and I have publised that version as a release. I also got the latest pcb in the mail which worked fine it can be ordered from pcb way. Thanks for the idea and help so far.

https://www.pcbway.com/project/shareproject/Pressuremon_PCB_for_Digital_Sensors_v1_3_593fc7fa.html

[nzbrewer]

Thanks for doing such a great job with the firmware, much appreciated. I have 2 units in service at the moment and, with the exception of the force configuration feature, they have been working great. I've held off on building the other 2 until I get the pcbs as the 3D printed case will need to be modified slightly. I'll update the firmware on the existing 2 once the beers are done.

Let me know once you are happy to get the word out and I'll make a post on the BrewPi community forum (one of the support areas for BrewBlox). Elco still hasn't released the new analogue GPIO board he developed for use with RTDs and pressure sensors and this is a much better solution for pressure monitoring as no control logic is required from the readout. This is where I'll do the post:

https://community.brewpi.com/t/analog-gpio-modules-for-rtds-and-pressure-sensors-update/5627

[mp-se]

Im good with the firmware for now, i will build a few devices for my kegs and test it more. I will do a case for the pcb as soon as i have time.

Feel free to spread the word, would be good to get some more feedback.

I still have some more documentation to do.

I wrote a small blog post here with some pictures of todays build

https://gravitymon.com/blog-pressmon.html

[nzbrewer]

Done, you can view the post at the link above. Nice blog post, I've linked to it as the starting point.

Cheers.

[nzbrewer]

The link to Webflasher on the documentation Software Installation screen is incorrect. /install should be /index.

[nzbrewer]

The webflasher appears to not be working now with either Chrome or Edge on 2 different computers. There was a recent update Chrome that could be the cause. The error message is:

Error: Failed to execute 'requestPort' on 'Serial': Access to the feature "serial" is disallowed by permissions policy.

The Espressif ESP Tool is working however.

[mp-se]

Can you check what the serial port permission is for gravitymon.com?

[nzbrewer]

In Chrome on the Windows 10 machine 'Ask' is set for serial ports. Under USB JTAG/serial debug unit, only 'Insecure content' is blocked.

The C3 Pico is seen and I can select it on the port but then get the error message sent earlier. Today is the first time this has happened.

[mp-se]

Could be that a fresh board presents as jtag ?

[nzbrewer]

It may have as it did say usb/jtag when I selected it in the connect window. If that is the case, then the Win 10 versus Win 11 may be a red herring as I had flashed it with Gravitymon using the latest version of Brewflasher just to confirm the board was ok before trying your Web Flasher on the Win 11 machine. Pressuremon isn't an option yet in Brewflasher.

This is the 4th (and my last) board and the only one that did it so interesting issue. Regardless, all wired up and connected to the last sensor and working fine.

[mp-se]

Great, i will add this to brewflasher once the next version is complete

[nzbrewer]

Just tested the web flasher on a Windows 11 machine and all good. Both machines that didn't work were Win 10.

[nzbrewer]

I have an interesting observation for you. My small unitank is less than 0.5 meters from the table where the Pi4, Brewpi Spark 4 and SSR are located and the wifi access point is about 4 metres away. This is in a small shed external to the house hence the repeater. The pressuremon electronics case normally sits on the unitank near the sensor but the cable is long enough to move it to the table when I dry hop which I did yesterday. I left it there and subsequently noticed the pressure readings were randomly reading 1 - 2 psi lower (never higher) from an ~10 psi normal reading. I track the pressure in BrewBlox logging every 300 sec.

The readings have always been quite stable so I surmised that the Pi and/or Spark wifi were interfering with the C3 Pico communication. I had a quick look at your code again and only see averaging used for the pressure calibration so it doesn't appear to be something like a dropped reading impacting the average. Regardless, I moved the case back to the fermenter top and all is stable again (slowing decreasing as the beer carbonates while the hops steep at 10C).

This isn't an issue and was an easy fix but thought you might find the information useful.

[mp-se]

Strange, its digital transmissions so it should not have an impact on the readings.

[nzbrewer]

I haven't been able to duplicate the intermittent lower reading issue but am away again for a couple of months so have only had a short time to test since kegging the last batch.

Another issue I've had on my home setup is intermittent failed logging to brewblox. In configuration mode this is very rare but it is common during normal operation so presumably an issue establishing communication and posting during the short wake-up period. The one time I saw it during configuration mode, it was a -3 error but I didn't catch whether is was during establishing the connection or during the push. I did increase the push timeout to 30 sec with no luck. I haven't had time to set up serial monitoring using the tx and rx ports but can in Sept. I've been monitoring the MQTT pushes with Node-red to log when it is successful.

This doesn't seem to be an issue at the brewery where we have 3 sensors in service. Both setups use Pi 4s and there is a lot more wifi interference at the brewery. The sensor settings are the same at both locations with the exception of the push target address.

Thanks for all of your work and help.

[nzbrewer]

Agreed. Once I keg the brew, I'll try to reproduce the issue and if successful, I'll monitor what is happening in the serial console and will let you know if I see anything. Thanks.

[nzbrewer]

Hi Magnus, hope all is well. I have noticed another issue with my units.

I kept my home unit updated with the most recent firmware as you released them but the production units at the brewery were all on version 0.5.0 (possibly even on beta4) until recently when I updated them to 0.70 between batches. I had noticed the battery on the home unit draining much quicker that the brewery units and thought maybe the C3 Pico on the home unit had a fault. Now the battery drains just as quick on all of the units at the brewery as well, lasting only about a month (~ 2 - 3 times faster) with high quality 3400 mAh 18650 batteries. I believe this started with version 0.60 which was skipped on the brewery units. The log time on all units is set to 300 seconds.

I will do some testing on the home unit to see if I can quantify the battery drain for each of versions 0.50, 0.60 and 0.70.

I haven't had time to investigate the intermittent failed logging issue mentioned above but still intend to.

Thanks again for all of your work and help.

[mp-se]

Ok, i will take a look and do some tests myself to see what it could be, could be the sensors are drawing power if they are not shutdown correctly.

[nzbrewer]

Thanks. I will graph the battery level versus time for each firmware version and will increase the log rate to speed up the process. The battery will be charged using an external 18650 charger. The home unit isn't being used at the moment.