Add support for Oil-SonicSmart

[zuckschwerdt]

See #2244

Open questions:

• How long does the pairing/test mode last? (the captures are only 30 secs).
• What is the stated range of depth readings? Esp. is the maximum over 255?
• What triggered the pairing/test mode? A magent like for other sensors?
• Does the unit ID change when you rebind by holding a magnet to the sensor for long enough?
• Can you simulate alarms like Leak/theft alarm?
• Confirm the binding counter, i.e. something that's only active in test mode.
• I.e. does the counter stop when the magnet is removed?
• Is there an error flag for "no reading"?

[StarMonkey1]

See #2244

Open questions:

• How long does the pairing/test mode last? (the captures are only 30 secs).
  Seems to be around 5 minutes (https://github.com/merbanan/rtl_433/blob/master/src/devices/oil_standard.c is a similar model and states 11 minutes)
• What is the stated range of depth readings? Esp. is the maximum over 255?
  Unknown but maximum shown in the manual is 300cm, minimum 12cm, (https://www.rpm-fuels.co.uk/system/storage/download/Apollo-Smart-Product-Manual.pdf) https://github.com/merbanan/rtl_433/blob/master/src/devices/oil_standard.c says 305cm and 3cm
• What triggered the pairing/test mode? A magnet like for other sensors?
  Magnet on a black dot on the side of the unit.
• Does the unit ID change when you rebind by holding a magnet to the sensor for long enough?
  Unknown, but the smart receiver doesn't need repairing after the test mode.
• Can you simulate alarms like Leak/theft alarm?
  Possibly, its detected by speed of change of level. Without a decoder I've not been able to monitor the transmissions longer term so not sure how many times per hour/day etc. a reading is taken to then simulate a leak/theft.
• Confirm the binding counter, i.e. something that's only active in test mode.
• I.e. does the counter stop when the magnet is removed?
  Magnet is only placed on the sensor for a few seconds to activate test mode and then removed.
• Is there an error flag for "no reading"?
  Again unsure, there are several errors referred to in the manual but it's not clear on which sensor readings trigger them.

I'll run the new code and monitor.

[zuckschwerdt]

Thanks! Over all very much like the "Standard" model/protocol then.
If you monitor the data over the next weeks, note that "flags" and "alarm" are just two raw bytes with no meaning so far. Perhaps you can on occasion spot pattern there?

[StarMonkey1]

Thanks! Over all very much like the "Standard" model/protocol then. If you monitor the data over the next weeks, note that "flags" and "alarm" are just two raw bytes with no meaning so far. Perhaps you can on occasion spot pattern there?

I think the sensor is pretty much the same as the classic Apollo sensor, it might just be the receiver that's different. The Apollo kit is very badly documented so it's difficult to know.

Should I build this branch by source and run it that way or is there a branch release? Eventually I want to run this within the Home Assistant RTL add-on but can run within an Ubuntu VM for the time being for testing.

[zuckschwerdt]

In terms of features very much the same, but there is more "room" in the data fields, so e.g. flags might map differently.

If you running docker is more convenient then use the branch feat-oilsmart (instead of master).

[StarMonkey1]

Yup, I've built from the feat-oilsmart branch and I've left it running in an Ubuntu VM (rather than docker). Fingers crossed no hardware crashes overnight. I think the oil monitor only sends updates very infrequently so they're difficult to catch!

What were the specific flags in the classic monitor? I'll see if I can figure out from functions in the smart display what any additional flags might be and how I could trigger/test them.

[zuckschwerdt]

see if I can figure out from functions in the smart display what any additional flags might be and how I could trigger/test them.

That would be great! The knowledge we have is summarized here:

rtl_433/src/devices/oil_standard.c

Lines 60 to 84 in 46491d3

	// The unit ID changes when you rebind by holding a magnet to the
	// sensor for long enough.
	unit_id = (b[0] << 8) | b[1];
	// 0x01: Rebinding (magnet held to sensor)
	// 0x02: High-bit for depth
	// 0x04: (always zero?)
	// 0x08: Leak/theft alarm
	// 0x10: (unknown toggle)
	// 0x20: (unknown toggle)
	// 0x40: (unknown toggle)
	// 0x80: (always zero?)
	flags = b[2] & ~0x0A;
	alarm = (b[2] & 0x08) >> 3;
	if (flags & 1)
	// When binding, the countdown counts up from 0x40 to 0x4a
	// (as long as you hold the magnet to it for long enough)
	// before the device ID changes. The receiver unit needs
	// to receive this *strongly* in order to change its
	// allegiance.
	binding_countdown = b[3];
	else
	// A depth reading of zero indicates no reading.
	depth = ((b[2] & 0x02) << 7) | b[3];

[StarMonkey1]

Ok, so I left it collecting data overnight and while it has now identified the data and rtl_433 recognises it the data contained within must be being decoded incorrectly. rtl_433 shows:

model: oil-ultrasonic
id: bd01
flags: 17
alarm: 0c
binding_countdown: 50
depth_cm: 0

The alarm value appears to change variously to:
0e
10
12

Readings appear to be every half and hour or so.

[zuckschwerdt]

Thanks. I've updated the branch with those hints and disabled the binding/depth switch (same value anyway)

[StarMonkey1]

I'm now getting depth readings.

model: oil-ultrasonic
id: bd01
flags: 17
alarm: 36
binding_countdown: 0
depth_cm: 51

I've no idea if this depth reading is correct at the moment, I'll have to pull it out of the tank again and measure against a known distance.

[StarMonkey1]

We've used oil since yesterdays comment (smart display shows less in litres) but the depth_cm is still reading 51 so I don't think it's decoding the correct part of the data. I'll attempt to get the sensor out today to see if that makes a difference.

[zuckschwerdt]

I'll attempt to get the sensor out today to see if that makes a difference.

Can you simply compare the reading you got before and after the change?

We only need/can compare these three flags: 17 alarm: 36 depth_cm: 51

The first two bytes will have a bit (MSB) for >255 cm, and may also have bit(s) for sub-cm reading. 2 bits for 1/4 cm readings maybe.

[StarMonkey1]

I'll attempt to get the sensor out today to see if that makes a difference.

Can you simply compare the reading you got before and after the change?

We only need/can compare these three flags: 17 alarm: 36 depth_cm: 51

The first two bytes will have a bit (MSB) for >255 cm, and may also have bit(s) for sub-cm reading. 2 bits for 1/4 cm readings maybe.

Sorry, I'm not sure I understand what you mean. Which readings do you think I should compare?

[zuckschwerdt]

Yesterday it was flags: 17 alarm: 36 depth_cm: 51 what is it today? flags: xx alarm: yy depth_cm: 51

[StarMonkey1]

191222_capture.csv

This is the last ~24hrs

[StarMonkey1]

depth_cm: 52

flags are 17 and alarm 30 or 32.

Anything else I should be doing/testing at the moment?

[zuckschwerdt]

We can copy your table to this BitBench.

The bits just before the "cm" field seem to roughly increase, e.g.
2022-12-19 17:32:57 to 2022-12-19 18:07:07
and 2022-12-19 19:15:27 to 2022-12-19 19:49:37
but then much jitter and suddenly 51cm jumps to 52cm. I would have expected the field to be close to 1111 before that, not 1001.
Not clear how to confirm anything. Likely best to just watch for a longer period and try to match up with the display unit?

[StarMonkey1]

This is looking good, I've got data since my last post and everything seems pretty stable.
To bottom out the depth I stuck a pole to the base of the tank and measured from top of tank to oil level, the reading said 73cm and my pole measured at 75cm (and there was a lot of roughness with my measurements). I think this confirms the depth reading is correct.

The flags data seems to be very stable, the alarm data seems to regularly change but I'm not sure what that's related to.

[zuckschwerdt]

OK, thanks. I guess "flags" then includes alarm and "alarm" is really a counter or temperature or such.
Maybe I'll just add a note and we'll leave it with depth only.

[StarMonkey1]

I guess if it merges and more people come across it we may come across other events. We've not had a refill yet for example, I guess those things can always be added as time goes on.

[zuckschwerdt]

Merging this now. If you ever get the chance to observe a distance going above 255 cm then please post the output (e.g at 250, 255, 256, 260). Also if you detect a pattern in the "unknown" fields :)