@Geoff_Blachstein@imadunatic you are right, looks like the āLevelā value is available in the first call - great.
I changed my sensor to use the RESTful Sensor - Home Assistant form instead of curl. This does allow you to easily move the authentication value entirely to your secrets file: (note the value will have to include the "Basic " in front of it as you are passing it as the value of the entire Authorization header.
Thanks for the update on this guys. Mine broke as well. The updated command line sensor works great for me. Unfortunately, I cannot seem to get the REST sensor to work. Iād prefer that method, but Iām just happy to have a working sensor again!
@mkjr75 - anything in the homeassistant logs for the rest calls? It could be unrelated (as I would expect it to impact curls calls as well) but I recently noticed an increase in timeouts for the huum api. Iāve set a longer timeout option and am monitoring how that goes.
@diffhome - nothing Iāve been able to find. I just recently turned on REST debug, but Iām not finding any entries in the log, unless Iām in the wrong area (I donāt typically do a ton of debugging, most things just work!)
I donāt think anyone has been able to figure out communicating to the device directly, just through the neevo api (which needs an account and a paid data plan etc). Local device communication would be the holy grail
Iām trying to make the adjustment to the new endpoint, but my testing via curl keeps returning a 502. Anyone else seeing this behavior? Iām pretty sure that Iām fully passing the login check, as prefixing anything to the front of that base64 string makes it fail earlier with a 401.
@tinker_ha ā Just want to thank you for the work you did here. I got an ESP32 device reading the data directly using your recipe with little fuss, and itās great to have that working as well as the API other folks shared.
I did mine with a shell script that log the info to a file when the data return the % level. Then a command line sensor that ācatā the log every 60sec. Does the job and havenāt failed me since I implemented it some time agoā¦
Iām using an ESP32 board that used to pick up status from my TM6030 via bluetooth just fine. Iāve since had to upgrade esphome and recompile the firmware due to a bad drive. Ever since, Iāve not bee able to see the tank level being broadcast. The RSSI for the TM6030 is showing up in esphome as: āSending state nan dBm with 0 decimals of accuracyā
Iāve downgraded esphome to version 8 and tried every version up through the current dev release. Nothing gets me around this issue.
I recommend you try a bluetooth scanner app on a phone to see if the tank monitor is broadcasting data correctly. This way you can rule out issues with you ESPHome config. ānRF Connectā is a good app on Android.
In the app you should see the tank monitor. The message from it will rotate through 3 different lines; one of which is the tank level. You will have to watch it for a few minutes to see it change.
It could be distance between tank monitor and your ESP32 device. The tank monitor also runs of battery which could be dying which will limit or shut off the bluetooth broadcast.
As luck would have it, I can no longer see the TM6030 using nRF Connect. I could in the past though. I was hoping it wasnāt showing up because I messed with the settings in the app.
The battery was pretty much dead, so I replaced the two cells and verified over 6 volts from the āfixedā battery. Still, no level advertisements.
At this point, I may have to just buy another one from ebay.
Thanks for the sanity check though. I was pretty much chasing my own tail for a while.
If yāall are still looking for a solution on this, this tank monitor I purchased 3 years ago has been great.
Hooks up via REST API direct. No recurring fees on the tank monitor and itās solar powered, which is great since weāre only at our place half the year.
Once you purchase the unit, they give you the credentials needed to hook up HA via REST API. Super straight forward, took me 15minutes to hook it up.