Proteus sensor api integration

Configuration
21

Hey everyone, this is a hurried post without really reading the thread.

I’m back from a horrendously busy summer and just published version 0.3 of the integration. This is an urgent release to fix the issue with the sensor being unavailable. It should be available via HACS or the Github repository.

(lots of head scratching at this one, since the exception really didn’t help enough. Took far too long for a fix of a single line)

I’m going to check the rest of the thread now and look for any changes that need to be made.

22

But i want to achieve a “cloudfree” solution. So the device should only communicate within my local network. Did someone have experience with this?

I’m very interested in running this sensor cloud-free. Cloud providers go away, hardware stays behind.

I never even tried because I assumed the traffic from the sensor to the remote server was fully encrypted MQTT, and never even bothered checking. Are you saying it’s unencrypted? In this case, routing it to Home Assistant may actually be a necessity, but it’s not a no-hassle solution.

I could easily create a branch of this integration that does ‘cloudless’. The only procedural issue I see is that it would have to be a separate integration, because HA metadata are fixed: your integration is either local, or cloud-polling, you set that up in the manifest.json file and can’t change this at runtime. If anyone knows better, please chime in!

Update on 2023-09-06:

I captured the conversation between the EcoGrog and its cloud server and I have some good news and some bad news: the good news is it uses HTTP and JSON, not HTTPS, so it would be trivial to be a man-in-the-middle and process the outgoing data ourselves.

The bad news is the JSON object contains just an opaque string that appears to be encrypted so we’re stuck for now.

And of course, even if it did send a clear-text message, the actual data it would send would probably be just a time between ping and echo, and the temperature (to help calculate the speed of sound more accurately). We’d have to convert time and temperature to distance (easy), and convert that to volume based on the shape and size of the tank.

image
image927×532 104 KB

23

I seen three differences between my own Ecofrog that talks to the e-Sensorix servers:

  1. The API URL is different.
  2. There’s an accountID field in the request.
  3. The response doesn’t come back as a JSON-encoded string, but as a JSON object that can be decoded properly. The only reason I wrote the integration was to bypass this problem with my own Ecofrog after trying to use the REST integration.

I think these can easily be added to the integration itself to make things easier. In fact, 3 is already in there—the integration only applies the string workaround if needed. If it gets a proper JSON object back from the API, it doesn’t bother.

Updated 2023-09-26: by the way, I forgot to mention. I released version 0.3 of the integration, if anyone still needs it! Get it via Github or HACS as per usual.

24

Hey @alexiosc,

Glad you are back and as I said in ma answer to the request iam happy to help where I can. My knowledge is very basic and I am far away from creating an add-on or even modify one. Because of that I have tinkerd a bit and created the above sensor.
Even if cloudfree would be a problem a modified version of your add-on with the possibility to switch between the Sensors during setup would be grate

25

Hi, the sensor uses a AES Encryption (Mode set to “ECB - electronic codebook”) the JSON String is written in HEX and encrypted via AES secret “t3k3l3k”.

I was able to decrypt the communication from the sensor to the server (in my case “mt.api.interaid.de”)

Following JSON was captured and decrypted:

First-JSON:
{'SURL':'http://mt.api.interaid.de/','PASS':'t3k3l3k','SPORT':'8483','AES':'1','SERI':'1234567','TCPR':'3','TCPT':'20','AUXALM':'0','SCTRL':'12345678','SDAYS':'MON,TUE,WED,THU,FRI,SAT,SUN,','SSTART':'7','SOFF':'57','LINT':'360','SSID':'SSIDNAME','TSER':'123456','HWID':'4','FW':'1.91','LIM1_POL':'Fill','LIM1_EN':'Disable','LIM1_HYST':'15','LIM1_THR':'1023','LIM2_POL':'Fill','LIM2_EN':'Disable','LIM2_HYST':'15','LIM2_THR':'1023','LIM3_POL':'Fill','LIM3_EN':'Disable','LIM3_HYST':'15','LIM3_THR':'1023','FIL_SRC':'15','FIL_RSSI':'15','ALM_PING':'15'}

Second-JSON:
{'SERI':'12345678','TSER':'123456','BAT':'29','WRSSI':'-61','MAC':'68:xx:xx:xx:xx:xx','WFWID':'0XX0XXXX90XX_2019XXXX','FWID':'1.91','PRID':'14','HWID':'4','ITEMP':'17','ULL':'82','SRSSI':'10','SRC':'10'}

My assumptions:
SERIAL —> Serialnumber
CREASON —> “MAN” (manual scan triggered by button on device); “SCH” (automatic, time based measure)
LRESET —> ?
PRID —> Product-ID

HWID —> Hardware-ID
FW —> Unit Firmware
SBATT —> Battery (Data * 10)
WRSSI —> Wireless RSSI
-77 and beyond - WEAK

CNUM —> ?
STYPE —> ? (Type of sensor?)
ITEMP —> PCB Temp (In Fahrenheit)
STIME —> Time of measure (GMT Time)
SRC —> ?
SRSSI —> Sonic RSSI (Signal)
ULL —> Ullage (Measurement in centimeters)

Response from API-Server was:
{"SSTART":"7","SOFF":"57","RTC":"10/04/2023 08:54"}

27

Works fine for me.
Is there an plan for a full home assistant integration?

28

Its already done: GitHub - ltspicer/heizoel24.mex: Daten vom Heizoel24 MEX auslesen und per MQTT versenden

Im using it via Cronjob from one of my Linux Machines to sent the data to MQTT and then fetch it via MQTT-Sensor in configuration.yaml.

Works very well. One of my sensor-config for example:

 - name: "MEXCurrentVolume"
   state_topic: 'MEX/Items/CurrentVolume'
   unique_id: "MEXCurrentVolume"
   state_class: "measurement"
   unit_of_measurement: "L"
   device_class: "volume_storage"
   force_update: true
29

Hi,
as i am far byond knowing how to create a integration i asked @alexiosc if he can modiyfi his one to be “selective” Maybe there will in the fuuture.
Please also keep in mind to set the “scan_interval” higher as i mentioned in an other post as you will request to many API-Cals otherwise

30

This only works with the ones from Heizoel24 not for the one from Protheus / Eco Frog
All 3 devices are nearly the same but they require different Services and APIs
The Integration from @alexiosc is for the Devices from E-Sensorix.
My “Yaml” integration is for the ones from protheus-sensor.de

31

Hello

I have been in contact with Michael Krause, Managing Director of Inno-tec (Proteus-Sensors).
It doesn’t make sense to request data more than once a day anyway, as the four measured values from the previous day are only transmitted the next day in the morning.