This site is now in read-only archive mode. Please move all discussion, and create a new account at the new Victron Community site.
Is it really necessary to have
Ve.can
Ve.bus
Ve.direct
Ve.smart
All incompatible, some using the same connectors with warnings not to exchange the cables, some with termination, some without?
CAN without VE. Should work for all, reduce the costs for victron and the customers, reduce the problems and complexity of the systems.
Some of these protocols are older than others, some are even deprecated. Some of the older ones work very well and would be difficult to simply drop them.
They each have their place for various reasons.
VE.Net is deprecated.
VE.Can is standard and also compatible with other Canbus systems (NEMA2000).
VE.Bus is proprietry but a solid, known working system used on current models. RS485 based. Good for mission critical applications where phase angle is to be maintained for example.
VE.9bit is deprecated, VE.Bus has taken its place. Newer RS products use VE.Can instead of VE.Bus - so maybe this indicates a trend.
VE.Direct is a point-to-point, nice and cheap - no need for special tranceivers, TTL serial based. Good for situations that are not mission critical andfor smaller setups.
VE.Smart is bluetooth based, very good for minimalis setups where a gateway device would not be cost effective. It's the only Victron wireless one available.
More information here if you want to study it:
https://www.victronenergy.com/upload/documents/Technical-Information-Data-communication-with-Victron-Energy-products_EN.pdf
Hello, everyone... good conversation. I'm just a regular Joe Blow and don't know much about Victron as a company, I do own several hardware pieces and mostly use Bluetooth to monitor them. I'm pretty happy that I don't have to add more wires to my battery backup systems. But looking at it from a regular user point of view, I would like to see a simpler solution, not just with Victron products but in general. I look for simplicity were ever I can, and always try to keep it or make it simpler. That is jut my nature. I would love to get the Cervo hardware but from what I have seen it looks complicated as in many cables going everywhere. Can Bluetooth be use and achieve the same results, Can the Cervo work on Bluetooth only as in no cables between devices? Like I said I don't know much about Victron hardware and just want to find out datails that would apply to my specific situation, right now I have 3 android devices on, so I can monitor 3 active Victron devices, that is 3 devices that I have to charge every so often, and fiddle around every time I need to monitor the devices. I would love to find an easier way of doing this but without breaking the bank.
I do think Victron could rationalise , then fully open all the then rationalised busses. Think of the eco system that would spring up around day an open protocol VE.SMART.
Ve.direct could easily be deprecated. Bluetooth is much easier then wires.
Bluetooth is horribly unreliable so unsuitable for larger installs where stability is required.
While bluetooth can't even deal with an audio device properly we won't be seeing it as a mission critical means of connectivity.
There are many products of differing ages, maintaining compatibility and looking after someone's investment must also not be forgotten.
If it was so simple, it would have been done, so let's consider that the powers that be may be better informed than the rest of us.
"we have always done it this way"
But, your remarks to bt are true, but again, here Victron could have used wifi at no extra costs and much more reliability.
No one uses wifi either for crtical comms, too much interference and other issues.
The average user can't manage their signal to the GX, you think it will be better between critical systems?
Apple have failed dismally using wifi for wireless carplay.
Maybe you think that's a great idea, I can assure you some bright minds would disagree.
I spend a lot of time in mission critical comms and some proper legacy environments - tech persists not because developers are lazy, but because the situation requires it and there aren't reliable alternatives.
You can't just dump tech either because something more interesting exists, dev and QA costs money, you also have to keep supporting the older tech so those clients are happy.
These decisions are far more complex than it might appear from the comfort of an armchair.
I work primarily in automating manufacturing, even the e-stops can be made over WiFi, certified and accepted for the highest safety level. But i have the advantage of not working for one company in one site making one product, but constantly working for different customers using different solutions for different applications.
Interesting thought. Of that list a big chunk are legacy and others have their place and are somewhat marketing names. For example...
VE.Can is just good old CAN with victron proprietary messages called VREGS flying around, along with some J1939 and NMEA2000 messages.
If my memory serves me right, VE.Bus is just a RS485 bus, so will be carrying Victron specific messages over it.
VE.Smart is just Victron messages over bluetooth
VE.Direct is a serial interface, again carrying victron messages.
So all in all they are using standards based technologies at the physical layer. At the protocol layer, I can understand them using their own messages and structures. What they need is not always implemented, so for example a lot of what I suspect they do over VE.Can can not be done using NMEA2000 or J1939 messages. In fact NMEA2000 allows for private messages allowing vendors to create their own as needs arise.
VE.Direct will never be replaced by WIFI or Bluetooth, or should I say, not for a long time. A physical wire is much less likely to fail than radio technology which can be impacted by weather, congested spectrum, denial of service attacks, etc. Running some of these protocols may work in very controlled locations, but as a general global deployment in uncontrolled open spaces may have more issues.
I installed a radar from a well known marine manufacture. To save running an ethernet cable up my mast, I connect to it via WIFI. It works well, until the boat is sat in the marina or a crowded anchorage, at which time the congested 2.5Ghz spectrum causes communication issues.
Everything has its place.
So you're also one of those people who, fascinated and completely pointless, ran their radar in the harbor. Welcome to the club :D
Sure, but cluttering up cerbo with connectors for 4 systems, that as you say are all dialects of can doesn't make sense, only increases the price of the product. CAN and USB would suffice, then customers could add additional interfacing over usb as needed.
By drastically reducing the price of the main unit.
Compatibility is the death of al progress.
@Trevor Bird inexpensive and victron is an oximoron, i respect that victron works in the yachting business where price doesn't matter, but the prices are not always fitting for the other markets. The internet gives us unlimited capabilities to compare features and prices.
But please remember this community is for users to help users. Victron welcome suggestions, but that's as far as we should go here.
Well @Ludo , you have a fair point : Victron has a lot of legacy interfaces. The same is true for the configuration tools : these days even a euro 20 switch has a web interface for configuration, so no dependencies on Android, IOS, Windows, Linux, etc. These, together with the apparent noise of the MultiPlus II, are the negative points of Victron.
I prefer wires over WiFi or Bluetooth anytime (since when is Bluetooth ´smart´, for a mission critical system ???). You may not need radar in a marina, but Victron does not only get deployed on boats, and then WiFi can be unreliable because of congestion ....
Still, by the time I am ready for it I will most likely buy Victron, simply because Victron has many advantages too and there is not a whole lot of serious competition out there (ignoring all sorts of lower quality Chinese brands, I see only Outback Radian, Studer XTH/Next and perhaps Schneider Conext. These are less suitable for integration with e.g. home automation systems and are even less well supported).
I think you forgot mastervolt in your list, sitting almost next door to victron. In a smaller part, just for RV's there are waeco, büttner etc.
Ofc I always preach victron if anybody asks me what to buy, but you can only criticize what you know and work with.
I'd like a clear roadmap to can for all systems plus Bluetooth or wifi for tiny installations.
Or else directly go to an Ethernet based protocol like profinet or ethercat, both realtime Networks with lots of supporters, both can operate with cat5/cat6 wiring and standard switches. Both work at normal network speeds, so phasing can't be any problem. Both work over most standard chipsets, so the costs remain low.
From personal experience adding Ethernet based protocols into the mechanism for command and control between products will bring complexity and lots of R&D for what benefit. I highly suspect that the message structures and detail would be encrypted for two reasons. Security, not having people hack the control of devices, and two to keep some control of what is going on. Therefore the control will not be open, but closed. They have open source capabilities that integrate with Node Red and Signal to allow users flexible control. So why would they do it. It does not reduce costs, but does increases complexity of stack and firmware that needs testing for some very simple message structures..
I suspect in a good few years time, we will see lots of Victron products using CAN. Just look at the new RS series of devices, they have CAN added. I have not got a device, but have watched release notes and capabilities being delivered at different times depending on the communication mechanism used, VE.Direct in some cases before VE.Can.
However today they need flexibility and to provide migration and capability to a lot of existing products. The Cerbo therefore has a place at the heart of a multi device system, today and into the future.
Can is ok for me, if ve.xxx is implemented in the firmware of a product it could maybe be reconfigured to can.
But hacking can is even easier then an Ethernet protocol.
And vrm opens all doors for potential hackers.
Ethercat or profinet was just a preference, also because of the possibility of using gigabit Ethernet as carrier, but can will do.....
If ONLY can.
