I’m trying to flash a pellet tracker with ESPHome. The goal is to measure the fill level of the pellet storage and bring the readings into Home Assistant.
Right now, the tracker only exposes data through the vendor app, and there’s no way to trigger a manual scan remotely. You have to press the physical button on the device, which becomes impossible once the pellet storage is full.
The tracker’s hardware uses an ESP32-WROOM-32D plus a Quectel BC95-G module.
You want to flash it with esphome and then? What’s you plan?
You mention Quectel BC95-G which is irrelevant for your approach, the sensor is XM122. Can you make it work on esphome?
It’s pretty simple to simulate button presses if that’s all you need.
Ideally I would like to get the same functionality. So my plan would be that ESPHome is able to do the scan and collect the current level of the storage.
I am not 100% sure, how it detects the volume of the storage.
Would it be easier to build a device from scratch?
Great photos. Clear and show detail needed for reverse engineering.
I did a quick Google search and found this:
Wow, this device is full of goodies!
The Quectel BC95-G gives you long distance NB-IOT functionality.
The XM122 is a radar reference design that has a low power Nordic nRF52840 chip with support for Bluetooth® 5, Bluetooth mesh, Thread, Zigbee®, 802.15.4, and ANT, and comes with a SDK. Did somebody mention the possibility of future Matter support?
The alkaline batteries are the giveaway - the power hungry ESP32 must be getting kept in sleep mode or powered off until the button is pressed.
Lots of room to explore there. The ESP32 may be superfluous to your needs, just being used as glue and a bit of data manipulation for the other chips. It may just be getting used as a serial to WiFi UART, and you should be able to load ESPHome, Tasmota or a MQTT type subroutines from an Arduino IDF on it to get your data into HomeAssistant. Check as that functionality may already exist in the current unit. Connect to your LAN, scan the IP range and look for any response on any IP address you strike. Plain text? JSON? MQTT? You never know.
ESPHome has added NRF52 series support recently. Looks like there are lots of test pins on the PCB Board which may match up with the reference design if you are lucky, otherwise careful examination of the tracks from the relevant processor chip pins will lead to clues.
If you are willing to trash the existing firmware and abandon existing functionality, the sky is the limit.
Not sure if the I2C from the radar unit connects to the NRF or ESP chip. There is I2C scanner code for both chips you can temporarily load to see what data is being returned as part of your investigative efforts.
As for functionality, I suspect the radar detects distance to the top of the pellets and returns a reading using I2C protocol. Fire up the radar and see what values are returned when it is empty, full, and other expected percentages between. The values may not be linear so experiment.
Not sure how often you want to check your pellet levels. This may be determined by battery life. If you want continuous polling then consider alternative power options such as mains or solar with rechargeable batteries.
The other option is to keep everything as is, and just add another chip to press the button remotely from HomeAssistant when you need a reading. Follow the PCB trace from the push button and see what chip it goes to and whether it has pullup resistors etc. The button may also be acting as a power switch, in which case a MOSFET or relay interface from something like a ESP01 module may suffice.
Have you asked the vendor if they have an API or have considered SCADA or other integrations? They may already have that as part of a firmware change - the hardware is offering that functionality possibilities for sure. You could use something like WireShark to intercept traffic to your existing app on your phone and see if you can decode it from there.
Your serial adapter should support 3.3volts as well as 5volts - don’t fry those chips!
The chips are all on the PCB board, with a tested and working layout, and built-in trace antennas. The relevant pins needed look to be taken out to test points. No point in making a new PCB board.
Download the data sheets and do some careful tracing will quickly identify what each test point is for. I would guess the solid pads on the right hand side are for quick flashing during production and that would be the ones I would follow first.
Unfortunately you didn’t mention the make and model of the entire model, so couldn’t search to see if somebody else had already gone down this track. Is it this one? https://www.pellettracker.de/
I’m guessing for a device that costs so much, just adding all the chips on the board and picking the eyes out of the best parts of their functionality may be an overall cheaper solution than having to stock and support multiple models for each communications protocol - bundle them all in! The software is the secret sauce, and the one that might be the easiest to reverse engineer.
Approaching the vendor might make them realise their is a greater market for their product if they add an API or document their protocols for third party integration. Try that first, before you start wielding the soldering iron.
Back to basics. You could adapt the code used for many simple SR04 type ultrasonic distance sensor projects to read the values from the radar unit via the I2S pins. The radar unit looks far more robust and probably more accurate than the SR04.
This is an interesting project. Your possibility of achieving your goal of HomeAssistant integration is very high. If the vendor lets this opportunity slip away to roll out their own solution you can use, they are ignoring a broad market.
The button is only required if you need to connect the device directly to the app. It establishes a connection between your phone (the app) and the tracker.
If I understand what you are saying correctly, is that I can flash tasmota subroutines onto the esp32 next to the currently present routines on their?
I would need to figure out how to connect to the ESP32 first to see what kind of data is being processed. Definitely doesn’t sound too easy, haha.
Thank you so much for taking the time to research so much!
I actually asked them if they have an API but they said they only offer a csv export via the app… but I like the idea with Wireshark! I haven’t been able to figure out, how to connect the pallet tracker to a WiFi since it always uses the cellular to transmit the data.
I checked the documentation again and the pellet storage might be too far away from the WiFi. I will try connecting to WiFi network tomorrow and see if I can find out, what kind of data is being transmitted.
Midnight your time and your phone needs charging. Let your subconscious do its’ thing while you are sleeping.
Wondering how it connects? Does it connect via WiFi, or cell, or BlueTooth? Easy to find out - turn off all on your phone and then see which one it connects with. Maybe turn off cell to force it to use WiFi to connect upstream, and then you can inspect the traffic via WireShark. I’m guessing it is 2.4Ghz WiFi after the initial setup, and it is using your router which you should be able to check to see what IP address is being used and WireShark that. If the transmission is encrypted, then that just adds another layer to your journey of discovery.
Unfortunately the source code on the ESP32 is not available to you, otherwise your questions would be different. You could try a ESP flash backup before you start experimenting, however you will not be able to run your custom ‘supplementary’ code alongside theirs - you will have to overwrite. .
I’m not up to speed with Android decompilers, but that would be one way of reverse engineering their code. The fact that they can export to csv would indicate they may be using a database to store information. Look for a folder on your phone that may contain clues also.
I see the app vendor also offers a serial BLE app in the app store to ‘communicate with IoT devices’. Mmmmm!!! Wonder how interesting that would be to check out? Strongly suggest that will give you many hours of fun, filling your hopper, emptying it, and seeing how the transmission traffic changes.
Whether it is the Nordic chip or the ESP that is doing the data transmission, or both, one at setup and the other in production is also something you may need to fathom.
So the button initiates BlueTooth or BLE pairing as part of the setup process. Good - a spare pin being used for a level shift, rather than switching voltage…
The latest app update from last month offers “OTAv2” as the reason for the update, raising the possibility of not having to do much if you can cobble together a firmware update rather than connect your USB serial adapter.
Frustratingly, German is not one of my languages and due to the vendor website being full of graphics, Google translate is not helping much. I see however that the device is linked to their re-ordering system, so they may not want to release their grip on this locked-in cash flow.
All the more reason to rise to this challenge!
I’d try software traffic interception first, possible decoding, and them consider customising the hardware, at which time you will probably lose the pellet re-order functionality.
You seem well on your way to reverse engineering this.
The XM122 is a radar reference design, so go back and see if the reference design software has also been closely followed.
Encryption may be basic too, or your possible alternative software could adopt its own. MITM may be a way to check what data flows across the internet. At least you know they are using MQTT, so if they wanted to develop an addon to HomeAssistant, it would be fairly easy to integrate, either direct from their device or via an API gateway to their website.
The Nordic SDK tools and examples may yield some clues too. Check the Espressif one too.
Briefly looking at just the pictures in the German instructions (I didn’t run the pdf files through a translator) shows a lot of real life scenarios have been considered. Not too sure how stable the firmware has been, how much effort the vendor puts into maintaining it, but if they are following along with this thread, either nervously seeing their product pulled apart so publicly, or excitedly seeing the potential market grow is now something out of their hands. The horse has bolted. Releasing an API or offering the functionality you require may be one way to retain control for them. They may offer it for free as an update (preferrable) or charge a small ongoing fee for data access (in which case you will most likely continue with this project).
Curious if the product is sold outside Germany, and if they have future plans to do so, including translation of their software and instructions.
Is the device sending similar data via BlueTooth as well as WiFi? Is the Nordic nRF52840 being used for BlueTooth, and the ESP32 for Wifi, and the Quectel BC95-G for NB-IOT, simultaneously?
Is the I2S bus being monitored by all three chips, or just one and the processed data is then shared amongst the others? Hint: follow the PCB tracks back from the XM122 connector. Are the three chips UARTs connected as well? Have you had a listen on the UART pins with your serial adapter - the chances of data flow being encrypted at that level may be low. Check that against the nRf UART data being transmitted.
Could you go back to basics, piggybacking off the I2C bus raw data, or UART traffic between the chips, and just send that from another chip using ESPHome, and leaving all the existing hardware and firmware to continue on its merry way? Yes, you might want to use another nRF52840 chip for power consumption reasons rather than an ESP32, and wire it in with the existing alkaline batteries which you will need to replace more often, but HomeAssistant should be able to monitor the level and warn you accordingly.
How often you poll the pellet level will determine how fast your batteries go down. Be cautious not to poll too often. How often do you use pellets? Is this automated too, and can be used as a trigger for the level to be read, or do you need a presence detector to see when your hopper is accessed to trigger a new reading? No point in getting readings if the level isn’t changing.
The phone app may store the data in a database that may be accessible from another app. Have a look around on the files on your phone. Exporting the data in csv format and sending it to HomeAssistant may be another option, something the vendor could probably also easily implement themselves as a future app update. Maybe they are using something like AWS IoT, and the access to the data would be easy to implement?
There is a lot of technology building blocks being strung together to make this all work, on a software as well as hardware level. Where to exfiltrate the data elegantly is your challenge.
I just wanted to give a quick update. I have to put the project on hold for a couple of months, because I had to refill the pellet storage and that means the tracker is back in the tank. In the meantime I will see what I can learn about the tracker and if there are other ways to extract the data from the tracker.
I will keep you updated if I have any news and when I have the tracker out of the storage.
Thank you guys for your help this far. I am sure I or we will find a solution for this device!
