question

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

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.

One of these connected to VE.CAN

https://www.maretron.com/products/tlm100-tank-level-monitor-40-depth/

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