Paladin Solar Australia Pty Ltd | Solar energy services

Paladin Solar Australia Pty Ltd

Phone: +61 416 245 439

Add/Update information

Reviews

Tags

• Businesses
• Local service
• Home improvement
• Information technology company
• Solar energy services
• Solar energy service

16.01.2022 If you haven't seen this, it is worth a look. The link has more detail, but shows only $ costs. Digging deeper they are using 8492kWh/year as a 'standard' Ki...wi home consumption. That works out at 23kWh per day (and change). Local mileage may vary !! I put up the Australian version of this a while back. Very similar apart from slightly higher Heating/Cooling/Space Heating in Aus, understandably. But water heating is the clear power hog. I was surprised by the Electronics and Other, but then I did a consumption check on the TV. Despite being LED, 170W is not trivial considering how many hours it runs a day. My PC is a bit of hog as well at 150W, but I do spend a lot of time in front of that (the TV hardly at all). All the rest makes perfect sense for my household. Anyone see any glaring anomolies? https://www.nzcompare.com//average-household-electricity-u

11.01.2022 Quick suggestion for an excellent read on sustainability and all things interesting about energy generally. I haven't digested it all, but attached is the synopsis to give you a taste. The 3 main PDFs are downloadable from : http://www.inference.org.uk/withouthotair/

09.01.2022 I have made a start on the Paladin 4/6 to Paladin-8 upgrade guide. By way of an experiment I am using a AI generated text to speech which seems to help pacing and clarity. Comments welcome.

04.01.2022 Part 2 The LoRa Monitor kit or complete? The LoRa remote monitor is a good case study in manufacturing issues verses costs and value. It is superficially a... very simple thing with a minimalist bill of materials and a simple function. As conceived it is just a LoRa ESP32, 20 character by 4 line screen, a push button switch and a case. If you can source these from AliExpress or similar you can do everything but the case for NZ$30-40 depending very much on postage rates (which are presently horrendous) and 6 weeks or so delivery. Locally sourced, you are nearer NZ$100, but they do arrive, and in reasonable time. The case is altogether another problem. As you will see from previous posts (30 July 20), I have mine in little 750ml transparent, snap lid food containers. Initially, it was just something that was almost exactly the correct size, cheap, available and practical. Although initially I thought you can't use this, and did a 3D printed one that took 4 hours of printing, I eventually went back to the food container. And now it has really grown on me as a sort of reverse steam punk, almost conservationist, virtue signaling thing. There are transparent lidded cases in Jaycar that can be used, or if you are careful and can use a Dremel for the screen cut-out, lots more options. Assembly is just 6 wires to solder to the ESP32 board. 4 for the screen (SDA / SCL / Earth and 3.3V (or 5V if you want it really bright). Power is via the micro USB on the ESP32. And now you have other potential problems. Putting wire directly to that ESP board is OK, but And the micro USB connector is delicate and easy to over stress when it comes straight off the PCB and the whole thing is bin fodder. So, I have made a little PCB to mount the whole thing neatly together and that was an interesting problem. The obvious place for the ESP32 is on the back of the screen. But there are little metal twist tabs that stick out and really interfere with attempts to use double sided tape to keep everything together. So getting a set of ESP32 rails and a decent, rugged USB connector into that space was a sod. But the end result was worth it. Attached is a screen shot from the design tool and a picture of a scale fit inside the tabs. You can easy see the wiring pattern. The nice trick is that a short (5mm) 4 pin cable that I use for other tasks is a perfect fit as well. So the whole thing is then just electric Lego. The cost of a PCB is $2-3 or so in bulk. I could put these together and change $150 or so and I am quite willing to do that, in fact I could give the kids up the road the job for some decent pocket money. Or I could just put all the bits (with a programmed ESP32) in a food container from the local Countdown and send them out as a kit for $100. Or you can get the bits yourself and make one from scratch. I will happily provide you with a PCB at cost + postage, but you will have to source the USB socket, pins and rails as well. But if you are canny you will get away with $50 or so. The firmware, either way is freeware and you can load your own ESP32 (see previous post). So what do you think? This little monitor is not going to make any money and I don't want it to just pay its' way in parts and time. It is so frigging useful and rock solid simple, that having two or more is not totally out of order. I was running 4 at one stage when I was testing and I still have one in the loo. Oh did I mention that they are portable. If you plug the USB power lead into a little power pack it runs for days. At the end of the day it will be a numbers game. Initially I will sell these direct myself as then I will know who is running a Paladin-8 unit and be able to keep track of updates etc by email. So I am really looking for feedback here. Is all this too expensive? Am I wasting my time with this? Should I just include a finished one with every full Paladin-8 and adjust the Paladin price accordingly? Who knows? There is a post from 30 July 20 showing the Monitor screens presently programmed - has it been that long getting this sorted

02.01.2022 Using SmartPhone HotSpot SSID 32 char string to inject actual SSID / Password pair to activate ESP32 WiFi. A somewhat esoteric topic, but related to the previou...s post on OTA via HotSpots. Only really of interest to those who play with code and IoT things generally. This started as a thought experiment and a bit of lateral thinking, and ended as a coding exercise. However it works surprisingly well (with limitations as detailed below). On start up, if a HotSpot is available and a valid SSID is seen - this sequence is performed, otherwise the start continues normally. The LoRa devices do a HotSpot 'look see' now on boot as a matter of course, so this is using an already active connection. Execution time is minimal and the code is short and simple. This is a natural progression from the previous use of a HoTSpot for OTA. It works simply and is a lot less hassle than using the flaky commissioning apps and the associated code libraries. Full execution time is less than a second either way. From the WiFi handbook : "The SSID can be any alphanumeric, case-sensitive entry from 2 to 32 characters. The printable characters plus the space (ASCII 0x20) are allowed, but these six characters are not: ?, ", $, [, \, ], and +." "WiFi Passwords for WPA2 must be 8-63 printable characters. There are no specific exceptions, but unicode may cause problems at the device end, depending upon OS and implementation." Method: On ESP32 startup using the WiFi.SSID(n) command, the visible SSIDs in range can be parsed. Using a statistically improbable ASCII sequence a valid SSID/PASSWORD pair can be passed to the ESP32 to enable it to connect to the main network. A unique target/separator will provide a search key. Only the first unique character sequence will be required for the SSID, but the PASSWORD will need to be complete. Assuming a single character separator, using up 2 of the 32 available, there will be some reduction in PASSWORD length available. For example - using "&" as a key separator and assuming there are no other SSIDs in range using '&" as a start character. Assuming an SSID as "ThisIsMyHomeWiFi" and a PASSWORD of "ThisIsMyHomeWiFiPassword", and that there was another SSID "ThisIsTheHomeWiFi" in the visible list. The unique segment to pass would be "ThisIsM" to allow the correct selection. The target HotSpot SSID would then be : "&ThisIsM&ThisIsMyHomeWiFiPassword" The WiFi.SSID() parse would collect the full SSID starting "ThisISM" and use that and the PASSWORD to activate its WiFi. The code sequence to achieve this is simple and robust. If no leading "&" separator sequence is found then the WiFi reverts to the last known SSID/PASSWORD pair (or none). If a successful WiFi connection is achieved the program will monitor and maintain that connection through the duration of that boot and save the SSID/PASSWORD pair for future use or until a valid HotSpot is seen on subsequent startups. Otherwise WiFi will be inhibited. This method can be further extended to pass a 3 character numeric for the last Octet of the IP address with some reduction in available PASSWORD length to stay inside the 32 character SSID limit. "&ThisIsM&ThisIsMyHomeWiFiPassword&176" is 6 characters too long! But this would be acceptable : "&ThisIsM&MyHomeWiFiPassword&176" This would start the WiFi using : ThisIsMyHomeWiFi / MyHomeWifiPassword and the IP address of xxx.xxx.xxx.176

01.01.2022 A few minor changes to the Paladin Motherboard for next year. Nothing too exciting, mainly minor access improvements, labelling and power flow for future add-o...ns. 1. Better labels for the CT sockets that can actually be read :) 2. The Diode and trigger group have been moved down to improve plug in access for the CT sockets. 3. An additional 3 way spring clip type socket is now accommodated in parallel above the normal screw connector for the temperature probe as an optional build. I am not personally convinced that this will be an improvement, but the temperature probe connection is arguably the worst job on the install, so we have to try. I have moved the existing screw connector down to the very bottom of the board - this will be better as it will be easier to steer the wires into the slot. 4. A dedicated 5V/Ground power pickup is now provided for the daughter board in addition to the supply through the ribbon cable. This is to assist with the Daughterboard power requirements as more features are added. Asking the ribbon to power the Arduino Mega, an ESP32 LoRa, a RF433 Tx and NEMO is too much. The power supply is well up to the task at 10W, but more copper is needed. I have a couple of other ideas for 'extras' once the P-8 is active and the use of a large power supply all that time ago has proved prescient. 5. Minor cosmetic changes to dimensions and mounting holes. There are no circuit changes as the MB is designed to be simple and robust and works well as is. If it ain't broke... All the 'smarts' are in firmware and on the Daughterboard. 100% backwards compatibility apart from the 5V power line - which is not anticipated to be needed until next year's builds anyway.

01.01.2022 Part 1 : Paladin Thoughts for the New Year. The Christmas and New Year period gave me time to tidy up some of the crinkly edges of the Paladin-8 release and ...(hopefully) simplify the bits and pieces that are no longer strictly HW Diverter 'things'. What follows is an insight into my thinking on all this. The ideas below are my opinions and in no way are these necessarily either correct or definitive. However, they may well be a basis for a discussion that could be valuable for all including myself. In no particular order : The core Paladin concept is simply a HW Diverter that allows users to optimize their PV harvest and to maximize self consumption. To my mind there is a serious disconnect in the concept of installing PV and hoping to justify the ROI using export. Feed in rates are low relative to what you pay for grid supplied electricity (particularly if you are on a 'low user' tariff) and will almost certainly stay that way. Every Watt you generate and use from your panels is potentially a Watt that you do not need to buy from the power company. The messy issue is that solar is diurnal, erratic and seasonally variable. Another inconvenience is that the electric pixies will not tolerate being ignored, and at the same instant you produce them you have to use or dispose of them. Unused Watts are a real problem that is akin to putting a thumb over the end of the garden hose. The pressure (read voltage for the electricity case) builds up and something gives. The solution is excess PV storage of some form. The obvious best functional solution currently available is a battery, but these are relatively expensive and in some cases, problematic. Prices are coming down and the choices increasing, but until we get to (IMHO) around $250 per kWh installed, you will never justify the expense in pure $ terms. Verily, the convenience and satisfaction of having a well designed and installed battery / inverter setup to mop up and subsequently consume those excess pixies is impossible to quantify. But don't even think about trying to justify it in a fiscal sense. Hot water is the obvious low hanging fruit as long as you have a storage cylinder of some form. And this is Paladin's raison d'etre. You can mop up 8-10 kWh a day with even a standard tank and you are going to use it like it or not. If you have teenage children around doubly so. Paladin has reached a level of reliability and maturity that allows me the luxury of opening up on some of the other things you can do with it apart from straight forward diversion. As you read through this list remember that I am an unrepentant geek and maker who loves to code and think outside the box. So some of this stuff is totally impractical, but that is not the same as impossible. Some things have to be done just to see if they can be... Variable Diversion allows targeted export wattages to be maintained. Variable Top-up allows a target maximum import Wattage regardless of house use. Direct control of hard wired devices relative to PV or excess PV. Indirect control of just about anything using a time matrix, HW temps or PV. 'Ant' A/I (Almost Intelligence) control of just about any connected device. WiFi interaction to a browser based controller. Grid stress sensing and assist / mitigation. Passive LoRa broadcast to enable an infinite number of remote devices. Selective hourly / daily matrix for hot water temp profiles. Ditto for Inverter battery use and charging profiles with ref to HW temps. Ditto again based on weather forecast. Lora Remote data monitor. LoRa remote DRED Air Con controllers. LoRa remote Temperature probe. LoRa remote second (or more) tank controller with full temp management. LoRa remote EV charger. LoRa remote house load analysis. There is more, but so much of the above is complex to manage and frankly unsupportable in the real world and will never see the light of day outside of my home system. Most of these 'tricks' are really rather useless in today's home environment but the techniques that produce them can often be used in other ways. Case in point, the Battery Inverter option : If you have a battery inverter a standard Paladin will get in to a high speed tugging match for the trickle of watts that the battery inverter exports to maintain it's stability. Paladin has a response time several orders of magnitude better and always wins. The end result is that Paladin goes into full transfer using battery power. The cure is simply to use the 'Joule Injection Technique' that forms the heart of the targeted export feature. In theory Paladin is set to ignore the first 3 joules (watts / seconds) or so of export before calculating a transfer value in that mains cycle. This is just enough to keep the inverter happy and they then play nice together. This is the option on DIP #1. The original Paladin had zero options and no controls other than an OFF switch. This was the simplest and arguably best solution. Then came the boost switch and DIP switches for variable temperatures, battery inverters, second SSRs etc. Mostly these are trouble free (from a support POV). But PV is a magical thing to some, and coupled with a lack of basic Physics can cause serious cognitive dissonance. Offering some of the other options above could well be helpful for some installs and many users would find utility and even delight in having them. But how to do this without spending my whole working day debugging minds and opinions instead of code? The LoRa broadcast concept of Paladin-8 is probably / hopefully the answer. Once that Paladin is broadcasting you can pick up that real time data on a remote device and do what the hell you like with it. Paladin does not care, it will just react to remote actions as if they were house loads and continue as normal. There is no direct back channel by design. A LoRa device switching a load is no different to turning something on or off in the house manually. The problem from my POV, is manufacture. As you may well know, Paladins are manufactured / assembled in Christchurch from globally sourced components, and is a modular design to facilitate improvements and upgrades and occasionally, repairs. I am constantly besieged by well meaning suggestions that I put everything onto one board and get it all made in China (or where ever) to save costs. Paladin will always be NZ made, end of story. One of the issues I had with the LoRa ESP32 device being used for Paladin-8's broadcast and receiver extras - is updates. And there will be updates and improvements as time goes on. The ESP32 platform is just too powerful and the possibilities for improvement and enhancement are endless. This is just the beginning of a wide range of features. Although we can always do postal replacement - which is why all the ESP32 units are the same and are pin pluggable - it would be better for some if these could be updated simply by attaching them to a PC and running a simple program or script (batch file). I have totally dismissed the WiFi option for the moment. WiFi is a total menace for IoT devices. It is insecure, unreliable and tricky to set up to a router without using protocols that can compromise the whole house network. The NEMO units use WiFi extensively, and when it all works and is set up correctly on a decent router - it is brilliant. But otherwise it is just a troublesome dog of thing. Which is why you haven't got one. On the Arduino platform is easy to load a new binary file using a single firmware file and a loader program. The ESP32 is very much more problematic as there are in fact three binaries that have to be loaded sequentially, into just the right memory space in the correct order. Usually this is done through the Arduino or manufacturer's programming package and a properly configured Python environment. Much too difficult for most I fear - in fact I couldn't do it until recently - and it also means having all the exact same libraries that were used etc. However a bit of lateral thinking and some deep dives into Windows temp files has provided a very simple solution. I have set up a Google Drive link for now that has all the current binaries in sub directories along with a single batch file that assembles and loads a compatible ESP32 at a single click. All you need to do is plug it into a USB port, select what you want it to be and it's done. With that solved, life gets much easier. Once you have the compiled Python loader package, I can deliver updates as a zipped set of firmware binaries and a batch file. But more on that later. To be continued : Part 2 The LoRa Monitor, kit or complete?