HedgeSlammer

Yes. 🙂 But it depends on the BMS and you'll need an interface of some sort...

Sorry, I didn't ever retry the CH340 with Win 11 after I got the PL2303 working. I'd offer to test it, but I'd rather remove my own eyes with a spoon than look at Win 11 / .NET ever again. 😬

https://www.fogstar.co.uk/ - Has anyone even heard of them? I know the company as being the people you go to in the UK for 18650s and the like (if you want to avoid getting burned with ebay fakes), and I've heard good things about their leisure battery range - well built and good value, apparently. Now I see that they're expanding into the ESS market with units that look a bit like the Pylontech offerings, but with a colour touch screen and a decent BMS (PACE). Besides the rack mount units, they offer some interesting formats, e.g: ..and the prices look pretty keen. So... has anyone here used or even heard of them? Too good to be true?

No idea if he will ship to .za, but there's a guy in the UK that I've heard good things about: Ben Allen - [email protected] His website seems to be broken at the moment, but here's his fleabay listing for the repair service: https://www.ebay.co.uk/itm/285164579131?hash=item426522293b:g:I2sAAOSwQchkDGfW Can't hurt to ask him.

Did someone say 'Daly'? A company that pushes f/w updates onto their BMS via their (horrible, flaky and intrusive) app without the users knowledge or consent, that bricks the BT comms module, then denies it? That 'Daly'? 😱 JBD or JK, mos' def'. 🙂 (Am I still bitter? Do I sound bitter? OK, yes. I'm still bitter).

Ah, yep... I had that problem, too. I got away with a 2A PSU and a 3300uF cap, but also I think in the code I might have made each needle move in turn (rather than more than one at the same time) - although in the 'test' mode they do all move at once, seemingly without the ESP8266 going nuts. 🤔 I've definitely found the ESP32 can be a bit more fussy (than the 8266) about voltage dips and noise.

How's your one coming along, @WannabeSolarSparky? I've got mine up on the wall... 😎 Here's a video (note the 'fake PV' data injection, then SOC plus inverter load to demonstrate - I'm fighting the real data as it comes in, so it jumps around a bit, but you get the idea). I used the '144 LEDs per metre' WS2813 strip for the legs, battery, inverter and house, with 60 lpm WS2812 for the sun and pylon. I'd made the legs to take 10mm wide strip, but the 144 was 12mm wide so I had to trim a mil off the power tracks on each side - luckily they were generous with the tracks, so I got away with it for such short runs. Getting it to bend around in nice curves and stay flat was a right pain, as the LEDs are less than 2mm apart, but it worked out in the end. Basically, by folding it back on itself, squeezing one side sharp and then flattening it back out whilst bending it into a curve with the sharp crease on the inside of the curve. It's best to completely remove the stick tape first, though. I didn't fill any/everything with hot glue (as a diffuser) as originally planned as it looks OK without it, plus it's too easy to lose the shape of the parts when they're heated. The code still needs a bit of fine tuning, plus there are a few oddities with the FastLED lib that need addressing (like the LEDs in the 'arms' don't go completely off when they should). I'll post the code / stl files once it's sanitised. 🤪

I used [email protected] a couple of months ago and got a quick response, with the latest 'batteryview' software and a (as it turned out, corrupted) zip of the firmware. It helps them if you can send them the serial numbers of the batteries, along with details of the exact issue you're facing. If there is no specific issue, the general advice is to NOT update the firmware. As I understand it, the newer f/w just contains specific bugfixes that overcome specific communications issues with specific inverters. If you don't have these issues, there's nothing to be gained - the functionality of the battery is the same. The risk of 'bricking' the battery by attempting a f/w update is not negligible. You'll find various versions of the 'batteryview' software in the 'downloads' section of this site (along with various f/w versions). If you do intend to go ahead with a f/w update, do yourself a favour and read this thread in it's entirety. 🙂

Good tip, thanks... I'd tried using this method before : #define DEBUG 0 #if DEBUG == 1 #define debug(x) Serial.print(x) #define debugln(x) Serial.println(x) #else #define debug(x) #define debugln(x) #endif .. but it all goes to hell when you're dealing with floats (i.e. more than one argument - the second defining the decimal places to be printed). But your method seems to cope with that, no problem. I'll be using that in the future. 👍 I do try to only enable one 'print' at a time, though - especially when dealing with 'timing critical' stuff, like these microsecond LED dimming loops. There's still always the trusty 'Search: Serial.print >replace with> //Serial.print', too. 😆

Here's the whole thing so far... I might have to re-do the sun, though. It's supposed to be sized so that the 60-LED-per-metre strip lines up with the 'rays' inside, but I suspect it won't and needs to be about 15mm bigger diameter... I tried it with the 30-per-metre, expecting it to be lining up with every other ray, but it's miles out. 😢 Still, what's not to like about a bigger sun? Making the 'rays' a bit bigger would certainly print a lot better, too. 🙂

Cheers for that. 🙂 From the WS2812/13 datasheets, they suggest that the data level needs to be 0.7 x the supply voltage, which would mean 3.5v at 5v supply - a tad higher than the ~3.3v the ESP delivers. Reading around, sometimes you can get away with it, sometimes not. Depends on the particular LEDs. One neat trick I came across was to split off the supply to the first LED and stick a small silicone diode inline there, which drops the supply voltage by 0.7v, meaning 4.3v x 0.7, so 3v data level, then the second LED takes it back up from there for the rest of the string. It does mean that the first LED will be a bit dimmer, though. I'll stick with the level shifter, as I already have some, it fits in there nicely and I won't have to experiment too much when the LEDs finally arrive. I started with the 'cylon' code, but it doesn't give me that 'ramping up' or 'fade in' effect for the leading LED. The 'blur' thing looked promising, but a bit clunky at lower speeds. I've gone for one 'active' LED on, then the one in front of it is ramping up as the one behind is ramping down by the same amount and the one behind that is turned off. Probably completely unnecessary, but I won't let that stop me! 😆

Looking good! 😎 My LEDs are apparently in the UK now... "5 Jan 2024: Customs Clearance-London Heathrow, Scanned-Scanned At Dispatch Hub". I did get a string of 30 (30 per metre) WS2812b to test with in the meantime. All the 3D printing is done and (like you) I'm 90% on the coding. I'll have to fiddle with the timing/speed of the flows some more once I have the LEDs connected and have removed all the 'Serial.print' cruft. How are you regulating the speed of your 'flows', BTW? Simple timers with a variable interval? I decided to make things extra complicated for myself by making the flow LEDs fade in and out as they moved along, so for lower speeds (<50%) I'm using a varying non-blocking delay (interval) between each of the (255) 'brightness steps'. With an interval of zero, the flow isn't fast enough, so for >=50%, I increase the number of 'brightness steps' taken in each iteration. Theoretically, this approach should make the flow speed double between ~49% and 50% (when 'brightness +/-1' becomes 'brightness +/-2'), but curiously it doesn't seem to.🤔 I've shot myself in the foot, there, as I can't now regulate the 'global' brightness of it without all the timings/speed changing. I could do a 'constrain', I suppose - or a 'map' - to limit maximum brightness. An aspect I hadn't anticipated was the need to explicitly turn LEDs 'off', since they each finish their innings at zero brightness. Normally, I guess you'd set them all 'black' after each 'Fastleds.show()', but this made everything flicker and takes too long, so I just turn off the one that preceded the currently dimming one, which appears to work. Also, did you get away without using a level shifter (to bring the ESP32 LED data outputs up to 5v)? I'm getting mixed results, but will probably use it - especially if I can just power it (3.3v side) from a GPIO pin set high.

My most recent version of 'BatteryView' is here. If you're updating the firmware, best practice is to do each battery individually, having disconnected it from the others. For the most up-to-date firmware(s), you're probably best off emailing pylontech ( [email protected] ) directly. They take a day or two to reply, but are generally pretty good in that regard. If they're working fine, though, why take the risk of updating them?

No need to spray them - if you look at them from the pointy end, it's obvious which is '+' and which is '-'. 😜

^^^ This. + Do the 2.4 & 5GHz on the Mikrotik have the exact same SSID name? I've had that cause a similar issue before.