Stanley/Whistler UT351 Limit Switch Replacement

We currently have a Whistler (Stanley/Genie series) UT351 screw drive garage door opener and it has been in need of some repairs. Since the garage door opener has been rock solid reliable, and it’s connected exclusively to a HomeKit Garage Door Controller Accessory that I developed (so all garage door commands are sent encrypted through HomeKit), we decided that it’s best to repair the opener that’s worked for so long rather than gamble on a new brand.

We repaired the motor coupler… However, there was another issue: all of the limit switches broke so they were being held to the track with a sophisticated mechanism of duct tape and carpet tape. This worked pretty well, but was becoming slightly problematic occasionally and required readjustment. Pretty problematic since if the limit switch slips, then the door will slam into the opener or into the ground with pretty decent force. We decided it’s time to replace these limits witches.

The issue: discontinued

Garage Door Opener Replacement Limit Switch
Part 36850

When we spoke to some garage door part distributers and discussed the parts we required, we were informed that limit switches are no longer produced for our garage door. We were able to find someone who sold, what was supposed to be, drop in replacement limit switches for our model. These are the Stanley-compatible Limit Switches (Part #36850). We ordered two of these and thought we were golden

Surprise 2: our limit switches are wired together

Original limit switch - one wire into opener and other wire proceeds to next limit switch

This one surprised us during the switch. Our limit switches are wired together in sequence and not independently wired back to the opener (i.e. one wire proceeds down connecting both limit switches, with only one wire returning to the opener from the closing limit switch). We thought maybe this was expected, so we installed both switches in place of the existing wires.

Plugged the opener back in and: surprise surprise… the opener started throwing an error indicating the limit switches were not connected. This made sense since the circuit would have to be completed for the opener to function properly, and this method of installing did not make that happen. The circuit could never complete since the reed switches would never be pulled closed at the same time.

The fix: resistors to the rescue!

To get these limit switches working, we’d need to complete the circuit by adding resistors to both limit switches between the wire coming into the limit switch and heading onto the next switch (or the opener in the case of the down switch).

We used 5% resistors: 1.3k Ohms (first/up limit switch) and 2.2k Ohms (last/down limit switch). Rewiring is pretty simple:

  • Connect the wire from the garage door opener into the first/up limit switch lead wire. Also connect the 1.3k Ohms resistor to this wire connection that’s just been made.
  • Connect the last wire of the first/up limit switch to the the existing wire heading to the second/down limit switch. Also connect the 1.3k Ohms resistor to this wire connection.
  • Connect the wire from the first limit switch into the second/down limit switch lead wire. Also connect the 2.2k Ohms resistor to this wire connection.
  • Connect the last wire of the second/down limit switch to the existing wire heading back to the garage door opener. Also connect the 2.2k Ohms resistor to this wire connection.
New limit switch installation
Excuse the mess here. This was simply a test to see if the theory works. The final connection will be much cleaner (and should be in your case as well)

Hopefully this assists in wiring new limit switches to the the older screw-drive Whistler/Stanley/whatever other brand they sold this UT351 opener under. Remember: you’ll be using the existing wire coming from the garage door opener to the first limit switch, and the existing wire going from the final limit switch back to the garage door opener. Keep that in mind when cutting the old cable and using the crimp connectors. Make sure both wires in the new limit switches have a resistor that ensures the circuit can always complete.

ActorAgeCheck October Website Update

ActorAgeCheck has had a minor update to improve performance and prevent downtime in certain conditions.

The image server has been slightly modified to prevent resource hogging in the event that the image database is failing to return image data timely. The site experienced an issue with its image database today which resulted in website timeouts or severe slowdowns (e.g. in some cases taking 30 seconds or longer to load a page).

I have made some improvements to the image system to fail gracefully in the event that our image database is not returning images in a timely manner.

This change will have no user-facing impact except in times of technical difficulties with a moving part of the site. If the image server fails to return images in a timely manner, it will no longer cause an overall site slowdown or timeout during times of heavy traffic.

Speech Jammer 5.1.2 Released

Speech Jammer 5.1.2 has been reviewed and approved by Apple and is now available on the iOS App Store.

This update adds the ability to export individual recordings off-line for sharing without uploading to the Speech Jammer Sharing Service. This was a big step for added privacy for users. Details are available below. This update also includes enhancements for the latest versions of iOS.

This update adds new enhancements and features:

  • Ability to export single recordings without uploading to the Speech Jammer Sharing Service
    • Speech Jammer has long offered the ability to share recordings by uploading your recording (encrypted during transit) to the Speech Jammer Sharing Service, which would store your recording and make it available via a generated link. This gave enhanced compatibility by making sure the recording is shared as a standards-based MP3 file and always accessible through a highly-available service.

      With this addition, users can now choose to share an individual recording without uploading it to the Speech Jammer Sharing Service. This adds an additional element of privacy for users and allows them to instantly share an Apple-codec based recording file through iMessage or any other sharing service of their choice. This will not upload any file to our servers, and will not generate any link. You can share the actual recording file.

      The Speech Jammer Sharing Service remains available as an option and the choice to share offline or through the server is up to the user.
  • Enhancements for the latest versions of iOS
  • Performance enhancements

Start Usage Meter upcoming changes

I wanted to write a quick blog post to comment on some upcoming updates to Start Usage Meter. Before I get into these changes, I wanted to circle back to my reasoning for splitting Start Usage Meter into two branches (perpetual 2.5.8.x, and 2.6 and beyond).

Why the change?

When I first started writing Start Usage Meter: I wrote it as a native Mac app and it was built from the ground up using Apple technologies. It was built to support as many older releases of OS X as possible from its birth. This meant that the app launched with OS X Lion support, even though it was released a couple of years prior to the apps development. I chose this for two reasons: (1) I felt it was important to support users on older operating systems, especially for a utility app where some users may not be able to progress past a certain OS and (2) I wanted to challenge myself to support OS X 10.7 Lion as long as possible, while still supporting the newest releases of the Mac operating system.

This was relatively easy to do for a long time. If an API didn’t exist in an older version of macOS, then I created workarounds to create the same outcome wherever possible. The only downsides were that it took some extra work and maintenance with potentially a little less polish (e.g. base localization couldn’t be supported since I cannot target OS X 10.7 and build with base localization, which meant that I needed to create separate XIB’s for each language and maintain them all separately. This meant that each language may not be pixel perfect). Where critical API’s didn’t exist, I just didn’t display it to the user (e.g. Notification Center wasn’t available in OS X 10.7 Lion, so I don’t support it and didn’t display any options relating to it).

I continuously announced my commitment to support OS X 10.7 for as long as possible and was able to keep it up for a while. I was able to work around the lack of new API’s in some cases. As long as my tools allowed me to continue, then I would.

Then Xcode 12 was released. This new version of Xcode included the new macOS Big Sur SDK’s and offered some pretty cool enhancements. The downside? You could only target OS X 10.9 or later. I had to make a decision. Do I keep the app on an old toolset, convert to a different environment, or drop OS X 10.7 and 10.8? I ultimately settled on dropping OS X 10.7 and OS X 10.8 so I can continue to build for macOS using native tools and SDK’s; however, I decided to create a second branch of Start Usage Meter: Start Usage Meter 2.5.8, which I plan to back port critical fixes and improvements from the later versions. I will always distribute 2.5.8.x as a signed and notarized app and will do this for as long as possible. This lets me finally modernize the app.

So what’s coming?

I plan to release Start Usage Meter updates shortly for the Mac App Store version. 2.6 already has some improvements that were held back due to old OS support, such as base localization and new UI improvements.

The upcoming releases will take this much further. I plan to transition Start Usage Meter entirely to Swift and modernize the codebase. There will be big UI improvements to help it feel even more like a new modern native Mac app (it is and always has been a native app, but older OS support meant holding back on some UI improvements).

The immediate upcoming changes will have some pretty impactful UI interaction improvements, which should greatly improve the user experience.

I just wanted to provide a bit of a heads up about what to expect from updates, and provide some additional clarity as to why the OS changes were made in the first place. I can’t wait to share the updates with you, and I hope it improves the experience as intended.

Modernizing servers and planning for the future

I’ve been making several changes to my servers in an effort to modernize them while maintaining stability and reliability. There’s been a lot of volatility in the server OS market: from macOS discontinuing several server packages and options to CentOS moving to become an upstream distribution. This has resulted in more-than-expected adaptations in order to future-proof the servers and custom scripts/procedures. Since Apple still offers the ability to replace binaries for Server.app-managed services, I’ll likely be leaving macOS deployments on the latest OS with security update commitments. The plans are slightly muddied for my Linux servers, though.

Latest Improvements

I am was a pretty avid CentOS user and have been running RHEL-derived distributions on all of my servers (with the exception of office installations where macOS Server.app may be used for remote access and configuration). I have been making several configuration changes in an effort to modernize my CentOS server performance (congestion algorithm changes and more modern protocols), which required quite a few changes to packages since CentOS is a downstream operating system without inherit support for modern feature sets and I usually run a LTS release for at least a few years.

CentOS becoming upstream

The announcement from CentOS threw a wrench into a lot of my upgrade path plans and has forced me to re-evaluate my distribution choice. Although it may be easier to remain with a RHEL fork (like AlmaLinux) for binary compatibility: this sudden change is a little disappointing and is driving me to a different distribution with a long history. It has ultimately been a blessing in disguise and has lead me to move to a new distribution with a better commitment to open and free software with a focus on stability. I have experience with Debian and distributions based on Debian (like Raspberry Pi OS). I’m also a fan of FreeBSD, although I’d like to stay in the Linux world for portability of scripts. Debian’s staying power and consistency is really what I’m looking for and is my current planned route (Debian Stable with packages built from source).

Migration Plan

I’m excited to make these changes and have started migrating my servers to Debian. I’m taking this move relatively slowly with a lot of preparation. Thankfully, I’m granted this extra time thanks to back ported kernels and CentOS 7 offering LTS until 2024. This gives me the opportunity to focus on getting this migration right and with very minimal downtime. This allots me plenty of time to re-write scripts, if necessary, prepare new configuration files, and test.

Current Status

Although my primary servers are still running CentOS or some other RHEL fork and I am preparing for the migration to Debian or FreeBSD; I have already migrated some services to different distributions. For example, my secondary/tertiary nameservers are now running Debian or some distribution other than CentOS and have new custom scripts for maintaining them. So far, I’m very impressed with the maintenance of these distributions and am excited for moving all of my servers off of RHEL once I’m confident that I can maintain the current stability I have. For the time being, I’ve been able to improve performance and reliability with CentOS 7, but I am ready to move forward to have a better future-proof plan. I’m hoping to have an upgrade plan ready to be implemented around Bullseye Hard Freeze.

Thank you to the CentOS community and RHEL for all the years of support and distributing stable operating systems! It has served me well and I was happy to be a user! I will still be dipping my feet in the RHEL world through future CentOS Stream versions for other use cases!

ActorAgeCheck 1.0.40 website update

ActorAgeCheck.com recently went down for maintenance on January 28th 2021. This was to address some backend issues that were resulting cache data not being cleared from the server as frequently as it should be.

This issue didn’t have any user facing impact, but the backend was not working as intended.

Maintenance completed after a couple of hours and I continue to work on backend changes; however, I am confident that I can complete these changes without taking the site down for maintenance and without any major user impact.

This update also:

  • Adds support for movie titles with a question mark in their title. In some cases, this would result in a 404 error due to part of the movie title being interpreted as a query string
  • Improves recently searched list links and self corrects any titles with unapproved special characters
  • Prevents failed responses from being cached

I will be performing these changes and optimizations over the next few days. During this time, the website may be slightly slower than normal. I do not expect any downtime or other issues during this work.

Thanks for your support!

Start Usage Meter 2.6 Released

New modern app build

Note: Users running OS X 10.7 to OS X 10.8 or earlier must use Start Usage Meter 2.5.8.1, which is available from my website as an app verified by Apple and notarized. If you are running OS X 10.9 or later, then you should use the Mac App Store version as usual.

Start Usage Meter 2.6 has been approved by Apple and is now available on the Mac App Store. As previously mentioned, this version only supports macOS 10.9 and later.

This app has native support for Apple Silicon (looking at you M1 chip!). This marks the first version of Start Usage Meter that includes a universal binary. This update also contains a few fixes to polish the app. It also includes some minor UI tweaks for macOS Big Sur.

  • Modernized many parts of the application to use newer macOS technologies!
  • Native support for Apple Silicon. The app is now a universal binary
  • Fixes an issue where the daily usage window would not highlight the row representing today
  • Icon improvements for Big Sur
  • UI enhancements

Start Usage Meter 2.5.8.1 Released for OS X 10.8 and earlier (including FAQ)

Note: Users running OS X 10.9 or later (including the latest versions of macOS) should use Start Usage Meter 2.6, which is available in the Mac App Store, built for the latest versions of macOS, and contains support for the newest Mac hardware

Start Usage Meter 2.5.8.1 has been released as a notarized app and is now available. It is an Intel app.

This update contains a few fixes for Start Usage Meter that have been backported from Start Usage Meter 2.6 (available on the Mac App Store for OS X 10.9 and later). This release has been checked and notarized by Apple.

SHA256 SUM (although unnecessary due to the fact that the binary is signed and notarized by Apple)
Start-Usage-Meter-2.5.8.1.zip – a1129fe051bcc2c5e9dc9b5fe08ae585d2938b7e216301bfdf2de267a6b3fb60
Start Usage Meter.app/Contents/MacOS/Start Usage Meter – 1b4abd4bbde01bb9e11beaeefd04a692371ef8bd4c2b893e1cd755ac3b8f36e1

Start Usage Meter 2.5.8.1 has been released as a notarized app for OS X 10.7 or later, available exclusively through my official website. As previously mentioned and planned, this marks the first version that will not be available through the Mac App Store since version 1.5. It contains back ported improvements relevant to its current feature set. Notably, this update:

  • Fixes an issue where the daily usage window would not highlight the row representing today

FAQ

What’s notarization?
Notarization is a feature from Apple that allows me to send my app to Apple for confirmation that it does not contain malicious content or anything that will harm your computer. It essentially offers the security advantages of a Mac App Store app, outside of the Mac App Store.

Is the app still sandboxed?
Yes. Start Usage Meter 2.5.8.x is essentially the same version you’d find on the Mac App Store if I were able to continue to offer it with support for the older versions of macOS. As the app and tools evolve, I’ll need to split the app into two versions; however, the security aspects of the app remain the same (i.e. the app is sandboxed and verified by Apple). Any release outside of the Mac App Store moving forward will always be sandboxed and notarized by Apple for your security. Always make sure you download from either the Mac App Store or https://dwightd.com.

Why not just cut support?
I’m really happy about my ability to continue to offer the app for all users on all operating systems. I’d like to continue that for as long as possible, and Start Usage Meter 2.5.8.1 represents my attempts to make this a reality. It contains a bug fix that is available in Start Usage Meter 2.6 on the Mac App Store. Although I may not be able to port all new features back to 2.5.8 for older operating systems, I’d really like to keep it running smoothly and issue free.

Is it still a native app?
Yep! Everything about Start Usage Meter remains the same as the Mac App Store build. It is still a 100% native app written using native Apple tools and languages. It does not contain any Swift code to maintain compatibility with OS X 10.7.

Old Icon (Click to Download)

Old icon?
Start Usage Meter 2.5.7 changed the icon to follow the macOS Big Sur design language. Since 2.5.8 was the last version to support OS X 10.7 and it contained the Big Sur icon, I’ve left it the same way in 2.5.8.1. That said, I have attached the 2.5.6 icon and you can copy it and paste it in the icon field by clicking the icon in the apps “Get Info” window.



Side note: the icon was slightly reduced in size in Start Usage Meter 2.6 to better match the rest of Big Sur. 2.5.8.1 contains the original, slightly larger, Big Sur icon introduced in 2.5.7.

Start Usage Meter 2.5.8 released (Merged: Start Usage Meter 2.5.7 released)

Start Usage Meter 2.5.8 has been reviewed and approved by Apple and is now available on the Mac App Store. This version consists of Start Usage Meter 2.5.7 along with an additional fix for macOS Dark Mode.

This update, as previously mentioned, has various improvements and polishes the app. It also includes an updated UI, including the main icon that is designed for the Big Sur era. This update:

  • 2.5.8: Addressed an issue with macOS Dark Mode
  • Adds a new macOS Big Sur-era icon
  • The daily usage window will now display an error message if the app fails to load daily usage data, giving the option to retry
  • Improved the daily usage window performance and reliability. This greatly reduces the energy and resource consumption that this window usually takes
  • Updated the main configuration user interface
  • Various fixes and improvements

As Mentioned Earlier
This may be the last update to support operating systems before OS X Mountain Lion (or potentially more recent operating systems).

If a future update drops support for OS X Lion and/or other versions of OS X, I will upload a notarized and signed version of the app at https://dwightd.com that will be maintained and updated with back ported improvements for OS X Lion and other older versions of OS X.

Speech Jammer 5.1 released

Speech Jammer 5.1 has been reviewed and approved by Apple and is now available on the iOS App Store.

As mentioned earlier, this update focusses on optimizations and improvements to various areas of the app. In addition to various improvements to existing functionality, this update adds some new features.

This update adds new enhancements and features:

  • Now supported on Mac’s with Apple Silicon and macOS Big Sur
  • Added an AirPlay button to quickly switch between headphones
  • New Settings section that allows you to customize certain app behaviour
  • Added ability to adjust Bluetooth quality and profile
  • Added ability to utilize built-in device earpiece, if available
  • Added echo cancellation feature as an option
  • Added ability to adjust gain/volume
  • Added ability to disable the delay completely

This update also:

  • Fixed an issue that caused the recording upload progress bar and percentage indicator to remain stuck at 0% until the upload finished
  • Improved the display of progress when archiving recordings
  • Improved reliability of the audio system
  • Optimized many parts of the app, which will result in a much smoother experience. This is an ongoing effort.
  • Improved support request system, including a much cleaner design
  • Fixed an issue that could cause recordings with a large file size (e.g. long recordings) to fail when sharing individually
  • Fixed an issue that caused the Name and Email fields to appear empty when submitting a support request
  • Fixed some design issues with the FAQ system
  • Fixed an issue that could cause shared recordings to continue playing, even when you close the recording window
  • Improvements to localization
  • Cleaned up unused code