dewme

garybau said:

M4 512 Mac mini HDMI 27’ and USB-C 32’
set to energy saving
on wake up the 32” will not pick up the signal and requires on/off to get an active screen.
Been doing this since day one, swapped USB cables, altermnated HDMI connections, so it was then the 27” which didn’t start.

Both front and rear USB-C ports have been swapped..makes no difference.

so I just switch off screens, then on and no further issues..

It’s annoying though and consistent with other comments.
I hadn’t thought of ‘low energy’ setting though..that was in a previous comment I read in this forum today….

I recommend installing BetterDisplay trial version on your Mac mini. This app allows you to configure all of settings on monitors without having to mess around with the tedious on screen display (OSD). It will work with all connection types, for example, HDMI, DisplayPort, etc. The USB-C connected monitor is probably using DisplayPort 1.4. 

slm1972 said:

I don't have this issue with my M4 Mac Mini. I have an old Apple wired keyboard (A1243) with a crappy Dell wired mouse attached to it. The keyboard is then plugged into the front USBC port using a Ugreen USB hub (model:CM478). I have two monitors connected using the rear HDMI and USBC ports.

I am on Sequoia 15.1. 24Gb RAM and 512Gb storage.

This is my Energy settings.

I hope this helps others with their issues.

Yup, that’s the first place to start looking with USB issues that pop up during waking up your computer from sleep and even with certain energy saving features that kick in under certain conditions. I’ve see USB issues related to sleep and energy settings on not only Macs but Windows PCs as well. I remember one model of Dell laptops more than 15 years ago that required changing BIOS settings to keep the USB ports powered up when the computer went into energy saving modes. They are even more prevalent if you’re using a dock or hub, whether the dock/hub is connected via USB or Thunderbolt. I see this issue occasionally on USB thumb drives and SD adapters connected to USB ports on a TB3 hub on my M2 MacBook Air. Don’t forget that most wireless peripherals have their own power saving and sleep features too and those features can contribute to the problem. 

The USB protocol does have heartbeat/keep-alive like features to ensure the communication between the hub and connected devices is maintained when there is no traffic between them. These features (as of USB3) are power-saving aware and the bus can enter a suspended state after a period of no traffic. Connected USB devices that support these features are expected to periodically wake up and let the host know they are still there when they haven’t been using the bus for a while. The mechanism works differently on pre-USB3 compared to post-USB3 especially for low power features. When the host and device initiate a connection they negotiate all of the required bus settings for both ends including speed, power, polling rates (mice and keyboards), and suspend/resume timing. In theory there should be no issues at all once the connection is established. But that assumes both ends work correctly and there are no wiring or electrical issues.

mikethemartian said:

Is USB really a resilient interface? I recently worked a contract where test stations in production would often start reporting errors in the middle of the tests because some of the equipment was connected using USB and it would intermittently disconnect. This is compared to HPIB/GPIB which is old, bulky and slow but extremely robust.

Your gut feel is absolutely correct. GPIB/HPIB is intrinsically more reliable than USB. GPIB (IEEE-488) is a purpose-built parallel bus shared by up to 15 devices, one of which is the dedicated controller. The protocol, signaling, error detection, etc, logic is hardware based and data transfers are deterministic. It was designed for a different purpose than USB was designed for.

USB is a general purpose serial bus using a host controller (master) that orchestrates all of the communication between up to 127 nodes on each bus, including the controller itself, attached devices and hubs (slaves). Multiple USB busses can be connected together in a tiered topology, with each bus having it’s own controller. USB is not deterministic because communication is scheduled by the master, all devices on a bus share the available bandwidth, and messages are packetized so they must be marshaled and un-marshaled (reassembled) on both ends. However, USB has improved its bandwidth to such a degree since its inception that it can still be used in applications that need very high speed data transfers, e.g., streaming and isochronous control. You could say that in a fixed topology setup USB can be considered to provide bounded determinism, but not absolute determinism. It’s simply doing so much more than GPIB so there are more opportunities for errors.

modeseven said:

I once had a 27” aluminium body iMac with this exact problem. Random USB disconnect events affecting any USB attached storage drives. It only manifested itself over extended periods, like an initial time machine backup to an external USB disk. Incremental backups would rarely be affected. Hilariously, I spent ages trying to figure it out myself, to no avail, despite being computer literate and working in the Tech industry. I eventually emailed Steve Jobs about it, and then got great attention from a bunch of people at Apple. They never diagnosed the fault. Eventually, years later, I finally figured it out. I would occasionally get mild electric shocks from the aluminium chassis. I assume this was a design flaw, or some errant connection was being made because something had come loose inside and was making unintended contact within the chassis of the machine. It was some kind of electrical/earthing problem with my iMac. If you read around, USB is apparently quite sensitive to issues like earthing problems. My natural assumption was it was a software fault, but in the end I decided I had been barking up the wrong tree. My guess is this was either a hardware/design problem, or a faulty device off the manufacturing line, and an errant electrical contact was being made which was periodically affecting the operation of the USB bus.

Are you sure the mild electric shocks were not simply static electricity? Once the relative humidity gets below ~35% it’s not uncommon static electricity from your body to discharge to metal objects like your iMac.

 If there were a non-ground electrical connection inside your Mac touching the case of your Mac the power supply’s short circuit protection would cause the Mac to crash.

USB issues can be very difficult to diagnose at the system level. The best way to troubleshoot USB issues would be to use a hardware USB protocol analyzer/ sniffer. 

The Honeywell Thermostats I’ve had are certainly functional and reliable. Unfortunately I’ve had to switch mine out simply because the LCD screens are very difficult to read. Great for battery life, but readability for old farts is quite poor. Even my HVAC technician struggles with them and recommended I consider the one he has been using for a long time, the Ecobee. So far I’m very happy with the Ecobee.  

It’s very nice to see all the new HomeKit and Matter compatible devices hitting the market, but the more of them I get the more I realize how incomplete Apple’s Home app really is, especially with its canned automation logic. For example, there is no automation in Home to turn off a smart plug or smart light when a linked motion detector hasn’t detected motion for a specific period of time, say 60 minutes. I suppose some of the Home limitations like that one can be worked around using Siri Shortcuts, but so far it’s been much easier for me to just use Alexa Routines that happens to have that automation. 

Maybe it would be overkill, but if home automation really becomes a “thing” the Matter consortium should consider offering a potentially stripped down or home automation specific version of an IEC standard automation programming language like function block diagrams. This would make it a lot easier for prosumers and pros to get exactly what they want instead of being at the mercy of vendors all doing their own thing in a their own way. If it’s part of the Matter specification the same automations could be run on different vendor’s system solutions as long as they follow the Matter standard. This is exactly how standard and open programming languages like C/C++, Python, and Swift work. 

Better yet, still use a standard language but system vendors like Apple should come up with a way for consumers to describe the exact conditions for the automation/routine they need in human language and have AI generate the code to make it happen. User’s would not have to look at the code if they didn’t want to, but advanced users and system integrators could modify the generated code to fine tune it in some way.