Intelligent AC control

Log entry #0

I was looking for a simple idea to win and keep the hardware.
After that I realized I'm doomed: Getting connections to the Thingy:53 for external hardware will likely destroy it, the nRF DK is missing a basic temperature sensor, but is easy to interface for components. When I final got the Thingy:53 I punched it with an nRF52 DK, not believing it can not interact with the Thingy:53 - it could, but only by erasing it and bricking it. The Nordic Tech Tour, EMEA will bring live to it again at end of September by handing out an nRF 53 DK. Until then I go with my nRF 52 DK to get the idea running, believing to easily port it to the nRF 53 DK...

Log entry #1

Set up environment to get code running on the nRF 52 DK.

• LED blink
• Button interrupt
• Potential Thingy:53 temperature sensor
• ...

Log entry #2

Instead of visiting The Nordic Tech Tour, EMEA, I chose to invest 50€ instead of sitting there 7h, digikey.de as always delivered in 2 days a nice DK to be able to unbrick my Thingy:53. Which was also a challenge, since nrf Programmer does not show the Thingy:53 as a target when connected via the DK - it shows a Thingy:52 and Thingy:91 when connected via DK, but not the 53...after some confusion about that I blindly tried a blinky...and the Thingy:53 blinked, instead of the DK....🤦

Now back in the game I got the basics running, challenges along the way:

• Tried hard to figure out how the PIR works with a Raspberry Pi Pico, RP2040 and CircuitPython - no reliable success.
• If you have a specific board type overlay, the general app.overlay is ignored - even for the boards that don't have a specific overlay.
• Getting USB UART for debug prints running on Thingy:53: It worked out of the box from the DK via JTAG, but the nrf53 USB was not enabled:
• Always run the sample/function isolated to prove it works, then copy it in your project to get it running in total. (In this case: samples/subsys/usb/console) Figuring out if it is not working the other way around is quite hard...
• Use dk_buttons_and_leds.h to prevent button bouncing & enable easy led switching.

Result: Basic elements are running: LEDs, button and temperature sensor.

Submit as draft.

Log entry #3

Business logic:

My project planning came short, I assumed some parameters of the Thingy:53 without checking the details and with that replanning came a time shortage.
To accomplish the results I would need a second device and a communication between both.
So a better layout would be an Thingy:91 indoors and a Thingy:53 outdoors communicating via bluetooth.

My startpoint feel good parameters come from https://www.baua.de/DE/Angebote/Rechtstexte-und-Technische-Regeln/Regelwerk/ASR/ASR-A3-5.html (German workplace laws for temperature)

Target a minimal temperature of 20° Celsius, maximal 35° Celsius, best: 26° Celsius at 50% relative humidity.
Utilities: Ventilator for getting air into and out of the room. AC for additional heating and cooling.
Define 'Summer' as 01.05-30.09., 'Winter' as 01.10.-30.04.

Summer rules:
Ventilator on if temperature outside < inside and if inside temperature > 26° Celsius
AC cooling on if temperature inside > 35° Celsius until 30° Celsius reached
Winter rules:
Ventilator on if temperature outside > inside and if inside temperature < 26° Celsius
AC heating on if temperature inside < 20° Celsius until 26° Celsius reached

Enhancement would be to add and combine relative humidity rules.

Log entry #4

Bluetooth communication between devices next....indoor is master, outdoor just needs to provide the temperature...

...Spoiler: didn't figure out the bluetooth communication between DK and Thingy:53 and integrate with my code in time; I just wanted to use the Thingy:53 as outdoor external temperature sensor and later replace the DK with a Thingy:91. I chose as base peripheral_uart + central_uart 😥

Final words

A (after Log entry #3: additional) Thingy:91 would be more suitable, since it is prepared with an to self solder header to get additional GPIOs to add a PIR + MOS FETs to control AC and Ventilators.