Need to Know podcast–Episode 353

in this episode I talk about a recent series of blog posts I wrote about some analysis I did on various AI services available today as well as my thoughts on these. I also cover off the latest news and information in the Microsoft Cloud for you. Listen along.

Brought to you by www.ciaopspatron.com

you can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-353-ai-services-analysis/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

or Spotify:

https://open.spotify.com/show/7ejj00cOuw8977GnnE2lPb

Don’t forget to give the show a rating as well as send me any feedback or suggestions you may have for the show.

Resources

CIAOPS Need to Know podcast – CIAOPS – Need to Know podcasts | CIAOPS

X – https://www.twitter.com/directorcia

Join my Teams shared channel – Join my Teams Shared Channel – CIAOPS

CIAOPS Merch store – CIAOPS

Become a CIAOPS Patron – CIAOPS Patron

CIAOPS Blog – CIAOPS – Information about SharePoint, Microsoft 365, Azure, Mobility and Productivity from the Computer Information Agency

CIAOPS Brief – CIA Brief – CIAOPS

CIAOPS Labs – CIAOPS Labs – The Special Activities Division of the CIAOPS

Support CIAOPS – https://ko-fi.com/ciaops

Get your M365 questions answered via email

Welcome to the Microsoft Incident Response Ninja Hub –

https://techcommunity.microsoft.com/blog/microsoftsecurityexperts/welcome-to-the-microsoft-incident…

Listen to an audio recap of your meetings in Teams –

https://techcommunity.microsoft.com/blog/Microsoft365InsiderBlog/listen-to-an-audio-recap-of-your-m…

Introducing Surveys Agent, your personal survey expert –

https://techcommunity.microsoft.com/blog/microsoft365insiderblog/introducing-surveys-agent-your-per…

What’s New in AI for Security from Microsoft Entra? –

https://techcommunity.microsoft.com/blog/microsoft-entra-blog/what%E2%80%99s-new-in-ai-for-security…

Microsoft ranked number one in modern endpoint security market share third year in a row –

https://www.microsoft.com/en-us/security/blog/2025/08/27/microsoft-ranked-number-one-in-modern-endpoint-security-market-share-third-year-in-a-row/

Securing and governing the rise of autonomous agents –

https://www.microsoft.com/en-us/security/blog/2025/08/26/securing-and-governing-the-rise-of-autonomous-agents/

How systems integrators are scaling innovation with Microsoft 365 Copilot and agents –

https://partner.microsoft.com/en-US/blog/article/copilot-partner-spotlight-august-2025

Microsoft deployment blueprint – Address oversharing concerns for your M365 Copilot deployment –

https://techcommunity.microsoft.com/blog/healthcareandlifesciencesblog/microsoft-deployment-blueprint—address-oversharing-concerns-for-your-m365-copi/4434598

Staying Ahead of Compliance: Keep Up with Key Insights from our Quarterly Compliance Update –

https://techcommunity.microsoft.com/blog/microsoft365copilotblog/staying-ahead-of-compliance-keep-up-with-key-insights-from-our-quarterly-complia/4448011

Microsoft Security Copilot in Intune deep dive – Part 1: Features available in public preview –

https://techcommunity.microsoft.com/blog/intunecustomersuccess/microsoft-security-copilot-in-intune-deep-dive-%E2%80%93-part-1-features-available-in-pu/4406244

What’s New in Microsoft Intune: August 2025 –

https://techcommunity.microsoft.com/blog/microsoftintuneblog/what%E2%80%99s-new-in-microsoft-intune-august-2025/4445612

OneNote for Windows 10 support is ending –

https://techcommunity.microsoft.com/blog/microsoft365insiderblog/onenote-for-windows-10-support-is-ending/4445230

Think before you Click(Fix): Analyzing the ClickFix social engineering technique –

https://www.microsoft.com/en-us/security/blog/2025/08/21/think-before-you-clickfix-analyzing-the-clickfix-social-engineering-technique/

Deep Dive: DLP Incidents, Alerts & Events – Part 1 –

https://techcommunity.microsoft.com/blog/microsoft-security-blog/deep-dive-dlp-incidents-alerts–events—part-1/4443691

Deep Dive: DLP Incidents, Alerts & Events – Part 2 –

https://techcommunity.microsoft.com/blog/microsoft-security-blog/deep-dive-dlp-incidents-alerts–events—part-2/4443700

New SKUs available for M365 Business premium – https://techcommunity.microsoft.com/blog/microsoft-security-blog/deep-dive-dlp-incidents-alerts–events—part-2/4443700

Testing the differences between AI services – CIAOPS – https://blog.ciaops.com/2025/09/06/testing-the-differences-between-ai-services/

An analysis of how AI services vary – CIAOPS – https://blog.ciaops.com/2025/09/07/an-analysis-of-how-ai-service-vary/

Comparison of AI-Generated Articles – CIAOPS – https://blog.ciaops.com/2025/09/08/comparison-of-ai-generated-articles/

IoT motor connectivity

Although I had completed a project using a servo motor with the Sparkfun ThingPlus ESP32-S2 Wroom here:

New IoT device with a servo motor

turns out that to drive any motor more serious you’ll need a dedicated motor driver board and a separate power supply just for the motors. Luckily Adafruit has just such a board available:

https://core-electronics.com.au/dc-motor-stepper-featherwing-add-on-for-all-feather-boards.html

with the details here:

https://learn.adafruit.com/adafruit-stepper-dc-motor-featherwing

This board will allow you to drive up to 4 independent motors.

which you connect to M1, M2, M3 or M4 shown above.

Flipping the board over, you’ll also find the connection for the external power (5-12V DC) required to actually drive the motors. I decided to use 4 x AA batteries in a separate holder with an on/off switch:

https://core-electronics.com.au/4-x-aa-battery-holder-with-on-off-switch.html

I also got a Mini Robot Rover chassis kit:

https://littlebirdelectronics.com.au/products/mini-robot-rover-chassis-kit-2wd-with-dc-motors

that, as you can from the above, includes 2 x DC motors.

I connected these to M1 and M2 on the motor driver board, as well as also connecting up the external power for the motors.

I then needed to connect 3.3V and GND to the motor driver board which are shown above and in more detail here:

The final piece of the puzzle is to connect the SDA and SCL pins from the Sparkfun ThingPlus ESP32-S2 Wroom to the SDA and SCL pins on the motor driver so they can communicate.

To talk to the motor driver board you’ll need to use the Adafruit motor shield v2 library. I’ll cover off some of the code I’ve created in an upcoming post.

When you apply the power supply for the motors to this board a green LED is lit just under the power connector as shown above. I wasted a few hours with this until I discovered a fault solder joint that was the cause of my issues.

So my wiring looks like:

with the two motors for the drive wheels connected to M1 and M2 as mentioned above and whole thing sitting on the mini robot rover chasis.

I now have a mobile device I can command to move about the room. Next step is actually writing the code to make it work, which I’ll cover off in an upcoming post, so stay tuned. However, here’s a sneak peak of what I managed to do:

Subscribing a Sparkfun ThingPlus ESP32-S2 WROOM to Adafruit IO

I have now been able to successfully publish temperature data from a ESP32-S2 device to Adafruit IO as I detailed here:

https://blog.ciaops.com/2023/05/31/connecting-a-sparkfun-thingplus-esp32-s2-wroom-to-adafruit-io/

The next thing I want to achieve is to ‘push’ data down to the device from the Adafruit IO web site.

The starting point for this is to create a new feed in Adafruit IO. You’ll find how to do that here:

https://learn.adafruit.com/adafruit-io-basics-feeds/overview

To inject data into this feed I’ll need to create a Dashboard in Adafruit IO. You can find out about doing that here:

https://learn.adafruit.com/adafruit-io-basics-feeds/overview

In my case, I’ll add an ON/OFF button to the dashboard and connect that button to the feed I just created.

This will basically inject the text values ON and OFF into the feed, which I’ll then read on my device and take action.

The code looks similar to last time but now:

Adafruit_MQTT_Subscribe onoffbutton = Adafruit_MQTT_Subscribe(&mqtt, AIO_USERNAME “/feeds/onoffbutton”);

You’ll see that I define a variable using the Subscribe method.

while (subscription = mqtt.readSubscription(2000)) {

Serial.println(F(“Received button data”));

if (subscription == &onoffbutton) {

Serial.print(F(“Got: “));

String ledstatus = (char *)onoffbutton.lastread;

The core of the program on the device is the statement starting above that reads from the feed, and if contains a value, it then takes an action. In this case, I look for the text ON or OFF in the feed and then take the appropriate action with the inbuilt LED on the device.

The result looks like:

You’ll find the code at:

https://github.com/directorcia/Azure/blob/master/Iot/ESP32-S2/IO-Adafruit-Subscribe/main.cpp

So using Adafruit IO I’ve able to pretty easily send information to a dashboard and receive information from a dashboard. I now need to have a look at sending data from Azure to the device but I’m in no rush to do that just yet as I figure it will take a bit of work. I think my next project will trying to use the device to control some motors and add ‘motion’ to my project.

Stay tuned for more.

Connecting a Sparkfun ThingPlus ESP32-S2 WROOM to Adafruit IO

After my previous success getting data into Azure IoT Central I now wanted a way to send data the other way. That is to the device from the cloud. However, I could see this being a challenge if I continued to use Azure as my cloud endpoint. What I really needed was something simpler to help me better understand the core communication concepts.

With this in mind I discovered:

https://learn.adafruit.com/

that is much easier to use to do the basic stuff I wanted.

I therefore went to Adafruit IO and created a free account. This will then give you access to:

https://io.adafruit.com/

I then needed to create a ‘Feed’ into which the data from my device would be sent so that it could then appear in the Adafruit IO console. You can follow these instructions to create a ‘Feed’:

https://learn.adafruit.com/adafruit-io-basics-feeds/overview

To get the credentials you’ll need to connect to the feed you just created you’ll need to select the ‘key’ icon in the top right of the window as shown above to reveal the details.

You should see a dialog like that shown above with your Active key. It is also handy to grab the sample code displayed below.

You’ll need the following headers/libraries in your code:

#include <Arduino.h>
#include <WiFi.h>
#include <Adafruit_MQTT.h>
#include <Adafruit_MQTT_Client.h>

you’ll also need to define a few things:

#define AIO_SERVER “io.adafruit.com”
#define AIO_SERVERPORT 1883
#define AIO_USERNAME “<Adafruit IO user name>“
#define AIO_KEY “<Your Active key>“
#define WLAN_SSID “<Your WiFi name>“
#define WLAN_PASS “<Your Wifi password>“

You’ll need to enter your own values for the last few to suit your own environment.

Next, you need to connect to the feed you created using:

// Setup the MQTT client class by passing in the WiFi client and MQTT server and login details.

Adafruit_MQTT_Client mqtt(&client, AIO_SERVER, AIO_SERVERPORT, AIO_USERNAME, AIO_KEY);

Adafruit_MQTT_Publish feed= Adafruit_MQTT_Publish(&mqtt, AIO_USERNAME “/feeds/<Your feed name>”);

The feed variable here is where you will ‘publish’ data to be sent to the Adafruit IO console. The main loop running on the device will then contain something like this:

if (!feed.publish(ciaaht_getTemp())) {
Serial.println(F(“Failed”));}
else {
Serial.println(F(“Success”));}

which in essence, publishes data to the feed you created. In my case, I’m feeding in temperatures data via the function ciaaht_getTemp() which get the temperature from the DHT20.

There is a little bit more to it than that, but all the code is here:

https://github.com/directorcia/Azure/tree/master/Iot/ESP32-S2/IO-Adafruit-Publish

including the custom temperature sensor functions code I created previously.

With the code now uploaded to the ESP-32 I was able to see the data appearing in my feed in Adafruit IO as shown above. You’ll also see in my code that I used the on board LED as kind of indicator to let me know if things were working. A visual debugger if you like.

As you can see, getting data into Adafruit IO is much, much easier than into Azure IoT Central and I understand why that is and I’d suggest people start with Adafruit IO before moving to Azure. There is far less code with Adafruit IO making far easier to debug and understand.

With this now working and displaying temperature from my sensor, it is time to try and now send data to the device to control it from the cloud. Look out for that update coming soon!

Connecting a Sparkfun ThingPlus ESP32-S2 WROOM to Azure IoT Central

One of the main aims I’ve had with all my IoT projects was eventually to integrate them into Azure. One way that I found was via:

Connecting to Azure IoT hub

The limitation there is that it really only gets the telemetry into Azure. From Azure IoT hub you need to send it off to another application to get any real value.

What I wanted to achieve was to send that data into Azure but have it display some sort of result, like a graph, without me having to do anything too much low level work.

The solution was to use the Azure IoT Central service. So the project plan was to use what I learned in building an

Adafruit Huzzah Temperature sensor

but instead of simply displaying the results on the serial console to have the results sent ot Azure and displayed in a graph.

The starting point was:

Quickstart: Connect an ESPRESSIF ESP32-Azure IoT Kit to IoT Central

problem was that the hardware device they use in this project is now obsolete it appears:

https://au.mouser.com/ProductDetail/Espressif-Systems/ESP32-Azure-IoT-Kit?qs=PqoDHHvF64%252BuVX1eLQkvaQ%3D%3D

Instead, I decided to use a:

SparkFun Thing Plus – ESP32-S2 WROOM

The hope being that it would be close enough to what the original document wanted.

Also for guidance and source files I used:

Connecting ESPRESSIF ESP32 to Azure IoT Central using the Azure SDK for C Arduino library

You should start here:

Getting started with the ESPRESSIF ESP32 and Azure IoT Central with Azure SDK for C Arduino library

which will take you through setting up a new IoT Central Application, which I won’t repeat here. The result of that will be 3 items that will need to be included in the code for the device:

ID scope
Device ID
Primary key

Next, you’ll need to download all the source files in the repo and include them in a new PlatformIO project. The files are:

AzureIoT.cpp
AzureIoT.h
Azure_IoT_Central_ESP32.ino
Azure_IoT_PnP_Template.cpp
Azure_IoT_PnP_Template.h
iot_configs.h

I renamed Azure_IoT_Central_ESP32.ino to main.cpp in my project.

The next thing you’ll need to do is set your local wifi parameters in the file iot_configs.h. The settings should look like:

// Wifi

#define IOT_CONFIG_WIFI_SSID “<YOUR LOCAL SSID>”

#define IOT_CONFIG_WIFI_PASSWORD “<YOUR WIFI ACCESS POINT PASSWORD>”

Make sure you save any changes to the files you make.

In this same file also locate and the set the Azure IOT Central settings like:

// Azure IoT Central

#define DPS_ID_SCOPE “<ID SCOPE>”

#define IOT_CONFIG_DEVICE_ID “<DEVICE ID>”

// Use device key if not using certificates

#ifndef IOT_CONFIG_USE_X509_CERT

#define IOT_CONFIG_DEVICE_KEY “<PRIMARY KEY>”

which need to include the values obtained when configuring Azure IoT Central earlier.

If you now build your code and upload it to the device you should find that it will connect to your local wifi and start sending information to Azure IoT Central.

The device configured in Azure IoT Central should report as connected as shown above when you view this in the Azure IoT Central portal at:

https://apps.azureiotcentral.com/

If you then select the Raw Data menu item as shown above, you see the data from your device being received regularly into Azure.

If you look at the serial monitor connected to the device locally you should see something like the above indicating that data is being sent up to Azure.

This, therefore, now indicates that there is a correct connection to the Azure IoT Central portal. The problem is that the data being sent currently is actually just static dummy data that never changes. What I want to do is send actual data read from a temperature sensor connected to my device. So I need to find the source of the data in the code so I can replace that with the dynamic data from the tempreture sensor connected to my device I want.

Turns out the source of that dummy data is in the file Azure_IoT_PnP_Template.cpp around line 236:

What I now want to do is replace the static value of 21.0 for temperature and 88.0 for humidity with actual readings from the device.

To achieve that I’ll need the code from the previous project that read the temperature data which is here:

https://github.com/directorcia/Azure/blob/master/Iot/huzzah-tempsens.ino

I’m going to add that to a new file in my project called ciaath.cpp to keep my code separate from the templated Azure stuff. In there I’ll have 2 functions:

float ciaaht_getTemp() which returns temp.tempreture

float ciaaht_getHumidity() which returns humidity.relative_humidity

Remember, both temp and humidity are objects and all I want is the actual numeric value in there.

I’ll also create a ciaath.h file that looks like:

#ifndef CIAATH_H
#define CIAATH_H
void ciaaht_init();
float ciaaht_getTemp();
float ciaaht_getHumidity();
#endif

The idea is that this tells other pieces of code about these functions. You’ll also note I have a function ciaaht_init() to initialise the temperature sensor at start up.

Back in the Azure_IoT_PnP_Template.cpp file I need to include the line:

#include <ciaath.h>

to tell it about my functions in my ciaath.cpp file. I can now also change the lines that report the temperature and humidity from their original static value to the value read from the temperature senor connected to my device to be:

static float simulated_get_temperature() { return ciaaht_getTemp(); }
static float simulated_get_humidity() { return ciaaht_getHumidity(); }

which basically get the data from my device which will then be sent to Azure.

Back in main.cpp I need to add:

#include “ciaath.h”

to tell it about my custom functions. I also have to add around line 359:

ciaaht_init();

to initialise the temperature sensor on my device at startup.

Once this all compiles and uploads to the device I can again check Azure IoT Central portal and see in the Overview menu item

and I see my temperature and humidity are no longer a constant.

If I heat up the temperature senor connected to my device I see:

and if I leave it to return to normal I see:

I’ve put all the code up at:

https://github.com/directorcia/Azure/tree/master/Iot/ESP32-S2/IoT-Central

so you can have a look and use it if you need to.

I did need to get some help along the way, especially with the code and working out where the values uploaded to Azure came from initially as well as how to structure the .h files to make it cleaner. I’m no coder but hopefully my explanation here helps other non-coder, but let me know if I haven’t got it right as I really want to better understand all this.

I’m now super happy I have this working and I’m confident that I can use this as a base to start creating more powerful projects connected to Azure!

New IoT device with a servo motor

I had a recommendation to move to a different IoT device to make connection to Azure and programming easier going forward. The recommendations was to use a:

SparkFun Thing Plus – ESP32-S2 WROOM

So the first thing I needed to do was get the right board selection working with PlatformIO. The end result of this was the need to use this platformio.ini file in the project:

[env:sparkfun_esp32s2_thing_plus]
platform = espressif32
board = sparkfun_esp32s2_thing_plus
framework = arduino

and you can look at this for further reference:

https://docs.platformio.org/en/latest/boards/espressif32/sparkfun_esp32s2_thing_plus.html#board-espressif32-sparkfun-esp32s2-thing-plus

Once I had the board being recognised and accepting uploads the next challenge was to execute some code. I went back to start and did the standard stuff I’d done with other devices like:

External flashing LED

but with the SparkFun Thing Plus – ESP32-S2 WROOM device instead. All of that is pretty straight forward on any device, so I won’t repeat the details here. What I though I’d cover off is something new on attaching a servo motor to the device.

The configuration is pretty simple as shown above. I used a:

SG92R Micro server motor

that basically has three connections – Power, Ground and Control as shown above.

I found some simple example code that I could use here:

Using Servo Motors with ESP32

I have also put all the code I’ve actually used for my ESP32-S2 device here:

https://github.com/directorcia/Azure/tree/master/Iot/ESP32-S2

I also needed to add the

ESP32Servo

library from Kevin Harrington to the project.

The code that I used to make the servo ‘sweep’ backwards and forwards is here for your reference:

https://github.com/directorcia/Azure/blob/master/Iot/ESP32-S2/servo.cpp

and here’s what it looked like when it ran on the device:

With this new device under control, it’s time to move onto bigger projects.

PlatformIO code compiles but fails to execute when uploaded

This is a really silly one but it tripped me up for far longer than I care to admit. In essence, the issues I was having is that I would successfully compile and upload my code in PlatformIO but for some reason it wouldn’t execute on the device. I tried many, many things, including a complete re-install of the environment to no avail.

The issue was that I was placing my code file at the root of the project file structure (where the red X is above) and not in the SRC directory (where the green tick is above). Thus, when I created a new project using PlatformIO, it created a new empty main.cpp in the SRC directory and was actually compiling that and uploaded that to my device. Because this default template effectively did nothing, the device looked as though it wasn’t working.

Without knowing this, I had create my code in a file, also called main.cpp, but at the root of the project structure that was never being compiled and uploaded! D’Oh!

Once I had my code in the main.cpp file in the SRC directory, it uploaded and executed on the device as expected. I probably should have read the PlatformIO documentation first:

PlatformIO IDE for VSCode

alas, I didn’t and thereby wasted hours trying to work out what was wrong! I’m glad that I’ve now worked it out and I’m sharing just in case someone else has the same issue, as I did spend heaps of time searching for a solution and found none that pointed out my error of file location.

Connecting to Azure IoT hub

The main aim of my dive into IoT was to get a remote device talking to Azure. After getting the IoT device connected to WiFi, flashing LEDs, accepting input from a button and capturing temperature data, it was now time to make that dream a reality.

There are different methods of connecting devices to Azure but for my first attempt I decided to use Azure IoT hub. The first step in that process is to login to the Azure portal and create a new IoT hub.

To do this, select the Create menu option in the top left of the Azure IoT hub blade

Once you have selected the Azure subscription and Resource group you’ll need to pick a Name for your Azure IoT hub. This name needs to be unique as a URL will be generated from this. Then select a Region and a Tier. You’ll notice that there is a Free tier, which I have selected for this example (very handy for tests like this).

Next, you can configure your networking. Because my device will just connect to a public Internet connection I selected Public access.

I left the management options as shown above.

The add-ons shown here are not available on the Free tier.

I didn’t need any tags.

I finally get a summary as shown. Note that the cost will be $0 because I am using the Free tier. Select Create to complete the process.

After a few minutes you should be able to see you IoT hub as shown above. Select Devices from the menu on the left.

Now select Add device from the menu on the right as shown above.

Give a the device a Name, and to keep things simple select Symmetric key for the Authentication type as shown. Ensure that the Auto-generate keys is select and that Connect this device to an IoT hub is set to Enable. Select Save to continue.

You should now see the device you just created listed as shown above. Select the name of the device to view it’s properties.

Here you will find the settings for your device. You’ll need to grab at least one Key and the matching Connection string to use when configuring your device.

With all of that information it’s time to head back and set up the device.

I have uploaded the code to get the device connected to Azure IoT hub here:

https://github.com/directorcia/Azure/blob/master/Iot/huzzah-iothub.ino

It is much more extensive that before and I will admit I am not yet 100% sure of what it all does but basically it connects the device to local Wifi then sends telemetry information to Azure IoT hub.

You’ll also need to have the file iot_config.h in the same directory when compiling your code. You can find an example of that here:

https://github.com/directorcia/Azure/blob/master/Iot/iot_configs.h

that file basically extracts all the unique security information like WiFi password, device keys and IoT Hub URL away from the main code. You’ll need to modify this file to suit your own environment before compiling.

The only other thing you’ll need to do is connect a single LED to pin 5 of the device to act as a diagnostic indicator. It will basically flash when data is sent to Azure IoT hub which gives a nice visual representation of something actually happening on the device.

When you compile the code you’ll also need to ensure all the appropriate libraries are available. Details of each of these is contained in the code.

With the compiled code uploaded to the device you should see the LED light start to flash after a few seconds indicating that data is being sent. If you look at the serial port you should see diagnostic data like so:

If you then look at the Overview page in the Azure IoT Hub you should the diagnostics reporting a number of messages increasing over time like so:

You can also download a tool called the Azure IoT explorer which you will find here:

https://github.com/Azure/azure-iot-explorer/releases

When you configure this for your IoT hub environment and drill down into the Device then Telemetry, as shown above, should allow to see the actual information being sent.

So there you have it. Once you have set up an Azure IoT hub and added a device to it you can grab the connection details and plug them into the code you use to configure your device. You can also use the Azure IoT Explorer to get more granular details of what your device is doing.

The next challenge is now to get the device working with Azure IoT central.