Good day Community,
I need some help. I recently installed a backup system with further plans to add solar. The installation is simple: Victron MultiplusII, Cerbo GX, Grid Meter & Hubble AM2 battery. The inverter settings are set as per the Hubble “Victron Inverter Setup”.
However, the Hubble AM2 charge is steadily dropping on a daily basis, even though the voltage is set to 52.4V. Hubble gave me 2 options: (1) bring the battery in or (2) connect a Hubble CloudLink. The battery is bolted to the wall, so that is the last option.
Is the CloudLink worth the money when I have a Cerbo GX?
Anyone else had a similar issue? Solution?
Thank you. (I’m a total newbie.)
Just looking around on the internet it seems that this is a common problem. At this point, all that has come up is that Hubble say that you must log a ticket. No published solutions yet.
I have done some searching, could not see anything. Maybe not using correct terminology. Can you post a link, please?
There are threads on other forums about people complaining about the same thing. It’s even made it to the mybb forums. On another forum, anything bad about Hubble gets deleted pretty quickly
I don’t have Hubble and will never recommend it until they have proved themselves locally. Right now, they don’t seem to be coping too well. In my opinion, one shouldn’t have to fork out R2500 so that the manufacturer can resolve issues with their product. This shouldn’t be the cost for the customer.
I read a thread yesterday where the customer took the battery in and was told that the SOH was down to 57% after a few hundred cycles. Others say the cells are not balancing, damaged cells but no clear message from Hubble. Either buy the cloud link or take it in.
If it’s a hardware issue, They should do a recall and fix it. If it’s software, they should provide a way for the customer or installer to update the firmware.
Hubble have also made it clear that they do not deal with end customers but rather only with their approved dealers although some people have had some luck taking the battery in.
Do you know what type of cells are inside and their specs? Is it not possible that they got their charge voltage too low. Reason I say this is when I was doing some tests with my battery set up I thought setting the charge voltage slightly lower would make the battery last a bit longer and be better for it but what I found is that it started loosing charge (% started dropping) and cells where not balancing properly. when I put it back to 56V (as per my battery specs not saying yours should be this high) it was happy and all was well again.
They use BYD NMC cells. They state that they undervolt them for longevity. It seems that their BMSs are misconfigured.
I would not recommend them to anyone (or any NMC battery for this purpose).
I think this is the problem. I wouldn’t be surprised if it worked better by upping the voltage a bit and watching what happens. The BMS is probably configured to work only when cells are full, just my guess
It’s possible but as I stated, this should not be for the customers account and Hubble should easily be able to fix this. I wonder if it’s a marketing campaign to force more people to get the cloud link.
Most of the issues on other threads are with people running sunsynk inverters and these are supposed to work out of the box. Forgot to mention that with the client whose SOH dropped to 57%, the BMS was still reporting 100% to the inverter so something is definitely wrong with thr BMS.
I noticed that the Cerbo picks up the Hubble BMS as a Pylontech, so it automatically caps the charge voltage at 52.4V (roughly 1V lower than the recommended charge voltage, much like an actual Pylontech)*. When it was initially hooked up the battery was at 50% charge and when charged up to 52.4V it reported 97%. This SoC % has steadily been dropping over the course of the past week, even though the voltage is unchanged and the battery is not being cycled.
Perhaps cycling the battery a few times will bring it to its senses? Alternatively it may perhaps be worth a shot to edit the Venus source code and remove the 52.4V voltage cap.
However, given that this is a fairly standard Victron system, surely Hubble tech support must have encountered this before and know what is going on?
*I helped Marcil7 configure the system.
I seem to remember that there is a firmware update for the Hubble BMS to solve this.
Had exactly the same problem before as the Hubble BMS was reporting that it was a Pylontech.
(It copied the Pylontech CAN messages exactly including the Manufacturer string)
I think we got a new firmware version from Hubble that fixed it.
1 Like
Thank you Pierre for assisting.
Thank you Stanley, I am going to do the firmware upgrade. Will share the results.
Just made a call to Hubble Lithium support. They are sending me the firmware upgrade. There is a issue that are rectified with the firmware upgrade, that’s why they are promoting the cloudlink. Another solution the tech support that was released yesterday is to disconnect the CAN cables and drain the battery completely, reconnect the cables and charge. I am opting for the firmware upgrade. Will post results over the weekend.
That’s because they duplicate the pylontech protocol, most likely.
There are three batteries that use 0x359 to communicate alarm info (everyone else uses 0x35A). Those are LG Resu, Pylontech, and Sony/Murata.
Pylontech has the letters PN in the frame, and Murata identify properly in 0x35E. So that is how you know which one you are dealing with, and that is also why batteries that duplicate this protocol WITHOUT the PN in the right place, wrongly identify as LG.
So if it incorrectly identifies as Pylontech, that’s because they duplicated the protocol down to the PN in positions 5 and 6 in 0x359…
Now in China you can probably do very little, but in some places, this can be a legal issue…
@plonkster, you are correct. Hubble support confirmed to me that they are using the Pylontech protocol.
Yes, they copied the Pylontech CAN messages exactly, even the manufacturer name is sent as Pylon.
In a Victron system, the battery can also detect the inverter. The GX device sends a frame 0x307 with the payload 0x12 0x34 0x56 0x78 V I C in the first 7 bytes. Some batteries already use that to switch to a more suitable protocol. OK, let’s be specific. Pylontech does this. They really deserve some praise for that. They adapt their protocol to the inverter, enabling all the extra diagnostic features.
Hubble could do the same thing, switch to 0x35A for alarms, and send 0x35E with the manufacturer. The battery will then be detected as a Generic CAN-bms battery, and the name Hubble (or whatever they put in 0x35E) will even show up on the screen.
Its like copying answers from somebody in a test and forgetting to even write your own name 
2 Likes
@Marcil7 did the new firmware resolve your problem? I have a similar setup and I am also seeing a steady drop on my SoC even though the battery voltage is kept at 53.6V. Started off at 100% SoC and I loose 1% daily - down to 93% today.
@VerticalEaz1 Yes, the battery started charging immediately and now steady around 97% - 100%. You have 3 options: manual update, take battery to service centre or get a RIOT Cloudlink. The “manual firmware” is no simple solution. You have to make up a special cable. I managed to get a Cloudlink unit on loan. The firmware update ran straight away - in the background. The RIOT Cloudlink is not worth the R4500. I am returning the loan unit.