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.

That's an interesting idea... +/-25V input, and they can be cascaded? There's probably even still one or two lurking at the back of a component drawer around here somewhere. 🤔 I was considering faithfully reproducing the Multiplus status LEDs, but realised that they're not particularly informative or useful. Using the whole 'inverter' on the new panel as a 12 segment indication of inverter load will be much more useful. I'm thinking of having blue up to nearly the limit, then the Victron trademark 'orange stripe', then everything turning an ominous red when the inverter limit is exceeded and we're drawing grid power. Anyway... I made a pylon (or rather, the front of it): It sits on top of another one that is slightly thicker, but also has a 0.5mm backing 'membrane' printed the size and shape of the middle bit (i.e. without the arms) to diffuse the (6) LEDs. The lower bit looks wrong (it would be unstable), but I had to make room for the light pipe thingy to attach in at the bottom. The printer's just chugging one of those out now. 🙂

Cheers for that, Moffat. 🙂 We use a Victron Multiplus II here, so I'm roughly modelling that with white PETG and lighting it up from inside... There should still be room to get the ESP32 in there, too - if I go steady with the hot glue, that is. 😁

The batteries aren't linked correctly... The 'link ports' should be chained together - 'linkport 1' to 'linkport 0' all the way down the stack, with 'linkport 0' empty on the 'master' battery and 'linkport 1' empty on the last. Only the 'master battery' then has either the RS485 or CAN port (depending on your setup and with the correct cable, which is almost never the one that came in the box - other synsync users can advise) connected to the inverter.

Fast work! 🙂 How does it sound? 🙉 Meanwhile... 😭

That's pretty much the stuff I used (I called it 'twin-wall extruded PVC shower panel material' earlier). Mine's maybe a bit thicker walled, with a horrible 'marble' pattern on one side. I found when testing it (with 5mm LEDs pushed through holes in one side) it bled the light along the direction of the 'tubes', so changing direction of the LEDs by 90° (from horizontal to vertical) just looked a bit messy. I'm currently messing about with ways to diffuse the LEDs a bit, but still prevent 'bleed' (between the segments of the 'battery', for example - blurring on the 'flows' is fine). The best result so far is with white PETG 3D printed shapes with 1mm thick walls, filled with hot glue. I've tried a test with a 10mm cube (or rather, 2 joined together) and a standard 5050 RGB LED: When the LED is off, it's just opaque white. For the curvy 'legs' that contain the flowing strips, I was hoping to be able to stick the LED tape on the inside side wall (vertically) to avoid having to kink the tape/PCB, but that leaves one side shadowed by the PCB... so I'll have to wait and see, there. Don't forget that without the need for (crudely made) gears, you'll likely have much less of an issue with the noise... You'll just have to wait until tomorrow to find out! 😆

You're welcome. Please convey my apologies to your wife. 😁 It just occurred to me that I didn't mention how I made the big LED in the OP... I had a bunch of these 16mm push buttons: ..which are not very good at being push buttons. In fact, they are the worst buttons I have ever come across. But with the button and plastic back removed (way easier than it should be), placed face-down on a silicone mat and filled with hot glue, then a 5mm tri-colour LED pressed into the back of them, they become big diffused indicators with a fetching chrome bezel. 🙂

Just a thought: Are your DIP switches upside down?

Nice. 😎 I was going to ask: Why a single string? Splitting them up into multiple strings wouldn't make wiring any more complex - it might make it simpler... all those pins on the ESP32 going to waste!? From what I understand, it doesn't take any longer to display than a single string... they all get their data in sequence, then a single 'FastLED.show();' call to display everything? I've not had the chance to use the library yet, but I'm quite looking forward to it... the 'blur' and 'fade' looks good, plus the inbuilt non-blocking timers sound like bliss. 🤓 What are you thinking for the dial faces and the loadshedding/geyser indicators?

To be fair, he also discusses the issues arising in low voltage (48Vdc) applications... I've had two '125A' polarised breakers fail (almost catching fire) when never subjected to more than 80A and never operated (switched) under load. Both failed the same way as Roland W's one in his powerwall - insufficient contact area leading to excessive heat, leading to... well, this: After the first one, I assumed I'd just somehow messed up the termination. Swapped it out, taking extra care the second time. It lasted a week. When I dissected them both, it became pretty clear that the tiny surface area of the contact was just too small to do the job, and the CSA of the single braid looked totally insufficient. These were branded 'TOMZN', but I suspect they might have been fake (even though they came from a reputable UK seller). Even the arc-deflecting 'magnets' appeared to just be pieces of steel (unless the heat killed them too, that is). I tackled the issue by installing mega-fuses and vowing to never use polarised breakers again if I can possibly avoid it. 🙂

I agree, the neopixels (WS2812) would simplify matters immensely - I only need to spend about £11 GBP to get 1 metre of tape with 144 of the WS2813 (better, faster version?) on it. I did kind of like the idea of kludging it together with the shift registers, and while initial tinkering looked promising, I've run into an issue with the dimming - which needs to look right to get the desired 'flow' effect. Specifically the timing: To write non-blocking code that regulates ramping the PWM up and down in between switching the LEDs in sequence, I'm down in the world of microsecond timings (especially when it's 'flowing' fast). The ESP32 has an annoying quirk whereby I can write (blocking) code with 'delayMicroseconds(interval)' which looks fine at high flow rates, but when I use a non-blocking 'if (micros() - timer > interval)', it takes WAY longer. Apparently this is due to the number of clock cycles it need to calculate 'micros()'... Ironically, 'millis()' takes less time, as it's being read straight from a register. Pah. I've been fiddling with making the 'steps' in the PWM ramps larger, proportional to the value being displayed. While this sort of works with the one string of 24 LEDs, by the time I've added another 3 or 4 strings to the mix, dealt with the incoming UDP packets etc, I think I'll have found the limits of the ESP32, if not my coding ability and patience. Pity, as I'd just found a 40106 hex schmitt inverter lurking at the back of a drawer, which freed up 4 PWM pins, as I realised that I can use just 1 PWM pin per string instead of 2 by simply inverting the PWM signal for the other half of the LEDs. But yep, the neopixels will be a lot more flexible, faster, easier to wire and likely look a lot better... Plus the ability to change the flow colour will be useful. I guess I'll have to get my head round that 'FastLED' library. But I'll probably still use a shift register or 2 to display battery level or something, just for old times sake. 😏 - Your mockup looks epic! Servos at ~£1 GBP each is pretty good, too... and they're 180°, so no need for gearing. Looking forward to seeing it. 🙂 How are you planning on getting the data into it? I used UDP from node red on the Cerbo GX... in node red, I added an offset of 1,000,000 for one variable, 2,000,000 for the next and so on, then at the ESP end did a simple 'if it's more than 1,000,000 and less than 1,999,999 : subtract 1,000,000 to get the value', etc. It seemed to be the simplest/fastest way of doing it, but I'm sure there are others. I had to order my neopixels from China, so I'm just waiting on speedpak now. I found a good resource on 'fastled' patterns (c/w videos of each effect) which I can stare at while I'm waiting... I'd like to do something between 'cylon' and 'comet', I think. 😁