Bluetooth propane tank monitor: ESPhome, Otodata, Nee-vo, Ferrellgas, BLE

Perfect! Thanks for posting the solution.

I just replaced the old CURL command with the new address and authentication mode and it sprang back to life.

Replace XXX with your base64 value of course but this is working for me:

command_line:
  - sensor:
      command: 'curl -H "Authorization:Basic XXX" https://ws.otodatanetwork.com/neevoapp/v1/DataService.svc/GetAllDisplayPropaneDevices --header Content-Type:application/json'
      name: "Propane Tank"
      unique_id: propane_tank
      value_template: "{{ value_json[0].Level }}"
      scan_interval: 86400

@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.

sensor:
  - platform: rest
    name: Propane Tank
    resource: https://ws.otodatanetwork.com/neevoapp/v1/DataService.svc/GetAllDisplayPropaneDevices
    headers:
      Authorization: !secret neevo_auth
    value_template: "{{ value_json[0].Level }}"

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’m trying to set this up for my house.

I also have a TM6030

I can see the iBeacon in nrf Connect for Mobile.

I tried to sign into the Nee-Vo account, but got a message that the device was already registered (probably by the previous owners)

I’m totally new to ESP and have hit a bit of a wall.

I got my ESP32 set up and in ESPHome, but can’t figure out how to get information from the beacon.

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 :slight_smile:

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.

rick@merlin ~]$ curl -v -v --http1.1 -H "Authorization: Basic VALUE_REDACTED" "https://ws.otodatanetwork.com/neevoapp/v1/DataService.svc/GetAllDisplayPropaneDevices"
*   Trying 3.138.74.96:443...
* Connected to ws.otodatanetwork.com (3.138.74.96) port 443 (#0)
* ALPN: offers http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=*.otodatanetwork.com
*  start date: Jan 15 17:51:03 2024 GMT
*  expire date: Feb 15 17:51:02 2025 GMT
*  subjectAltName: host "ws.otodatanetwork.com" matched cert's "*.otodatanetwork.com"
*  issuer: C=BE; O=GlobalSign nv-sa; CN=AlphaSSL CA - SHA256 - G4
*  SSL certificate verify ok.
* using HTTP/1.1
> GET /neevoapp/v1/DataService.svc/GetAllDisplayPropaneDevices HTTP/1.1
> Host: ws.otodatanetwork.com
> User-Agent: curl/7.88.1
> Accept: */*
> Authorization: Basic VALUE_REDACTED
> 
< HTTP/1.1 502 Bad Gateway
< Server: nginx/1.18.0 (Ubuntu)
< Date: Wed, 23 Oct 2024 04:38:00 GMT
< Content-Type: text/html
< Content-Length: 166
< Connection: keep-alive
< 
<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx/1.18.0 (Ubuntu)</center>
</body>
</html>
* Connection #0 to host ws.otodatanetwork.com left intact

I am not able to reproduce this. Switching in my VALUE_REDACTED value in the command gets a 200 response.

Do things work if you visit https://ws.otodatanetwork.com/neevoapp/v1/DataService.svc/GetAllDisplayPropaneDevices in a browser and enter your username and password?

@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.

1 Like

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…