[pre-release] macOS Monterey

[mnfesq]

3 hours ago, 5T33Z0 said:

@ombra88 In OpenCore's sample-custom.plist there's a field for the Board ID called "BoardProduct" under PlatformInfo > SMBIOS which is the equivalent to BoardID in Clover.

 

I take back what I said about OC's configurability.  I have not begun to memorize all of the options available in the sample-custom.plist and there certainly are many.  That said, the OC Configurator developers have Board Product filled out automatically when selecting an SMBIOS.  

[Tecnicaso Rico]

16 hours ago, ombra88 said:

I see and thank you for the info!! Unfortunately I’d like to make it work on OC 😕

OpenCore sets by default a specific board-id for every SMBIOS. But their is a work around to set your desire board-id without  interfering the PlatformInfo/Generic section.
Clone the OpenCorePkg repository: git clone https://github.com/acidanthera/OpenCorePkg.git
Edit AutoGenerated.c  with Xcode. This file is in: /OpenCorePkg/Library/OcMacInfoLib/AutoGenerated.c

 

 

And finally cd into the OpenCorePkg folder and run: ./build_oc_tool
An inconvenient with this method is the need to build  it again for every OpenCore update.
I wish OpenCore could select automatically the closest board-id when using the Platform/Generic mode.
For example: SMBIOS 17,1 has three different board-id's. One for i5-6500, another for i5-6600 and finally one for i7-6700K

Adding this feature will make OpenCore Generic SMBIOS selection more close to the the hardware being use and still being what it is: a generic solution.

 

 

[Guest 5T33Z0]

I have a Question regarding Board ID / Board Product. I have an Ivy Bridge Notebook (MacBookPro10,1) which can run BigSur (as MBP11,1) and Monterey (as MBP11,4 and patched in Drivers for the IntelHD4000). But as soon as I have to change the SystemProductName from MBP10 to MBP11, the CPU behavior changes: higher base clock, overall higher CPU useage and more fan noise because the CPU model used in MBP11 uses different board IDs and is tuned for CPUs of the Haswell Family. My workaround for this so far was to leave SystemProductName as MBP10,1 but use -no_compat_check.

 

Can't I just change the SystemProductName to MBP11,4 but use the Board ID of MBP10,1 instead to avoid this issue? Do I have to generate a new SMBIOS to fill out the fields of the SMBIOS section then?

 

EDIT:

 

So out of curiosity, I tested this in Clover (since it's easier to do): using an SMBIOS MacBookPro11,4 (Mac-06F11FD93F0323C5) with the BoardID for a MacBookPro10,1. (Mac-C3EC7CD22292981F). Unfortunely that didn't work (crossed-out circle). I guess the Board-ID is also checked for compatibility by macOS.

Edited September 9, 2021 by 5T33Z0

[Tecnicaso Rico]

3 hours ago, 5T33Z0 said:

I have a Question regarding Board ID / Board Product. I have an Ivy Bridge Notebook (MacBookPro10,1) which can run BigSur (as MBP11,1) and Monterey (as MBP11,4 and patched in Drivers for the IntelHD4000). But as soon as I have to change the SystemProductName from MBP10 to MBP11, the CPU behavior changes: higher base clock, overall higher CPU useage and more fan noise because the CPU model used in MBP11 uses different board IDs and is tuned for CPUs of the Haswell Family. My workaround for this so far was to leave SystemProductName as MBP10,1 but use -no_compat_check.

 

Can't I just change the SystemProductName to MBP11,4 but use the Board ID of MBP10,1 instead to avoid this issue? Do I have to generate a new SMBIOS to fill out the fields of the SMBIOS section then?

 

EDIT:

 

So out of curiosity, I tested this in Clover (since it's easier to do): using an SMBIOS MacBookPro11,4 (Mac-06F11FD93F0323C5) with the BoardID for a MacBookPro10,1. (Mac-C3EC7CD22292981F). Unfortunely that didn't work (crossed-out circle). I guess the Board-ID is also checked for compatibility by macOS.

It’s always recommended to use a SMBIOS as close as possible to your hardware specs. When using different board-id’s, these board id’s must be part of the SMBIOS being used. As mention before as an example,  iMac 17,1 has three different board-id’s so when using iMac 17,1 SMBIOS I should use one of those three board-id’s and not a board-id from a different SMBIOS.
People sometimes use a SMBIOS that doesn’t matches their hardware because they have different priorities (Like having full VDA Decoder support) but they get away from Power Management problems with the help of CPUFreind. There is also an interesting scenario where two different board-id’s are being used at once, and it’s with the Wonderfull magic perform by the WhateverGreen kext. This kext can spoof a different board-id only to the video section for full VDA Decoding purposes without changing the main board-id being used by macOS.
So finally when switching between different SMBIOS’s don’t mix board-id’s, just get away of Power Management problems with the help of CPUFreind.

[Slice]

36 minutes ago, Tecnicaso Rico said:

It’s always recommended to use a SMBIOS as close as possible to your hardware specs. When using different board-id’s, these board id’s must be part of the SMBIOS being used. As mention before as an example,  iMac 17,1 has three different board-id’s so when using iMac 17,1 SMBIOS I should use one of those three board-id’s and not a board-id from a different SMBIOS.
People sometimes use a SMBIOS that doesn’t matches their hardware because they have different priorities (Like having full VDA Decoder support) but they get away from Power Management problems with the help of CPUFreind. There is also an interesting scenario where two different board-id’s are being used at once, and it’s with the Wonderfull magic perform by the WhateverGreen kext. This kext can spoof a different board-id only to the video section for full VDA Decoding purposes without changing the main board-id being used by macOS.
So finally when switching between different SMBIOS’s don’t mix board-id’s, just get away of Power Management problems with the help of CPUFreind.

If for example iMac17,1 can have three different board-id then it can have four them.

[Guest 5T33Z0]

37 minutes ago, Tecnicaso Rico said:

It’s always recommended to use a SMBIOS as close as possible to your hardware specs. When using different board-id’s, these board id’s must be part of the SMBIOS being used. As mention before as an example,  iMac 17,1 has three different board-id’s so when using iMac 17,1 SMBIOS I should use one of those three board-id’s and not a board-id from a different SMBIOS.
People sometimes use a SMBIOS that doesn’t matches their hardware because they have different priorities (Like having full VDA Decoder support) but they get away from Power Management problems with the help of CPUFreind. There is also an interesting scenario where two different board-id’s are being used at once, and it’s with the Wonderfull magic perform by the WhateverGreen kext. This kext can spoof a different board-id only to the video section for full VDA Decoding purposes without changing the main board-id being used by macOS.
So finally when switching between different SMBIOS’s don’t mix board-id’s, just get away of Power Management problems with the help of CPUFreind.

 

I know that. I use an i7 3630QM while Board-ID C3EC7CD22292981F is for a 3615QM… can't get any closer than that.

 

My point was to use this ID for SMBIOS MBP11,4 as well. But since this ID isn't allowed in/supported by macOS Monterey this leads to the crossed-out circle. I have a working SSDT-PM, but when switching to another SMBIOS which is based on newer CPU family it's no longer as efficient since this SMBIOS is for Haswell. As far as I know, CPUFriend can only be used for CPUs which support XCPM which IvyBridge doesn't in current macOS. I patched it in once for testing and it didn't perform well, so that's that.

[Guest 5T33Z0]

14 hours ago, mnfesq said:

 

I take back what I said about OC's configurability.  I have not begun to memorize all of the options available in the sample-custom.plist and there certainly are many.  That said, the OC Configurator developers have Board Product filled out automatically when selecting an SMBIOS.  

 

EDIT: Don't forget to tick the check boxes "Add this section in config.plist" before saving. I forgot to do that first and I was wondering why all the sections were missing from the confi.g

Edited September 9, 2021 by 5T33Z0

[ombra88]

I think that soon they are probably gonna fully address the compatibility hw issues with the OC legacy patcher. iMac 15,1 was added as well. https://dortania.github.io/OpenCore-Legacy-Patcher/MONTEREY-DROP.html#newly-dropped-hardware 

[mnfesq]

3 hours ago, 5T33Z0 said:

 

I know that. I use an i7 3630QM while Board-ID C3EC7CD22292981F is for a 3615QM… can't get any closer than that.

 

My point was to use this ID for SMBIOS MBP11,4 as well. But since this ID isn't allowed in/supported by macOS Monterey this leads to the crossed-out circle. I have a working SSDT-PM, but when switching to another SMBIOS which is based on newer CPU family it's no longer as efficient since this SMBIOS is for Haswell. As far as I know, CPUFriend can only be used for CPUs which support XCPM which IvyBridge doesn't in current macOS. I patched it in once for testing and it didn't perform well, so that's that.

 

I thought this was the exact purpose for CPUFriend.kext/CPUFriendDataProvider.kext.  You can use a different board for power management than the one that is designated for your SMBIOS.  I use it to get many more P-States for speed-stepping.

Edited September 9, 2021 by mnfesq

[Guest 5T33Z0]

10 minutes ago, mnfesq said:

 

I thought this was the exact purpose for CPUFriend.kext/CPUFriendDataProvider.kext.  You can use a different board for power management than the one that is designated for your SMBIOS.  I use it to get many more P-States for speed-stepping.

 

Yes, you can do that – if it supports XCPM. Otherwise you have to use ssdtPRGen.

[sonicthehedgehog2]

On 9/8/2021 at 10:45 AM, ombra88 said:

When I tried If I am not mistaken the smbios needed to run both r9 290x and iGpu with Haswell is not supported by monterey

Opencore works on my i7 3770 as a Mac Pro 6.1 (as recommended by the dortania guide). I’m using Clover running the beta 6 Monterey public preview. I’m using an external graphic card so I can’t comment further.

Edited September 12, 2021 by sonicthehedgehog2
Auto correct

[WizeMan]

Anyone having sleep issues with Monterey?

 

pmset -g log|grep -e " Sleep  " -e " Wake  "

2021-09-09 08:08:26 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 18 secs   
2021-09-09 08:09:29 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:10:33 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 08:11:35 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 20 secs   
2021-09-09 08:12:40 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 18 secs   
2021-09-09 08:13:43 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:14:47 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 18 secs   
2021-09-09 08:15:50 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:16:54 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 08:17:56 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:19:00 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 18 secs   
2021-09-09 08:20:03 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:21:07 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 08:22:09 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:23:13 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 18 secs   
2021-09-09 08:24:16 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:25:20 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 08:26:22 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:27:26 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 18 secs   
2021-09-09 08:28:29 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:29:33 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 08:30:35 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:31:39 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 18 secs   
2021-09-09 08:32:42 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:33:46 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 08:34:48 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:35:52 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 08:36:54 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 20 secs   
2021-09-09 08:37:59 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 08:39:01 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 20 secs   
2021-09-09 08:40:06 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 08:41:08 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 25 secs   
2021-09-09 08:42:18 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 08:43:20 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:44:24 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:45:28 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:46:32 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 08:47:34 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:48:38 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 18 secs   
2021-09-09 08:49:41 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 08:50:45 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 18 secs   
2021-09-09 08:51:48 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 14 secs   
2021-09-09 08:52:47 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 18 secs   
2021-09-09 08:53:50 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 1036 secs 
2021-09-09 09:11:51 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 09:12:55 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 09:13:59 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 09:15:01 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 09:16:05 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 18 secs   
2021-09-09 09:17:08 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 928 secs  
2021-09-09 09:33:21 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 20 secs   
2021-09-09 09:34:26 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 09:35:30 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 09:36:32 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 997 secs  
2021-09-09 09:53:54 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 18 secs   
2021-09-09 09:54:57 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 20 secs   
2021-09-09 09:56:02 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 17 secs   
2021-09-09 09:57:04 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 19 secs   
2021-09-09 09:58:08 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep':TCPKeepAlive=active Using AC (Charge:0%) 18 secs   

 

Sleep was working perfectly on macOS Big Sur, but since installing Monterey it doesn't. I haven't changed any sleep related settings, it was working with these (and yes, power nap was working great):

PS I have 3200Mhz RAM but I have under clocked it @ 2666Mhz.

 

[eSaF]

@WizeMan - Hi Bro look in System Preferences/Sharing and deselect all the tick boxes there because that is where the readout '(sleep prevented by coreaudiod, sharingd, bluetoothd)' is pointing then test sleep again. I had this exact problem with Sleep in Monterey and that solved it, this tip is also mentioned on Apple Forum. Good luck.

[WizeMan]

13 hours ago, eSaF said:

@WizeMan - Hi Bro look in System Preferences/Sharing and deselect all the tick boxes there because that is where the readout '(sleep prevented by coreaudiod, sharingd, bluetoothd)' is pointing then test sleep again. I had this exact problem with Sleep in Monterey and that solved it, this tip is also mentioned on Apple Forum. Good luck.

 

Thanks my main man, it seems like everything is already unchecked.

 

I am afraid Handoff could be causing this:

 

 

I disabled Handoff  but the problem persists.

 

pmset -g log|grep -e " Sleep  " -e " Wake  " -e  " DarkWake "

2021-09-13 10:29:41 +0300 Sleep               	Entering Sleep state due to 'Software Sleep pid=192':TCPKeepAlive=active Using AC (Charge:0%) 26 secs   
2021-09-13 10:30:07 +0300 DarkWake            	DarkWake from Normal Sleep [CDNP] : due to PEG1 PEGP PEG2 PEGP PXSX RP10 PXSX RP11 PXSX RP12 PXSX RP13 PXSX PXSX RP02 PXSX RP03 PXSX RP04 PXSX RP05 PXSX PXSX PXSX RP18 P/Network Using AC (Charge:0%) 36 secs   

 

Edited September 13, 2021 by WizeMan

[eSaF]

22 minutes ago, WizeMan said:

Thanks my main man, it seems like everything is already unchecked.

Hi Bro another method to try, in System Preferences/Energy Saver disable 'Wake for network access' if enabled.

[WizeMan]

1 minute ago, eSaF said:

Hi Bro another method to try, in System Preferences/Energy Saver disable 'Wake for network access' if enabled.

 

Was about to write that. That's what I disabled and it worked! Thanks mate, I have no idea how it used to worked earlier. Maybe upgrading to Monterey enabled this setting automatically!

[eSaF]

@WizeMan I know I don't have to tell you this but just incase you overlooked it also check the 'Power' tab in 'Hackintool' to make sure all is stable (see attached).

Spoiler

 

[WizeMan]

3 minutes ago, eSaF said:

@WizeMan I know I don't have to tell you this but just incase you overlooked it also check the 'Power' tab in 'Hackintool' to make sure all is stable (see attached).

  Hide contents

 

 

I already did this "fix" from Hackintool after upgrading because I know such major updates reset these settings to default, it seems like I just missed "wake for network access" Thank you @eSaF !

[eSaF]

Just now, WizeMan said:

Thank you @eSaF

 Any time my friend 

[Slice]

On 9/13/2021 at 10:47 AM, eSaF said:

Hi Bro another method to try, in System Preferences/Energy Saver disable 'Wake for network access' if enabled.

I have it enabled.

2021-09-15 08:29:53 +0300 Sleep               	Entering DarkWake state due to 'Software Sleep pid=172': Using AC (Charge:0%) 3 secs    
2021-09-15 08:29:56 +0300 Wake                	DarkWake to FullWake from Invalid [CDNVA] : due to HID Activity Using AC (Charge:0%) 7 secs    
2021-09-15 08:30:03 +0300 Sleep               	Entering DarkWake state due to 'Software Sleep pid=172': Using AC (Charge:0%)           
2021-09-15 08:30:18 +0300 Sleep               	Entering Sleep state due to 'Software Sleep pid=172': Using AC (Charge:0%) 7205 secs 
2021-09-15 10:30:23 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep': Using AC (Charge:0%) 7206 secs 
2021-09-15 12:31:16 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep': Using AC (Charge:0%) 7205 secs 
2021-09-15 14:31:21 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep': Using AC (Charge:0%) 7206 secs 
2021-09-15 16:32:13 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep': Using AC (Charge:0%) 7205 secs 
2021-09-15 18:33:04 +0300 Sleep               	Entering Sleep state due to 'Maintenance Sleep': Using AC (Charge:0%) 5267 secs 
2021-09-15 20:00:51 +0300 Wake                	Wake from Normal Sleep [CDNVA] : due to XDCI/UserActivity Assertion Using AC (Charge:0%) 5678 secs 
2021-09-15 21:35:29 +0300 Sleep               	Entering Sleep state due to 'Idle Sleep': Using AC (Charge:0%) 268 secs  
2021-09-15 21:39:57 +0300 Wake                	Wake from Normal Sleep [CDNVA] : due to XDCI/UserActivity Assertion Using AC (Charge:0%)     

 

[eSaF]

1 hour ago, Slice said:

I have it enabled.

And Sleep is stable without intermittent Wakes in between? If I have 'Wake for Network access' enabled the machine wakes periodically specially during the night and then sleeps again which can be annoying I think is a deliberate action by Apple (not absolutely certain) but I have it disabled and machine sleeps until I wake it with mouse click or keyboard.

Edited September 15, 2021 by eSaF

[Slice]

6 hours ago, eSaF said:

And Sleep is stable without intermittent Wakes in between? If I have 'Wake for Network access' enabled the machine wakes periodically specially during the night and then sleeps again which can be annoying I think is a deliberate action by Apple (not absolutely certain) but I have it disabled and machine sleeps until I wake it with mouse click or keyboard.

May be you means PowerNap?

[eSaF]

@Slice - This is how my Energy Settings are without any Sleep problems as this but will experiment some more and report.

Spoiler

 

[eSaF]

@Slice Ok I have now selected 'Wake for Internet access' Sleep Cycle seems to be unaffected but will have test over a longer period to see if it wakes during the night as before. Will report findings.

Spoiler

 

[Slice]

"wake during the night" is PowerNap which is checked for you.