Hi, thanks!
What happens during a cronjob is that it looks for SMART activity. The way it works is that it request which state the drive is in before it pulls out the rest of the SMART data. If the drive(s) reports a typical spinning state (ACTIVE/IDLE), then it will request all SMART data from that drive. If this for some reason fails, or the HBA expander always says the drive is ACTIVE/IDLE regardless the real state of the HD, it looks like it will then wake up the drive to get the SMART data.
But I'm not sure about this and I'm not sure how to really test this further. Maybe there's some special SMART override configurations for the HBA controller if it has a BIOS to prevent it from waking up when SMART is requested? Or maybe SMART is getting disabled, overridden or ignored?
You can check if you trigger the messages from dmesg via these commands:
Check SMART activity, will (should) only post results if the drive is either ACTIVE or IDLE:
smartctl -n standby /dev/<device>
Output should be something like "Device is in IDLE_B mode". If this line is missing, it is detected as standby or sleep (non-spinning).
If the drive is detected as ACTIVE or IDLE, then the cronjob will go on and get the rest of the SMART data with this command (except it will get them via --json in the script):
smartctl -n standby -x /dev/<device>
One or both of these command is probably what causes your messages to happen, and be sure to check if the SMART data seems to be correct and not something the controller "makes"