One of the more pressing and troublesome tasks on my 'to do' pad has been a remote temperature sensor. Attempts so far have been disappointing. Rf433 is too range limited and subject to interference, WiFi is just a dog to configure and often limited in coverage and reliability in all some locations. The problem is Paladin needs an 'always up' reliable temperature report, that to date has required a hard wired sensor.
Enter LoRa. LoRa has now been coupled to an ESP32 processor and as such can be brought to the workbench. Like every tool, it depends how you use it. LoRa has limitations in data rate and buffer size, but in practice these are more than adequate for Paladin's use. Some lateral thinking needed.
The end result is that, using a part autonomous, part challenge/response, part broadcast protocol, it verrks !!
The temperature probe end ESP32/LoRa is mightily underutilized, but that will change later. The Paladin Core ESP32/LoRa is not exactly challenged either, and for the temperature task is only active for 50ms in every 8 seconds. So what else could it do?
Paladin Core now blind broadcasts a full Paladin data set every 5 seconds, corresponding to it's internal bulk collection cycle. Any device that happens to be listening can pick that data up and do with it as it may. This now becomes most interesting...
Another 'little' task was to implement a DRED (manufacturer implemented throttling for ACs et al) interface so that Paladin can control AC(s) to use excess solar. See how easy that is to type as a mission statement?
Implementation of a such a simple 4 wire / 3 + 1 state protocol (OFF/50%/75%/FULL) should be simple, and it is. But intelligently, not so much. It took a few sleeps and rather more coffee to get my head around a method using Paladin data to do this in a satisfactory way. And what satisfaction it was. A bathtub moment for sure.
But like so many things, when you get to the bottom of the problem (if not the barrel), with a lot of help from Occam's Razor, the solution is so very very simple.
On the test rig, it works like a charm. There are a few possible 'tuning' issues that will have to wait for full live tests when we get more sunshine; as I am well aware that theory and test rigs are not any sort of real world substitute in this PV game. Excess PV is simple phrase with so many variations.
However I foresee no major issues, even to having a single firmware solution for any mix of compressor sizes (relative to available PV); even multiple units in concert. Using the hardware of the ESP32 as a mini AI to do all the heavy lifting, just leaves Paladin to host the control switch. Thus the impact on Paladin Core performance is effectively zero. Nice.
Control as I see it at the moment are using the existing switch - we may need another (but there are other possible big changes here also).
Assuming the AC head unit is ON. Left is Full On (no DRED), Center is Off (Under DRED), and Right is Auto (DRED control to match available excess PV).
The implications of this are massive. There is now autonomous operation of DRED devices in relation to excess PV at scale. This allows total utilization of excess PV for home conditioning and a huge potential power sink to help mitigate the 'duck curve' that network operators worry so much about.
Even little 'nice tricks' like having the DRED activation level proportional to the HW temperature drop in neatly, since Paladin does this already for other things.
The very best feature from my POV is that it is totally 'plug and play', automatic and autonomous. No WiFi, no internet, no provisioning, no apps, NADA. Flick the switch and it goes.
I envision putting a simple tri-color LED on the DRED receiver unit to show it's activity and DRED state, since the other wrinkle is that ACs are in themselves high reactive devices. Watching this all work is so incredibly counter-intuitive, there has to be some easy to understand feedback to what, if anything, it is actually doing.
Clarke's Third Law: Any sufficiently advanced technology is indistinguishable from magic.
(https://en.wikiquote.org/wiki/Arthur_C._Clarke#:~:text=Any%20sufficiently%20advanced%20technology%20is,he%20is%20very%20probably%20wrong.)
ID Verified
Trusted
