I have a VenusOS on board running on a raspberryPi 4B for 2 years now and I have tweaked a lot with different interfaces and sensors. It always boils down to run new serial connection wires across the boat to all the controllers, Victron devices, 3rd party devices etc. (I2C, 1-wire, RS485, GPIO connections...)
I plan some better integration and I think about using distributed IoT WiFi microcontrollers like the ESP32, ESP8266 etc. next to the sensors, and using a second WiFi radio dongle on the Pi configured as Hotspot dedicated to the sensor network. MQTT comes in mind as lightweight protocol (but victron uses it already for other purposes) node red would be too bloated for the tiny controllers I think.
The idea is to define a message structure / protocol on the controllers and write a stub service on the Venus to receive and process this messages, discover, create and maintain DBUS services for the different type sensors that appear on the fly, store the settings locally and allow editing them, send the updates back to the microcontrollers and sensors if necessary and do house keeping when they disappear. In the first step I am thinking about some ADC like ADS1115 /current and voltage sensors like the INA3221, INA226 or INA219 with respective 300A shunts for monitoring Alternators, Start batteries and other 3rd party chargers without data interfaces (wind generators etc), current loop sensors like hydrostatic tank sensors, impulse counters from flow sensors or temperature / moisture/humidity/pressure sensors. An example would be a controller in the engine room, collecting data from 3 shunts (start battery, alternator, charge output to house battery after the battery separation diodes), 3 temp sensors (engine compartment, alternator, engine cooling water), 2 flow sensors (fuel lines differential impulses). The hub would calculate the SOC, the power for the 3 branches, the voltages, the fuel usage in l/h, would monitor the temperatures and raise alarms, it could even control the alternator field to prevent overheating or switch charging of the house battery off by relais/solenoids.
Another controller could monitor the fresh water tanks, black water tank, bilge, environmental data in the cabin like humidity, temperature...
Realising this in the current setup would require a dedicated cable for each of this sensors back to the "cerbo", a lot of USB interfaces, hubs and hassle and put a lot of load on the single unit, with the controllers a lot of the measuring, gathering and aggregating could be offloaded to the nodes.
I think about using the existing constrains for registering services /Mgmt/ProcessName, ... /Mgmt/Connection, /DeviceInstance, /Connected...to be published by the IoT sensor in a structure on connect and the stub would then create the according services in Venus on the fly, receive the data and publish it to the DBUS, where it can be grabbed from the GUI, VRM, MQTT and all the other data services of the Venus and end up as a Battery, Temp Sensor, Tank sensor in the regular structures. It could be probably even possible to transport a Ve.Direct connection over WiFi for instance and make the SmartShunt or MPPT wireless connected to the VenusOS, but this would involve encapsulating/tunneling the serial p2p connection over TCP/IP, probably too much effort - I think Victron will come up with BTLE one day and make this obsolete (the WiFi range is of course better anyway, it could be unlimited using the Internet).
Long shot. what do you think, would MQTT be suitable as assync messaging system side by side with the Victron MQTT/ModbusTCP or would it be better to do something special, not used by Victron to not mess up (or get messed up) with upcomming services?
