Happy Thanksgiving, for those who celebrate.

Whenever there's a new, major release, there's an inevitable set of problems that weren't caught during testing (even the long public beta). We've got those mostly taken care of in the new 3.3.1 update, released today.

Most users having problems are running macOS 10.10 or 10.11. Here's the list:

• 10.10 users had an immediate failure with a dyld error due to a release build mess-up on our side. In addition, on some systems, there was a digital signature validation issue. We've corrected both in this update.
• Users with unusual characters in their drive names (eg "ø") were getting errors on all OS versions. This should be fixed.
• There was a problem with drive names with quote marks in them (eg "Fred's MacBook Pro 17" Backup"). Fixed.
• Read-only images would sometimes generate a symbol substitution error. Not any more.

There's one remaining issue for 10.10 and 10.11 users: Erase, then copy backups are failing due to some unexpected "volume transformation" events that are occurring. When we validate the result, we're being quite cautious, and we're not seeing what we expect, so we fail the copy.

That isn't yet fixed, because it's going to take some very careful investigation and, well, Thanksgiving. The workaround is to use Smart Update. If you need to erase, you can erase with Disk Utility, and then run Smart Update.

If you are unregistered, need to run a backup on macOS 10.10 or 10.11, and you're running into this issue, you can Download v3.2.5 here.

The update is available through the normal built-in updater, or you can...

Download v3.3.1

OK, back to celebrating with the family. Enjoy, everyone.

I'm happy to announce the release of v3.3 of SuperDuper, our fully Catalina-compatible version: happier, perhaps, then even you are in reading the news. It's available via the normal update mechanism, or by downloading it from the web site.

Everyone with a Beta version installed will get an update notice for this version as well.

Note: after SuperDuper! 3.3 is installed, if you keep getting prompted for Full Disk Access, you need to restart your Mac. Welcome to Windows 95!

Roads, Long: See Island Destinations

The process of getting to a final version took longer than I hoped it would, but for good reason: once again, Apple has made some pretty radical changes to the way things are stored on your drive, and we didn't want to release a final version—a version that would be installed by "everyone"—without getting extensive test coverage in "real world" situations...that is, setups other than our own test setups and real-world "developer" systems.

Testing has gone really well, and the broader coverage has provided us with some cases that we wouldn't have normally seen: broken systems, leftover volumes from bad OS updates, generally weird behavior with early Catalina releases.

So, thanks to everyone who participated in the public beta: your reports, feedback and encouragement helped create a better final release of v3.3.

What's Changed?

The whole idea of the new version is, if we did our job right (and I think we did), things should just work the way you expect them to. You'll notice a bunch of little things here and there that clarify things, or parts that work more smoothly than before. But overall, it should feel like SuperDuper always has.

But despite that, SuperDuper is doing a lot more things. Catalina has made some radical changes to the way your files are stored, and it's important to know what's going on "behind the scenes".

You may notice, during your first copy, that there's a new step in the Status View: Copy System Files, which will sometimes precede Copy Files. Why is that?

Catalina divides your drive into two volumes (which is what we've been working all spring, summer and fall to support properly). A read-only "system" volume, and a read/write "data" volume.

Things you are allowed to write to, in general, are on the Data volume. Things you can't (the OS, Apple's applications) are on the System volume.

Before Catalina, I often told users that they didn't "own" most of their drive: the vast majority of it was owned by Apple, or rather macOS. You only really "own" your Home folder, in /Users, and the applications you install. (Yes, yes, I know about /usr/local, etc, but work with me here.)

Catalina now formalizes that concept beyond just Unix permissions and SIP-protected locations. The stuff you "own" is now on the Data volume. The System volume is off-limits. For good.

Both macOS and SuperDuper "hide" the details of this from you by tying the two volumes together into a single "Volume Group". You actually start up from the System volume, and the Data volume is connected to it using a new file system feature called "firmlinks".

The details here are unimportant to the user, but the reason you'll occasionally see strange things (like, when you eject a backup drive in Finder, it may tell you there's more than one volume), or extra steps in our Status view, are because of this new setup.

So, your first copy will convert your destination into these two volumes and copy each source to its corresponding destination. We then do what's needed to "tie them together" using firmlinks so they work as one.

Note, though, there's one big benefit: subsequent Smart Updates will not copy the system volume if it's already up to date, which speeds things up quite a bit!

Forced March

Changes like those introduced in the last few OS versions have been frustrating, because they've meant we've had to spend most of our engineering time simply maintaining compatibility with the changes Apple is forcing on all of us.

Not only has the last three years introduced a new file system (APFS), it tightened "security" in a way that broke automation, and then, as I explained above, radically changed the way system and data files are stored on a drive, splitting them into multiple volumes...while hiding those facts from the user.

Until the curtain parts, and they suddenly don't understand what's going on.

Each one of these changes required very significant investigation into under-to-un-documented parts of the system, months-long checks of assumptions, followed by writing a ton of new code, and then extensive testing of all that stuff on both current and older OS versions to ensure we've maintained compatibility with the platforms we support.

And that takes time. Time we'd rather spend implementing new things.

Yes, it's our job. And as long as Apple keeps yanking the rug out from under applications like ours, we have to continue to move, as fast as we can, to wherever the new floor covering lands.

But doing that kind of thing every year is bad for everyone. It's bad for developers, like us, because it means we're constantly chasing the ball. It's bad for users, like us, because it breaks their software (this year more than most), and gives them a less stable system that doesn't let them get their work done, or requires them to replace working software with new software: software that they then have to learn all over again.

On top of that, there are background murmurs suggesting another platform shift, to ARM processors. Because it might give us slightly faster Macs, with slightly better battery life.

So more hoops. More time spent doing things other than the things we really want to do.

This isn't an argument against progress. We all benefit from forward momentum: real security and functionality improvements are valuable and welcomed.

But constantly changing a platform in ways that break compatibility, or confuse users, or make their data less safe and secure stops that progress. We all spend the year between the releases trying to catch up with the latest change, without actually being able to spend time reaping the purported benefits.

It can be frustrating. But it's the way it is, right now.

It doesn't have to be. We can make progress without jerking everyone around. Security can be improved without subjecting users to confusing prompts and bad UX. New APIs can be built without forcing users to throw away software and hardware they've been depending on for years.

Respecting users must also recognize the fact that they have a significant investment in their software and peripherals, let alone their Mac. Just because someone can't afford to purchase new hardware, or needs to maintain compatibility with an old scanner or printer, or really likes what they have...that shouldn't be reason enough to leave them behind. They shouldn't have to add their perfectly good gear to a landfill.

Climbing Off the Soapbox

With that off my chest, I hope you all enjoy the new version of SuperDuper. We've put a lot of love and care into it, and I think you'll find it works exactly as you'd hope it would.

Have at it, and thanks for being a SuperDuper user!

Not much to say about this build: we've fixed a bunch of things, basically. The vast majority of users had success with the last beta. But:

• Some had schedules that would fail right at the start, with a collapsed window. Fixed!
• Copies to HFS+ volumes would fail to copy recovery in some cases. Also fixed!
• Eject would sometimes not eject both volumes of a volume group. Can you believe it? Fixed!
• Some systems have a broken installation of Perl and xpath, which we detect. But that detection was broken. We fixed it!
• If you had just set up a bunch of scheduled copies to locked volumes, we were only preauthorizing against the keychain for the first one. I bet you can guess: fixed!
• Various other things. Fixed!
• Some people were impatient and didn't realize HFS+ to APFS conversion might take a while! We now tell them to get a tasty beverage! Which isn't so much "fixed!" as "indicated to them that patience is a virtue".

Yeah, like I said. Things are in good shape. We're busily making sure all the various panel gaps are even.

Keep reporting the things you find...until then, download away, install and enjoy.

Download SuperDuper! 3.3 B6 (v119.7)

Beta updates are rolling along. We've incorporated a number of fixes for additional edge cases, polished some behavior, worked around some OS issues...the usual.

We've had a number of people ask whether it's "safe" to run these betas.

Now, barring the occasional, rapidly-fixed "goof" (eg the bless error we fixed in Beta 4), every beta version we release is basically "production ready". They're "betas" because we're dealing with a new OS that's changing rapidly, and we want to ensure we've covered all the cases we didn't think of before we do a general release.

Prepare for Boredom

For example, this version has an "automount" fix in it. As I've discussed previously, sdautomatedcopycontroller is used to run "automatic" copies. Those include scheduled copies, copies users can run from the command line or their own tools, etc.

sdautomatedcopycontroller (every time I type that I think why didn't I make this name shorter) handles the detail of automatically mounting source and destination volumes, and setting them up to eject when the copy is complete.

With volume groups, though, there are two potential volumes to mount...but keychain passwords might be under either the Data volume or the System volume, depending on what the user does. Previously, we were only looking under the System volume name...now we check both.

Not Boring Enough? Try This!

Another example: on some user systems, certain macOS command line tools that are written in Cocoa or Swift would output loader warnings as errors (on stderr), and so we'd think they failed. We now handle more of those cases, if the tool otherwise is successful.

Short and Sweet

So, yeah. These are little fixes that cover cases that come up in broader testing...and are examples of why these betas are "safe". These fixes just aren't things most people are going to notice.

Again, thanks for your feedback: your reports are making SuperDuper! 3.3 better for everyone!

Download SuperDuper! 3.3 Beta 5 (v119.6)

Yeah, well, sometimes a change to the install process that shouldn't have any effect on anything else...does.

Beta 3 gave an error when using bless to bless the drive. The underlying issue was code we have that needs to ignore certain types of output on stderr that aren't actually errors. (For example, the EFI fix that I describe in this blog post produces an error that isn't actually an error–we know it's going to fail in a specific way).

The unexpected part is that just before the beta, we made a change to the installer to try to improve our workaround for systems that required rebooting post-install to make Full Disk Access work. After we made the change, we didn't re-run the full suite of tests because we (incorrectly) thought the change was isolated to the install process.

However, it was made in a runtime element that was shared with the way we executed bless. We didn't take that into account, and should have re-run all the tests.

The backups themselves are fine (and are even bootable, even though there's an error issued). Beta 4 fixes the false error indication: once installed, bless will not give a false failure.

Sorry about that. Beta. >sigh<

Download SuperDuper! 3.3 B4 (v119.5)

Third time isn't a charm; you'll note a bless error at the end of copies. We'll have a new beta Sunday that fixes this dumb goof.

(For the impatient - scroll down and you can download Beta 3 at the bottom of this post. Note that existing betas will, as always, automatically update.)

Well, we've reached the critical Beta 3 phase, where we think we've dealt with all the issues reported, save for one or two stragglers we're trying to figure out.

Mostly Beef, Some Filler

Overall, things are pretty solid. We tightened up some of the image and encryption handling, which affected some users (and provided interim betas to those who got in touch to confirm our fixes). There were some problems with volumes being ejected at the end of scheduled copies under Catalina that were fixed, as well as some related issues with auto mount (also only under Catalina).

Pretty minor stuff.

Mystery Meat

We've got a few users whose systems are in a bizarre state where the loader is outputting

dyld: warning, LC_RPATH @executable_path/Frameworks in /System/Library/PrivateFrameworks/TelephonyUtilities.framework/Versions/A/TelephonyUtilities being ignored in restricted program because of @executable_path (Codesign main executable with Library Validation to allow @ paths)

when we run certain system command-line tools. It's happening to a very small number of users, but for those users, neither rebuilding their dynamic libraries nor reinstalling their version of Catalina (current public release) fixes the problem.

We were able to reproduce the problem, once, with a non-admin user under the current public release, and it fixed itself after installation of the current developer preview, but given we can't reproduce it again, even with the public release, we're not entirely sure what weird system thing is going on here: we just know it's not good.

If this is happening to you, get in touch.

Certified Fresh

We also added a diagnostic that detects a rare situation where a user's system has broken scripting tools (like a bad Perl install), which can cause problems. Again, rare stuff.

Piping Hot Chinchilladas

But, apart from those relatively minor kinds of things, Beta 2 worked well. And Beta 3 should work even better.

Once again, thanks for your patience and support. Enjoy!

Download SuperDuper! 3.3 Beta 3 (v119.4)

As always, a download for the new beta is at the bottom of this post, and if you're uninterested in the changes, you should just scroll down a bit (or, if you have a previous Beta installed, launch SuperDuper and it will offer the update).

Beta 1 - Worked Well!

We had a lot of people download and run the new beta, and a gratifyingly small number of problems, which is always a good sign.

That doesn't mean nothing was wrong with it, of course. A developer's job is never done, and the only program with no bugs in it is, well, theoretical. And hey, it's a Beta—the whole point is to get broader testing so we can fix any problems we missed internally.

So thanks to everyone who wrote in with success and failure reports.

Small Issues

The first beta had some relatively rare problems:

1. If there was a space in the path to SuperDuper, we'd give a weird error in the log and fail.
2. The versions for some of our launch agents weren't set properly, so they'd get reloaded on every SuperDuper launch.
3. On some user systems, Full Disk Access doesn't take after install, and they have to restart after installing the new version. This is because our bundle ID has changed due to notarization and the OS doesn't handle it well. We did our best to try to get it work, and it does for most. One time issue for those it happens to.

Larger Issues

And a few larger issues:

1. Disk image backups would fail when copying source volumes with snapshots enabled.
2. Some valid scheduled copies would fail to run under Catalina.
3. In some circumstances, ownership wouldn't be properly enabled for the system volume of an external Catalina volume group, which made the backup not boot.

Sea of Memories

I could go into detail on the latter problem, but rather than bore you, I'll refer you instead to this old post from 2005 (14 years ago oh god I have been doing this for too long shut up inner monologue i am trying to type here no you shut up) where I discuss the general issue.

The new Beta resolves this issue. Note, though, that SuperDuper doesn't copy the System volume if it's not a different version. So, there are two options if your backup doesn't start up as expected:

• Navigate to /System/Library/CoreServices on the backup drive and remove SystemVersion.plist. The easiest way to do this is to use Finder's Go To Folder command, in the Go menu, and enter:

  /Volumes/your-backup-volume/System/Library/CoreServices

  Substituting your actual backup volume name for "your-backup-volume". Then, remove SystemVersion.plist. When you run the new version of SuperDuper, it'll fix all the files without recopying their data, and you should be all set.

• Alternatively, you can do an erase-then-copy backup rather than a Smart Update.

That wasn't too painful

See? When I'm tired I can't ramble on as much (yes you can you're rambling now shut up i said inner voice shut up shut up).

Note that if you don't have drives selected in the source and destination pop-ups, the internal updater won't work. Either select drives or download and install manually.

Thanks again to everyone who provided feedback, and an extra tip of the pocket to Ben, Sydney, Mathieu, Jeff, Gary and Norman for their reports and testing help.

Download SuperDuper! 3.3 Beta 2 (v119.3)

As promised, at the bottom of this post is a link to our Catalina beta.

A very dramatic announcement! (Also, see https://t.co/2mDlY6LUfu for details.) pic.twitter.com/AUFtTuesUh

— Dave Nanian (@dnanian) October 18, 2019

This post is mostly a just-the-facts-ma'am discussion of changes in Catalina that have affected us and may affect you. Details of our journey may come later, when I'm in a more narrative mood.

This version has been a long time coming, and while we hoped to have a beta during Catalina's development, we really didn't like the stability of Catalina during the process. Many things involving the drive setup were changing and being reworked as the summer wore on.

Rather than put out something that was at the mercy of the underlying system, whose release process we couldn't control or predict, we decided to hold off until the real release. Once that was out, we finalized our testing, and now we're putting the public beta into your waiting arms/hands/drives/computers...whatever metaphor here is appropriate.

Drives are Different

Apple's intention is to hide the details, so it's possible you didn't notice, but in Catalina APFS drives are now quite a bit different than they were before. Let's just do a quick refresher of how we got to where we are now.

Stage 1

macOS started out with pretty "standard" Unix-style protections. Permissions and ownership were used to establish what you could or couldn't do with a file. The "super user" could override those permissions, so while you were normally denied access to "system" files, a little "permission escalation" allowed you to modify anything you wanted.

And, since "you" could modify anything with a little work, so could something that had unkind intent.

Stage 2

In 10.4, Apple added ACLs, which are more fine-grained "Access Control Lists": super detailed permissions for files and folders that can be inherited. Most people aren't aware these exist, but they're super handy.

Stage 3

The next step was adding a special attribute ("com.apple.rootless") that caused the file system driver to "protect" certain files on the drive.

That caused some initial consternation that I documented on this blog, because Apple "overprotected" the system, even when it wasn't the startup drive. Fortunately, before shipping, they fixed that problem, and copying worked as expected.

Stage 4

Next came System Integrity Protection (SIP), which took that concept and extended it to some user files as well. Some areas of the drive couldn't even be viewed, let alone copied, but with certain types of authorization (like Full Disk Access), copying could be done.

Stage 5

And now we're at Stage 5, which is either denial or acceptance. I forget, but basically this is where the entire system has been made read-only, and placed on its own, separate volume.

It doesn't look that way in Finder: everything seems like it was. But behind the scenes, two separate volumes have been created. Your files, and dynamic system files, are on a new "Data" volume. The system is on its own "System" volume. And they're stitched together with "firmlinks", a new, system-only feature that makes two volumes look like one at the directory level.

Make this invisible

Again, Apple has tried to make this invisible, and for the most part, that's what they've done. And we've tried to do the same.

In SuperDuper, you won't notice any changes for the most part. But behind the scenes, we've made a lot of modifications:

• In order to replicate this new volume setup, system backups of APFS volumes must be to APFS formatted volumes. SuperDuper automatically converts any HFS+ destinations to APFS volumes for you (after prompting), so you won't have to do anything manually in most cases.
• Any existing APFS volumes are properly split into these new Data and System volumes. If your backup was previously called "Backup", your files are now on a volume called "Backup - Data". The read-only system volume, which contains Apple's files, is called "Backup". These volumes are now set up in a "volume group". Again, all this is done for you, and we hide the details...but if you see some new volumes, you now know why.
• And because of this, a single copy is really two copies: the system volume (when unmodified) and the data volume (where your stuff resides)
• Those two volumes are further linked together with "firmlinks", which tunnel folders from one volume to the other in a way that should be transparent to the user. But they can't be transparent to us, so we had to figure out how to recreate them on the copy, even though there's no documented API.
• Plus, we've needed to make sure we do the right thing when you copy from a regular volume to something that was previously a volume group, intuiting what you mean to do from your copy method.
• I really could go on and on and on here. It certainly felt endless during the process!

Yeah, no matter how much one might long for turtles, it's hacks all the way down.

Seriously, though, this is the kind of thing that requires an enormous amount of testing—not just tests of the program, but testing during development as well. One "little" change that totaled about 10 lines of code required over 1000 lines of unit tests to verify proper operation. And that's just one internal change.

Except when you can't.

Despite our efforts, the new setup means some adjustments must be made.

• You can't turn an already encrypted APFS volume into a volume group. As such, you'll have to decrypt any existing bootable volumes. Once you've backed up, you can boot to that backup, turn on FileVault, and boot back. Subsequent Smart Updates will maintain the encryption.

That doesn't mean you have to back up critical files to an unencrypted volume. If this is important to you (HIPAA or similar requirements are often quite strict about encryption), create a separate account called, say, Intermediate. Use a SuperDuper copy script to exclude your normal User folder (where the critical data is - for example, /Users/dnanian - see Help > User's Guide for a detailed discussion of Copy Scripts). Then, use that new script in "using" to back up to the unencrypted volume.

Start up from the unencrypted volume and log into Intermediate. Turn on FileVault.

Now, start back up from the regular volume and use "Backup - all files" with "Smart Update" to update the backup. This will add your regular account data, which will remain encrypted, as will subsequent Smart Updates.

• Unmounted images are a bit of a problem. We don't know what's "in" the image when it's a file, and so we don't have enough information to warn you before the copy starts.

  Because of the reasons listed in Make this Invisible, we may need to convert the image to APFS. Some cases might not work, and some we don't want to do without prompting you.

  So, we'll give you an error, after the image has been opened. You can then select your image's "open" volume (not the image file itself), and do the backup, once, like that. We'll warn you normally, do the conversions needed, and make the copy. Subsequent updates that don't require conversions will work normally.

• Because we've had to work all through the summer while everyone else was having fun, support may be crankier than normal. Sorry/not sorry.

Wrapping it up

So that's about it. Things should generally feel "normal" to you, although there will be some prompts for those who have encrypted or HFS+ destinations and a Catalina APFS source. Overall, though, the goal is for it to be relatively painless...and I'm sure you'll get in contact if you feel otherwise.

To get started, download the beta below. Note that you'll automatically get subsequent beta releases, and the final Catalina version when available. Once that final version is released, you'll only get release versions...until you manually install another beta.

Thanks for your patience, and we look forward to your (hopefully positive) feedback.

Download SuperDuper! 3.3 Beta 1 (v119.2)

Hey folks. Sorry for the relative silence here. We've been working during the summer on a Catalina update, and unfortunately we're just not quite ready for a general update. But we're close!

Catalina introduces some significant changes to the way a startup drive works, and while we've solved the various issues involved in making the backup process as transparent as possible, it's taken a lot of slow, careful work to get the testing done.

As you might expect, the "new way" Catalina splits your drive into two parts makes things more complicated. The details are hidden from you by Apple for the most part, but SuperDuper has to know, and handle, all the various tricky cases that arise from that split (not to mention the technical details of tying the volumes together, which we figured out early in the summer).

There are stories to tell--our initial intention was to take a different approach than the one we ended up taking--but those will have to wait for when I've got a bit more time.

That said, the GM version was just released on October 3rd, the final version was released today, we've got a beta almost ready to go, and I'll be posting it to the blog as soon as it's passed our internal testing.

That beta works great for most users, but will have some limitations around images: we're probably not going to work with APFS image destinations in the beta when selected as files, if the source is a volume group.

There are also some caveats regarding encrypted destinations: basically, we can't form a "volume group" from a destination that's already encrypted, so you'll have to unencrypt encrypted destinations, copy to them, then boot from them and turn on FileVault.

More soon; thanks for your patience, and thanks for using SuperDuper!

As we plug along with our Catalina changes, I thought I might write a quick post talking about some other stuff I'm enjoying right now. Because, hey, why not.

Coffee Related

Software Development and Coffee go together like Chocolate and My Mouth. And so, a lot of it is consumed around these parts.

I would never claim to be an expert in these things, but I've really been enjoying the Decent Espresso DE1PRO espresso machine. It doesn't just give me a way to brew espresso—many machines can do that—but it gives me the information I need to get better at it, and the capability to make the kind of adjustments needed to do so consistently.

It's a pretty remarkable machine. Basically, it's a very "complete" hardware platform (pumps, heaters, valves, pressure monitors, flow meters, etc) that's driven entirely by software. It comes with a tablet that runs the machine's "UI". And you can tap a button to brew an espresso.

But you can also see the exact pressure/flow/temperature curves happening in real-time as the brew happens. And, even more importantly, you can extensively change the behavior of the machine—adding pauses, changes in pressure, temperature, flow, etc—very easily.

You can emulate lever-style brewing. You can do "Slayer" style shots. You can do simple E61-style shots. The possibilities are endless.

And all of this happens in a machine that's much smaller than any other full capability espresso machine I've ever seen.

And that's not even going into the super helpful and friendly owner forums.

I've spent at least eight months with mine, which I preordered years before it shipped, and it's really made a huge difference. Highly recommended, and surprisingly available at Amazon, but also at the Decent Espresso site. There are less expensive models at the Decent site as well: the PRO has longer duty cycle pumps.

Power Related

A few years ago, I purchase a Sense Energy Monitor to see what I could learn about power consumption in our house beyond just "the bill every month".

Sense is a local company that uses machine learning and smart algorithms to identify individual loads by sensing waveform shapes and patterns in your main electrical feed. So it can identify, over time, a lot of the devices that are using power, how much power they're using out of your entire power use, etc. Which, as a problem, is super difficult...and they've done a very good job.

Sense can identify quite a few things, given time, including electric car charging, refrigerator compressors, AC units, sump pumps, resistance heaters, washing machines, dryers, etc. And it's getting better at these things all the time.

But, of course, they know they can't figure out everything on their own. It's easy for us to plug something in, knowing what it is, and wonder "hey, Sense, why can't you tell me that's an iPhone charger", when that tiny 5W load is deep in the noise of the signal.

So what they've done, on top of their "line" sensing, is integrate with "smart plugs" from TP-Link and Belkin. You can identify what's connected to those plugs, and the Sense will find them and integrate that information into its own energy picture. Plus, the additional information helps to train the algorithms needed to detect things automatically.

It's cool stuff. If you go in not expecting miracles ("Waah! It didn't detect my Roomba!"), and you're interested in this kind of thing, it's pretty great.

$299 at Amazon.

Plug Related

Speaking of smart plugs, boy there are a lot of bad products out there.

There seems to be a reference platform that a lot of Chinese-sourced products are using, with a 2.4GHz radio, some basic firmware, and an app framework, and a lot of products lightly customize that and ship.

Belkin

I don't know if that's the case with Belkin, but their products, while somewhat appealing, fall down hard in a pretty basic case: if there's any sort of power failure, the plug doesn't remember its state, and comes up off.

Given the plug can remember many other things, including its WiFi SSID and password, you'd think it could remember the state the plug was in, but, no.

That behavior along makes it unacceptable.

Not Recommended - no link for you, Belkin.

TP-Link

TP-Link has two products in its Kasa line that do power monitoring: the single socket HS110 and the 6-outlet HS300 power strip.

Both work fine, although the HS110 mostly covers up the 2nd outlet in a wall outlet, and that makes things inconvenient. The HS300 is a better product with a better design. All six outlets are separately controllable and each measures power as well. As a bonus, there are three 5V USB charger ports.

Both properly maintain the status of plugs across a power outage.

I've used both of these successfully in conjunction with the Sense. Standalone, the software is meh-to-OK for most things. It's fine.

There's support for Alexa and Google Home but not HomeKit (the Homebridge plugin only seems to support the HS100).

Highly Recommended for Sense users (especially the HS300); Recommended with caveats for standalone users.

Currant

The Currant smart plug is so much better than any of the other choices in most ways, it's kind of remarkable.

Unlike most other smart plugs, the Currant has two sockets, accessible from the side. It works in either horizontal or vertical orientations, with either side up (the plug can be swapped), and it's got a position sensor inside, so its app can unambiguously tell you which plug is left/right/top/bottom.

The plug itself is attractive and well built. The software is great, and if it's built on the same platform as the others, they've gone well beyond everyone else in terms of customizing their solution.

Plugs are quickly added to your network and the app. New plugs are found almost instantaneously, and announced on the home screen.

Plugs can be named easily, associated with icons and rooms, and the power measurements involved constantly update and are accurate.

Their software automatically recognizes usage patterns and suggests schedules that can be implemented to save energy.

You can even tell them what your power supplier is, and they'll automatically look up current energy costs and integrate that into the display.

There's support, again, for Alexa and Google Home but not HomeKit, and there's no Homebridge plugin. A future version looks to be coming that's a regular wall outlet with the same capabilities.

Finally, as of right now, there isn't (sniff) any support for the plugs in the Sense system.

All that said, these come Highly Recommended for standalone users...and I'd even recommend them for Sense users who don't need these particular loads integrated into the app. They're still measured, of course...they're just not broken out unless recognized normally via Sense's load sensing algorithms.

Here's hoping the Sense folks add support.

The WiFi versions of these plugs were initially expensive at $59.99. However, as of this posting, they're half price at $29.99. Available at Amazon.