question

@Seamaster The system is not designed to be a generic PGN data repeater. It is selective of the devices it will accept PGN messages from and what it will process. For example it does not listen or process any temperature PGN's. There are documents on the Victron site which document the PGNs that it transmits and receives, as required by the NMEA2000 standards.

Just because you have a current sensor sending battery status and DC Voltage/Current if the device is not broadcasting the correct function and class then the system will ignore the messages.

As you are aware N2K is complex and VenusOS uses certain elements in defined ways. So the limitation is that VenusOS is designed to do certain things and interact with N2K in a certain way, if that is not compatible with your sensors then there is little that can be done through this forum to support you. You would need to get Victron themselves to modify the N2K/VeCan drivers.

@Bathnm you are saying:
"Just because you have a current sensor sending battery status and DC Voltage/Current if the device is not broadcasting the correct function and class then the system will ignore the messages"

I spent long time today going through different documents on Victron website. I this comment:

https://www.victronenergy.com/media/pg/Cerbo_GX/en/marine-mfd-integration-by-nmea2000.html I find these statement:

"Battery monitors

Supported. This includes any battery monitor as supported by the GX Device."

while in the previous paragraph "Inverters/chargers" the document specifies

"The interface has two functions:

• The function, “153 Inverter”, represents the AC-output

• The function “154 AC Input” monitor represents the AC-input

Charger Status messages will be sent by the Inverter function. Both functions have their own network address."

there is no specific requirement for battery monitors.

I also see that PGN127508 Battery Status is supported, by victron, but can you please shed some light what is expected? is there a specific device function and device class that is expected and if it is can you please specify what are these?
I did put quite bit time today to find out, but so far i have not found specific requirements.

Thank you for the help

@Seamaster Without digging into the actually code of the N2K device driver I am unable to answer your question. If what you are trying to do was supported it would just work. What you are asking for is not something that Victron has probably coded. They have current meters that can integrate into their environment, ref Smart Shunts and BMV712 so I doubt they need the capability via N2K.

I would hazard a guess that if your device looked like a battery it might work. This is based purely on the fact that they support CAN based batteries. However I do not believe there is a specific specification in N2K for a battery!

Sorry I can't help any further.

@Bathnm @Stefanie (Victron Energy Staff) @mvader (Victron Energy) Is there someone of the Victron staff that can clarify what is Venus OS expecting in terms of function and class in order to read third party NMEA2000 certified devices that output:

PGN127508 Battery Status or

PGN127751 DC Voltage / Current or

PGN127744 AC Power / Current - Phase A and PGN127747 AC Voltage / Frequency-Phase A

Where can we find NMEA2000 Driver so we can study the issue and understand exactly what is happening?

Is it published or do we need to request it from Victron's staff?

thank you

PS for informational purposes, with regards to Battery specifications, there is some new PGNs at the works at the moment and I have looked at them. The NMEA2000 organization will be releasing them soon.

@Seamaster the driver is closed source and Victron proprietary so you will not get your hands on the code. It becomes trial and error to reverse engineer the lower parts of J1939/NMEA2000 that are being used to identify devices, and should things change in the future you would need to go through that all over again.

If you have nota already done so take a look at this document. It clearly states that PGN127508 and PGN127744 are used and supported. There does not seem to be any reference to PGN127744. They do not publish the list of PGNs that they will receive, just what they transmit, that should also say something about the Victron approach to their equipment and interworking with N2K. I suspect the document and other material you have found is directed at people that want to capture data from the Victron ecosystem or to interact with the system to get power details into their ecosystem. It is not to support people sending data into that ecosystem. If it was to support receiving data from third party equipment, what you are asking for would be published in the open domain.

Ask your self, not from your perspective but from that of Victron's, what is the benefit of VenusOS being a generic data received for power information, how would that impact their business. If receiving data from N2K from any generic sensor is about display purposes then it is a very expensive display and not Victron's key business. If it is to influence the way the Victron eco-system works and controls devices then there is a significant regression testing and support implication on the Victron side. Does what you are trying to do have a positive impact on the volume of equipment that Victron can sell, if so I am sure they would be interested, just not through a public forum.

I am at the extent of the information and support I can provide, and you will not get Victron directly responding to you about this subject on an open forum, for the reasons articulated above related to support and maintenance of their ecosystem.

All the best.

Ask your self, not from your perspective but from that of Victron's, what is the benefit of VenusOS being a generic data received for power information, how would that impact their business. If receiving data from N2K from any generic sensor is about display purposes then it is a very expensive display and not Victron's key business. If it is to influence the way the Victron eco-system works and controls devices then there is a significant regression testing and support implication on the Victron side. Does what you are trying to do have a positive impact on the volume of equipment that Victron can sell, if so I am sure they would be interested, just not through a public forum.

@Bathnm @Stefanie (Victron Energy Staff) While some of what you are saying makes sense, there are things that I definitely don't get!

1. Why make it partially open source if the goal is not to let anyone else in? Is this portion od their code closed due to NMEA2000 being closed definitions? There are plenty of drivers/interfaces now developed for Venus OS that will display competitor information on the RPI system. I just installed service for Midnite Solar Classic 150 that works well!

2. Why implement MQTT and ModBus? this is opening this device to display any competition device that support one of these protocols. Why limit NMEA2000?

Does what you are trying to do have a positive impact on the volume of equipment that Victron can sell, if so I am sure they would be interested, just not through a public forum.

3. Why read NMEA2000 tanks sensors and read NMEEA2000 GPS, but do not read anything else? Victron does have tank interface, and reading third party sensors is in conflict with the theory of them selling more devices.

4. Reading NMEA2000 current sensor (not a shunt) should not harm their sales as they don't have one...

Anyhow, thank you for responding to me and please ignore my frustration....

What I'm thinking is maybe is is possible do create Python script to read from the can interface and write to dbus.

It is fudged solution and I don't really like it, but is there other smarter way?

Is there any Victron device that outputs on VeCan bus battery or AC Voltage/Current information that Venus OS can read successfully so I can study it and understand what is the difference?