Ed Davies

?

I think this is the key point this thread has been dancing around. If you want to make good use of PV you need significantly more than one day's storage so you need to oversize by the standards of systems specified for heating from E7 or a boiler, so the first day or so's discharge will likely leave the store at over 50% SoC. On the previous page @ProDave said: Maybe they're perfectly willing to deal with it but are unable for some reason, e.g, because the original firmware developers are unavailable. Maybe they don't even have the source code, who knows? In my experience it's not unknown for small companies focussed on other issues to not give sufficient attention to software as an ongoing development process. Maybe fixing such issues is part of the reason for the work on a new controller.

If a PCM48 existed it would be ideal for that use. But how much hit does the CoP take if you run the ASHP at 60 °C, or a tad more, to charge a PCM58? It'd still be significantly better than one, I imagine. Bearing in mind that if you have a pre-heat buffer at your UFH temperatures then the quantity of heat you need to put in at the higher temperature would be fairly small.

https://en.wikipedia.org/wiki/DMX512

PCM58 for direct production of DHW. What I have in mind is preheat from a buffer tank as @JSHarris does. I did wonder about PCM34 for the buffer tank role up until I heard PCM34 was twice as expensive. Any heat loss from the buffer will be useful space heating, anyway.

Same as with an electric battery: put energy in to get back out later. Just that the energy is stored as heat (sensible (actual hotness) or latent (phase change)) rather than the chemical changes which happen in an electric battery. I see the main selling points as: 1) Lower standing heat losses, as said. 2) Lower temperature of storage allowing charging from lower-temperature sources. 3) Smaller size. As @ProDave says it would be better if the temperature was a bit lower than 58 °C when the source is an ASHP or, for that matter, solar thermal.

It'll be a while yet so plans might change but my current thought is to use one without any of their electrics. I.e., charge via hot water through the low-power circuit and extract heat for DHW via the high-power circuit. Maybe also extract some heat for space heating via the low-power circuit. To me the main attraction is to be able to use relatively low temperature heat sources (solar thermal, maybe boosted by diverted PV) to charge to just above DHW temperatures while still getting good capacity. Being purely hydronic is for flexibility of heat sources and sinks beyond anything their controller is ever likely to deal with but @JSHarris 's problems confirm. AIUI, as long as the input water temperatures are kept low enough such a system should be intrinsically safe for the gunk.

Ta. So it seems reasonable to assume that the “_PV” suffix means that wiring difference plus perhaps some other configuration change on the board. It sounds like they've made an attempt to introduce some, quite sensible, hysteresis but overcooked it. It's difficult to know the state of charge with PCMs but they've got enough temperature headroom between the whole lot becoming liquid (e.g,, I imagine you can be pretty sure of this by the time all the sensors read, say, 65 °C) and cooking the gunk. E.g., stop charging when any sensor gets to 75 °C, start charging when all have reduced to 65 °C would seem to me to be safe but use a much larger proportion of the capacity. You'd still get the behaviour where resetting the controller might cause it to start accepting charge but only over a much narrower band of SoC. And WTF, in 2018, did they build a controller without at least a web interface to allow you to see what's going on?

I reckon that's a clue in Lidl. If all the boxes are intact then it's either new in the last day or so or OK. If there's one opened box then it's probably OK, people have just been having a look. If there are multiple opened or taped boxes then there have been lots of returns, avoid. Most of the stuff I've got from there has been OK or good but there've been a few bits of crap. E.g., a workmate-like thing which was very poor even though I picked one of the few boxes which hadn't been opened. I'd take more notice of that, now.

Looking at the PDF UNIQ HEAT BATTERIES REFERENCE MANUAL_V2.0 version 2018_07_19_v2.0 page 19 (section 6.1, figure 6.1) the UniQ_SBC_01 seems to have only one 230 V input (16 A) with the constant supply going to the board via an internal 3 A fuse. Yours, though, has two separate 230 V inputs, doesn't it? My assumption is that the controller board for the SBC_01_PV is the same as for the SBC_01 (though, as you say, maybe with different factory settings) but with wiring a bit more like the SBC_02 (figure 6.3) with separate terminal blocks for the constant supply (6 A) and the heater supply (16 A) but without the relay R2 for the pump and associated wiring and terminal blocks.

What's the difference between that and the standard UniQ_SBC_01? Just that the 230 V in for internal power and for the heater element are separate (so the power for the heater can go through a diverter without the controller switching off every time the sun goes in)?

Absolutely. But if you're sending at less than about 100 kbaud and the (not-yet-known) transmit buffer size for the Arduino Nano is noticeably shorter than your message then your code could still be delayed beyond the end of the current 10ms time slot potentially causing a blip in your PWM code or whatever. Here's the Arduino code I was using on the ESP32 to test the buffer size: char str[200]; void setup() { Serial.begin(9600); for (unsigned i = 0; i < sizeof(str); i++) str[i] = '0' + (i % 10); str[sizeof(str)-1] = '\0'; } void loop() { unsigned long start = millis(); Serial.println(str); unsigned long end = millis(); Serial.print("Start: "); Serial.print(start); Serial.print(", end: "); Serial.print(end); Serial.print(", length: "); Serial.println(end - start); sleep(1); } Just tweak the size of str, declared on the first line, to try different buffer lengths until the operations start and end at the same time (“length: 0”).

It doesn't say, though, that it'll return before characters from previous calls to Serial.print have been transmitted. I also doubt that that statement is completely true: if a single Serial.print() call queues more characters than the buffer can hold there's bound to be some delay. I suspect that would be better worded as “may return before all characters are transmitted.” It's just a question of how big the buffer is. If it's the same 128 bytes as the ESP32s, etc, then you're fine. But, yes, upping the baud rate is the simplest way to be sure.

Quite possibly not in writing but maybe face-to-face.

I don't think there is a clear-cut answer, it depends so much on the details of the wall make up and the type of insulation being added. Perhaps your local building control department will have some experience of what's worked (or not) on houses like yours. The concrete floor slab will probably be a relevant consideration as it'll affect the way moisture in the ground moves. Is there no possibility of external wall insulation? That's usually considered safer from the condensation point of view and better from the point of view of avoiding cold bridges and problems with cold ends of joists.

FWIW, the ESP32 seems to have 128 bytes of buffering. Print 127 bytes plus newline and it goes “instantly”, 128 + nl and it takes 1 millisecond. 200 total takes 75 ms.

Having written that I did wonder if the baud rate would matter for a purely USB connection. I know it did on the original Arduinos with a separate USB/serial chip from the main processor but I wasn't sure for the modern ones with the USB integrated. I have some newer ones but they're packed away somewhere so I tried with an ESP32 which, though different, is a similar concept from this point of view. Indeed it was slower at 9600, 67 ms to send 70 plus a few characters: 18:49:33.538 -> 123456789 123456789 123456789 123456789 123456789 123456789 123456789 647 18:49:33.626 -> 123456789 123456789 123456789 123456789 123456789 123456789 123456789 648 18:49:33.693 -> 123456789 123456789 123456789 123456789 123456789 123456789 123456789 649 Indeed, there might be some buffering. Guessing wildly, maybe 16 bytes; that's what the cleverer UARTs on PC had and it's not entirely unlikely that's been emulated down the line.

That's neat. Worrying about style is a bit over the top for a 200 line program. One thing to think about, though, is the printing baud rate. There are 72 characters of fixed text in the message plus whatever is needed for the actual values. At 9600 baud (960 characters per second) that's at least 75 milliseconds to print so once a second your code will stutter for few cycles. Probably doesn't really matter but not nice. Maybe increase the baud rate.

Thanks @Cpd, very useful description. I guess the key is that the metal is mailable enough to conform reasonably well to the bottom of the slate so provide enough of a seal that water does run under the slates much?

Ugger, just looked at that link to find out what a soaker is. So, what's a soaker, then?

Isn't that Onoff's point, another reason to think ahead and not just follow the centre spacing slavishly?

Also, if your cutting is a neat as mine you'll want to arrange to bury the cut edges “inside” the joins wherever practical.

West gable of my house: spent ages working out how to put the studs exactly on 600 centres ready for portrait-orientation OSB sheets. It was all a bit of a compromise as the ridge beam is a about 30 mm south of exactly centre (my fault) and the south main post is about 30 mm north of where it should be (not my fault) so quite a bit of head scratching was involved. But I learned from it: for the other end of the house I realised only the studs on 1200 centres need to be exact, the intermediate ones just need to be roughly in the right place so I lined everything up to centre on the posts not caring that the centre stud up to the roof beam wasn't lined up as it went up the middle of a sheet. Much simpler and I've yet to find a problem with that.

That's the Japanese approach - WC in a separate room. They're pretty disgusted by western bathrooms for the reasons you list.

Does that use printed connectors between off-the-shelf metal parts? Standard extrusions cut to length? Anything else done to the metal, like drilling a few holes?