This site is now in read-only archive mode. Please move all discussion, and create a new account at the new Victron Community site.
I have one of those radio linked floating sensors that gives a bar graph display of the level, but it's not very accurate, I would like an accurate display of my heating oil on the Cerbo, but after an hour of searching and reading all I find is water and LPG tank sensors?
Tap Tap! Hellooooo is anyone there?
Is there any reason a water or LPG level sensor wouldn't work for you? One of the Mopeka bluetooth sensors for example?
Hi Jeremy, Don't think I could use a water sensor in heating Oil it might attack the components, they call it Oil, but it's not really much different to jet aviation fuel. I'm not sure how the LPG sensors work, I know they are detecting it in it's liquid form, but surely it's not inside the tank? you would let all the gas out fitting it? I will have a look at them. Bob
The Mopkea sensors are ultrasonic and attach to the outside of the tank. It really shouldn’t matter what kind of liquid it is, as long as the sensor can see through the tank properly.
Hi @wedgehog
I have an Apollo oil sensor they use radio signals to send data from ultrasonic sensor on top of heating oil tank to a small plug/display that's inside the house. I capture this radio frequency using this:
GitHub - merbanan/rtl_433: Program to decode radio transmissions from devices on the ISM bands (and other frequencies)
Which is running a separate raspberry pi and then forward it to gx device via MQTT.
Only thing i needed to do on GX device was use the dummy script to make a "virtual tank"
velib_python/dbusdummyservice.py at master · victronenergy/velib_python · GitHub
I imagine you could technically install rtl_433 on the venus os device itself. You'll likely also need to install the drivers for the SDR.
No worries,
I think there's some arduino devices that folk have made to forward on the RTL_433 to mqtt. Using openMQTT I'm not too familiar with making/configuring arduino like devices so just went with raspberry pi zero and just used a script for forward that rtl_433 received onto gx device. (if you go this route double check the oil sensor you have is in the arduino version of the program)
There's a list of sensors on there the rtl_433 site that it works with but where i am (UK) almost all the oil sensors I've seen are Apollo (even if they're not the protocol is identical so works as though it was)
GitHub - NorthernMan54/rtl_433_ESP: Trial port of the rtl_433 Library for use with OpenMQTTGateway on a ESP32 and a CC1101 Transceiver
Hi Matt, Thank you, The youtube I told you I found, it's a chap called Matt is it you?he shows us this
https://docs.openmqttgateway.com/upload/web-install.html
It is a sytem called Open MQTTgateway and you can upload firmware directly to your ESP32 from the page. I can do that no problem, I can edit the ESP32 script as well provided someon shows me what to edit and what to put.
What I don't understand yet is this, the ESP32 also has standard wireless, so if it is receiving the sensor on 433 can it not directly send the MQTT info to the Cerbo-GX via the wireless network, is any other device or receiver needed? . Bob
Nah that's definitely not me. These folks are far smarter than me!!
I imagine it'll depend what ESP32 board you've got. However you're right it the chip supports wifi/ethernet. And i believe what you're describing is what OpenMQTT does. It forwards data it receives from sensors onto MQTT server. So you can forward the data onto gx MQTT server. The only bit I'm unsure of is how you format the data from what's received from the sensor into a format the GX device wants. That's the bit you'd need to edit in the ESP32 code i think. I'll have a look but not something I've done before.
Mine I use a raspi and do that formatting in python
EDIT: seems like a pretty active community so imagine someone could tell you if formatting exists.
If not then they should be able to tell you where is best to edit the code to get it to work for your needs. I did have a quick look but my c++ isn't the best.
The oil sensor will give you depth. You then need to calculate the values victron needs from that somewhere in c++.
The maths is:
Here's the equivalent in python:
def vol(depth,radius,length,tankVol):
m = depth - radius
theta = 2 * math.acos(m/radius)
inner = theta - math.sin(theta)
return (0.5*radius*radius* inner * length)
if depth == tankDepth/2:
Level = 0.5
elif depth > tankDepth/2:
print("under half")
Level = vol(depth,tankDepth/2,tankLength,tankCapacity*1000)/(tankCapacity *1000)
elif depth < tankDepth/2:
print("over half")
Level = 1- ((tankCapacity*1000) - (vol(depth,tankDepth/2,tankLength,tankCapacity*1000)))/(tankCapacity*1000)
Remaining = tankCapacity * Level
See what the community says about where to add that maths.
I'm very much c++ beginner, but i would say you add an if statement in around line 260 to check if the contents of the RTL_433 sensor is your sensor by checking the id (as this will be static). Then if it is the id ie your oil sensor. Then instead of passing all the json data to the mqtt topic you just pass the values you need like level/capacity (after doing the above maths ofc).
How do I forward the MTQQ from a Lilygo 433 to a Victron Cerbo-gx
Hi @wedgehog
Here's how you setup a virtual tank. You can then write the litres values to this. (If you can edit the output received from ultrasonic oil sensor to just send litres to mqtt topic then you wont need any other devices).
Victron has a more detailed guide here, which explains how you can make the below more robust, and get the drivers to persist over updates etc, however the below works.
So you start with Victrons custom driver but edit it to make it create a tank
#!/usr/bin/env python3
"""
A class to put a simple service on the dbus, according to victron standards, with constantly updating
paths. See example usage below. It is used to generate dummy data for other processes that rely on the
dbus. See files in dbus_vebus_to_pvinverter/test and dbus_vrm/test for other usage examples.
To change a value while testing, without stopping your dummy script and changing its initial value, write
to the dummy data via the dbus. See example.
https://github.com/victronenergy/dbus_vebus_to_pvinverter/tree/master/test
"""
from gi.repository import GLib
import platform
import argparse
import logging
import sys
import os
# our own packages
sys.path.insert(1, os.path.join(os.path.dirname(__file__), '/opt/victronenergy/dbus-systemcalc-py/ext/velib_python'))
from vedbus import VeDbusService
class DbusDummyService(object):
def __init__(self, servicename, deviceinstance, paths, productname='Thunderstorm Tank', connection='Dummy service'):
self._dbusservice = VeDbusService(servicename)
self._paths = paths
logging.debug("%s /DeviceInstance = %d" % (servicename, deviceinstance))
# Create the management objects, as specified in the ccgx dbus-api document
self._dbusservice.add_path('/Mgmt/ProcessName', __file__)
self._dbusservice.add_path('/Mgmt/ProcessVersion', 'Unkown version, and running on Python ' + platform.python_version())
self._dbusservice.add_path('/Mgmt/Connection', connection)
# Create the mandatory objects
self._dbusservice.add_path('/DeviceInstance', deviceinstance)
self._dbusservice.add_path('/ProductId', 0)
self._dbusservice.add_path('/ProductName', productname)
self._dbusservice.add_path('/FirmwareVersion', 0)
self._dbusservice.add_path('/HardwareVersion', 0)
self._dbusservice.add_path('/Connected', 1)
for path, settings in self._paths.items():
self._dbusservice.add_path(
path, settings['initial'], writeable=True, onchangecallback=self._handlechangedvalue)
GLib.timeout_add(1000, self._update)
def _update(self):
with self._dbusservice as s:
for path, settings in self._paths.items():
if 'update' in settings:
update = settings['update']
if callable(update):
s[path] = update(path, s[path])
else:
s[path] += update
logging.debug("%s: %s" % (path, s[path]))
return True
def _handlechangedvalue(self, path, value):
logging.debug("someone else updated %s to %s" % (path, value))
return True # accept the change
# === All code below is to simply run it from the commandline for debugging purposes ===
# It will created a dbus service called com.victronenergy.pvinverter.output.
# To try this on commandline, start this program in one terminal, and try these commands
# from another terminal:
# dbus com.victronenergy.pvinverter.output
# dbus com.victronenergy.pvinverter.output /Ac/Energy/Forward GetValue
# dbus com.victronenergy.pvinverter.output /Ac/Energy/Forward SetValue %20
#
# Above examples use this dbus client: http://code.google.com/p/dbus-tools/wiki/DBusCli
# See their manual to explain the % in %20
def main():
logging.basicConfig(level=logging.DEBUG)
from dbus.mainloop.glib import DBusGMainLoop
# Have a mainloop, so we can send/receive asynchronous calls to and from dbus
DBusGMainLoop(set_as_default=True)
pvac_output = DbusDummyService(
servicename='com.victronenergy.tank.ttyO1',
deviceinstance=0,
paths={
'/Capacity': {'initial': 1.235},
'/Level': {'initial': 0},
'/Status': {'initial': 0},
'/Remaining': {'initial': 0},
'/FluidType': {'initial': 4},
'/Standard': {'initial': 2}
})
logging.info('Connected to dbus, and switching over to GLib.MainLoop() (= event based)')
mainloop = GLib.MainLoop()
mainloop.run()
if __name__ == "__main__":
main()
Edit initial values. Can also edit tty01.
This file should be saved in data folder. I make another folder to store it all in called virtTank
/data/virtTank/virtualTankTTY01.py
You also need to create a folder
/data/virtTank/service
inside this folder you will make a file named run
run will contain:
#!/bin/sh python /data/virtTank/virtualTankTTY01.py
Then you need to create a symlink in /service to the folder /data/virtTank/service
This would be done using command:
ln -s /data/virtTank/service/ /service/virtTank/
You should then see a folder be created in /data/virtTank/service/ called supervise and a tank appear in dbus-spy (and on VRM).
There are more details on victron's github about making the above more robust and to persist over updates as well as storing the drivers in /opt/victronenergy however for a simple setup the /data folder is fine. If you're adding more complex programs keeping things neat and stored in correct folders will matter more. Similarly if persisting over updates is critical then read further here:
https://github.com/victronenergy/venus/wiki/howto-add-a-driver-to-Venus
I'm not too bothered with my setup breaking over updates as redoing the above is quick enough once you've done it once.
Now the virtual tank is in venus os/GX device. However you need to get data values into it.
I do this via MQTT.
The topic you'll need to send the remaining and level to are:
Remaining: /W/{VRMID}/tank/{deviceID}/Remaining
Level: /W/{VRMID}/tank/{deviceID}/Level
Where VRMID you can find in settings->VRM Online Portal
of your GX device
And device ID you can either find in GX device list or VRM device list And i believe it's VRM instance ID. If you just copy the above scripts it will be 0.
Hope this helps. Of course you'll need to somehow format the output of the oilsensor that's read by the arduino into level and remaining before sending into victron's mqtt topics that I've noted above.
@wedgehog This all looks very complicated..
Can't you just use a normal 0-190 Ohm pressure sender and manually set the range in the Cerbo.
Something like this can be mounted on a tee on the tank outlet pipe:
https://wema.co.uk/products/pressure-sender
Loads of similar on Amazon etc.
Hi @wedgehog
What file did you use for your lilygo. I've got my custom code running (it's picking up neighbors weather station and a few other devices around the area but not the oil sensor that it's literally right next to).
At first i thought it was because i was compiling with OOK instead of FSK. However I've done that now and still doesnt seem to work (magnet trick doesnt work on mine so i'm having to test once per hour).
I noticed the FSK prebuilt file uses 915mhz not 433. Was curious which file you used.
@matt1309 Hi mate, Upload, upload from the web, Lillgo_rtl_433-fsk. Oh! and don't forget, your tank may only send info a few times a day unless you put a magnet by the internal switch on the sender unit. You can look that information up on the web site for your model of sonic sender
Turned out I needed to clear flash.
Data's received now. Just need to check the code that extracts the data and converts depth to capacity etc then should be done.
(unfortunately magnet trick doesn't seem to work on mine) mine seems to be some obscure model that just uses same data structure but is branded differently
