Jump to content
Thank you for the great forum, Safe Driving over the weekend. Sincerely Jason


  • Content Count

  • Joined

  • Last visited

  • Days Won


Youda last won the day on March 12

Youda had the most liked content!


Profile Information

  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This is how the cable should look. Red and Black wires are NOT cross-connected. Just the cable itself is "twisted" as a form of shielding.
  2. @Fazil "Both" or "both combined together", please?
  3. Oh my! That dark brown color is really scary. Maybe that apart from the heat the chip also produces a huge amount of UV light. If this LED was able to destroy the plastic, imagine what it will do with your bare skin after some time...how about to buy yourself a decet Hazmat suit instead of pyjamas? Btw: I'm personally using OSRAM or Philips brands. Even their LEDs will change color a little over the years, but it's almost unnoticeable. You have to put the old and new next to the each other, in order to spot the difference. Your example is a real extreme.
  4. @martynw I have a similar experience - the console port is able to accept HEX protocol commands that are described in the RS485 guide. But the other way around it does not work, at least for me: RS485 port is not able to accept clear-text CLI commands, nor can be used with the BatteryView. To be honest, if I would be skilled enough to code a perfect Pylontech HEX protocol parser, I would use the physical RS485 interface, while leaving serial console port empty. This way, I would be able to keep automation running, while performing diagnostics on the serial console at the same time. For a shame, I am very bad in coding, therefore I have to stick with the easy CAN bus
  5. I do absolutely agree - lowest/highest cell info would be pretty sufficient for the most of the applications. Basically, the battery can report a cell-level info via RS485, whenever you send a special request. But broadcasting that kind of detail over CAN would be an overkill. Especially when considering the fact, that you can have multiple groups of 8 batteries stacked together, which equals to hundreds of cells....and the CAN message has just 8bytes of payload. BTW, I hope that "SOMEONE" will be able to post the updated CAN protocol description, once it will become available
  6. Hi Simon, Solution 1) The easiest way is to connect Pylontech batteries to the ICC. There's a special cable available for this. Just ask the seller of your ICC kit and he will be able to make that cable for you. (Actually, it's a serial to USB converter, not just a cable). This way, ICC will read the exact SOC information from the batteries and can act based on that info. For example, with GPIO KIT, the ICC is able to ON/OFF relays and contactors. Solution 2) Since I see that you've made a C# code to communicate with the InfiniSolar inverter on your own, without using ICC, you might also be able to code a Pylontech part too. There's number of options how one can speak to the Pylontech batteries. Just check these posts in my LAB here that will help you with the start: https://powerforum.co.za/topic/2322-youdas-off-grid-lab/page/5/?tab=comments#comment-69912 https://powerforum.co.za/topic/2322-youdas-off-grid-lab/page/6/?tab=comments#comment-75314
  7. Hi guys, I noticed a number of questions on the forum recently, on the topic of how to include Pylontech batteries in your homebrew monitoring and automation solutions. So, here's the summary to help you with the start. Also, it contains links to protocol descriptions, examples and downloadable source code archives. Just for the case that these files would be deleted from their original locations. Technically, there are 3 interfaces available on the Pylontech master battery: RJ-11 Serial Console RJ-45 CAN bus RJ-45 RS485 The actual pinout of the each interface is described in the US2000/US3000 manuals: The serial console is used by the manufacturer's diagnostic SW (BatteryView) and also by the ICC. But it's a bit hard to log-in and parse all the information this interface provides, since it was originally intended for running diagnostics and CLI only, not for the automation. Output of the CLI is formatted as human-readable tables and lists. Therefore, parsing this correctly can be a bit tricky. Here's a couple of examples, that are using serial console interface: https://github.com/irekzielinski/Pylontech-Battery-Monitoring Pylontech-Battery-Monitoring-WIFI-master.zip https://www.photovoltaikforum.com/thread/118958-pylontech-us2000b-daten-über-konsole-rs232-auslesen/?t=118958&start=10 Speichersystem_Pylontech.zip PYLON LFP Battery communication protocol - RS232 V2.8 20161216.pdf CAN bus communication with Pylontech is the easiest to code. CAN messages are short and easily convertible to the numeric values. Also, there's no need to actively query the batteries, since the messages are broadcasted automatically in a pretty frequent intervals. On the other hand, there are 2 drawbacks: CAN bus HW is not a part of the standard Arduino and Raspberry boards. You have to buy additional shields, hats or converters. The second drawback is, that Pylontech provides just a basic info over the CAN protocol. For example, there's SOC, temperature, voltage, amps, health and state flags. All of this is being reported for a stack as a whole, but you can't get to the individual brick or cell values. AFAIK, there are no CAN bus examples available on the internet. Luckily, the Pylontech's CAN protocol description is available: PYLON BMS CAN-Bus-protocol-PYLON-low-voltage-V1.2-20180408.pdf RS485 provides the most detailed information and even accepts configuration writes. For example, you can monitor individual cell values too. It's the best choice for automation. On the other hand, RS485 messages can be very long and the Pylontech's protocol layer is extremely complicated. There's a lot of circular checksums, numeric values that are not 8bit aligned and variable message length is being used too. A couple of forum member were already able to successfully implement RS485 comm with the Pylontechs. For example, @Elbow : https://powerforum.co.za/topic/3429-pylontech-vs-raspberry-arduino-plc/?tab=comments#comment-51956 pylon485-elbow.zip https://www.photovoltaikforum.com/user-post-list/106579-ondra234/ pyloncom.zip PYLON RS485-protocol-pylon-low-voltage-V3.3-20180821.pdf Hope the above info will help some of you with your Pylontech monitoring efforts. Youda
  8. I'm using a mini PLC that has multiple RS232 serial interfaces. These interfaces are connected to each InfiniSolar directly. The PLC has some CAN bus interfaces too, these I'm using to talk to Pylontechs A code running in the PLC is parsing serial communication (and CAN bus), then is providing the RestAPI with JSON interface available over TCP/IP LAN. Once you have a LAN device with JSON support, it's actually very easy to use it in Fibaro. PLC Tecomat Foxtrot: https://powerforum.co.za/topic/2322-youdas-off-grid-lab/page/3/?tab=comments#comment-60376 JSON output sample: (I bet that even Alexa or Siri would be able to use JSON directly, so you could yell something like "Siri, what's the actual solar power?" or "Siri, turn on the power plant".) Of course, you can use any piece of suitable hardware, like RaspberryPI, Arduino etc. For example, I used a clone of Arduino called Z-UNO in the start, since it has embedded Z-Wave chip onboard and is very easy to include in home automation as a standard z-wave device. It had some advantages and some pitfalls too. In order to parse the serial communication, you have to search for a PDF "infinisolar protocol". It's available for download even somewhere on this forum. Or, you can modify one of the many github projects that are intended for use with Axpert/PIP inverters. There difference is, that Axpert/PIP protocol has "QPIGS style" commands, while InfiniSolar has "^P003GS style". One last word: talk to the Infini via RS232 directly. As an alternative, you can talk thru USB port, since it's just a USBtoSerial embedded chip, not a real USB device. But stay away from using features of the "SNMP Web Pro card" for home automation. This card is a crap and has many issues.
  9. Hi @RikH Hmm, just like I said - OFF button for turning off - ON button for turning on For example, just press the OFF button for couple of seconds, the inverter will produce a long beep and then it will shutdown. Basically, if the sun is shining, the Infini will stay in charger-only mode. In this mode, it's charging the batteries, but not generating AC. Once the sun will go down, the Infini running in charger mode will shutdown completely. Once the sun will rise again, the box will wake up and will start charging the batteries again. Just keep in mind that it will stay in charger-only mode, so it will not generate AC. If you want the box to supply AC loads, then you have to turn it back on. Manually, by holding the ON button, or via a remote command. If you shutdown one of the units that are running in parallel, the process is online and non-disruptive. The other paralleled inverters will continue to supply the AC. Same with starting the inverter again. Please, bear in mind that my system is off-grid. Your inverters might behave differently if you have a grid supply connected to them. Of course, nobody will do the ON/OFF operations manually, every day. Therefore, you can do it remotely, via WebGUI of the "SNMP Web Pro Card". There's even a basic scheduler available for this: Or, if you have your inverters connected to a home automation, then you can issue ON/OFF command remotely, via script, based on the logic of your choice. Personally, I'm running a few scripts with this logic: SOC: If battery SOC is 25% then shutdown all the inverters. This will trigger the house ATS switch to connect the house to the backup power. If battery SOC 70%, then start the first inverter. This will trigger an ATS switch to connect the house back to the PV system. AC LOADS: Normally, just one Infini is running, other two are in charger mode. If there's more than 4000W of AC load, the other two Infinis are started automatically. EV: if an EV is connected to the wallbox AND battery SOC > 40% then all the inverters are started in order to enable maximum EV charging speed. AC LOAD: SOC: EV:
  10. @Nitheido first of all, let me repeat myself - " If you're not a certified Pylontech expert, don't touch the CLI, please". Easiest way is to start BatteryView and connect to the stack. Then close the program and open Putty, using the same COM port number. Press Enter twice and the CLI will prompt you for input.
  11. http://www.mppsolar.com/manual/SolarPower (hybrid)/Solarpower 1.14SP7/installSolarPower_Windows.rar http://www.mppsolar.com/manual/SolarPower (hybrid)/Solarpower 1.14SP7/installSolarPowerCS_Linux_64bit.bin
  12. Hi @Jurgens For a shame, Axpert King Inverter is not grid-tie capable and does not support running without batteries. Luckily, when Axpert King is configured in the SUB mode, it's possible to run it with just a small battery, and it will work too. For example a 3kWh of lithium for the start. Speaking of battery-less operation, it is supported on these models, specsheets attached: Axpert VMIII PIP5048MG PIP 5048GK But keep in mind, that battery-less operation is supported only for a single inverter. When running 2 or more inverters in parallel, it's not supported and may kill your inverter. PIP-MG specsheet.pdf Axpert_VM_III specsheet.pdf PIP-GK specsheet.pdf
  13. @RikH Oh yes...those European sunless winters I have a script in place that allows roughly 7kW charging during the day. In the night, or when lithium SoC falls bellow 40%, the wallbox auto-switches to 2kW. So, the logic above should work okay even during the winter. If not, I will swap the sign for some other, saying that EV's are welcome to top-up my home batteries
  14. Hi guys, today I made the sign for my solar EV charger. It's just a sticker on plate of inox steel, covered with a couple of clear-coat layers. I hope that it will survive longer than till the first rain...
  15. It's a standard RS232, therefore the voltage can be anywhere between -25V to +25V Long story short -USB to TTL cable converter is NOT suitable. You need a proper USB to RS232 converter.
  • Create New...