Schwie's Pad

Last summer, the plastic micro-USB covers snapped off my lovely Romanian Lumma Systems Grip Lights. I had plenty of time to find new covers, but of course didn’t and could have at least covered the port with a large rubber band, but I digress.

This spring, I carelessly rode through a few spring showers that seemingly shorted out my lights. The lights will still somewhat work when pressing the button, but they randomly turn on and off and cycle through modes all by themselves. Fortunately the laser still works. I happened to be one of the lucky backers who received all three sets of lights that I ordered, which means I still have a couple working sets to roll with, but I really want to fix up my broken left Grip Light.

I pulled two phillips screws out of the grip light and disconnected its power cable. The board slides out of the housing by gently prying up on the rubber fittings around each LED. Using my digital multimeter, I delicately poked around the PCB, which isn’t all that complicated. I soon found resistors R7, R8, and R14 to have given up their ghosts. R7 is marked 470, R8 is covered in rust and unreadable, and R14 is marked 220. I’ll try to verify R8 on another board, but it will probably be covered in dried hot glue unless I tear some away to expose it.

I don’t have the proper board level soldering gun to attempt this repair, but I may give it a shot with my pencil soldering iron and try to replace the blown resistors. Will post an update later if I can size and source the resistors.

I must be looking in the wrong place, but it felt difficult to figure out what to use for remove Testor’s Black Enamel from a paint brush. After reading a few sources, we decided to use a small container (wire nut) filled with Paint Thinner.

After inserting the brush, covered in black enamel, into the wire but, five the brush a several spins, pull the brush out, and wipe the brush with a paper towel. Allow it air.

Good to go!

If you are running Aruba VIA 3.1.3 (vpn), you might notice in Console.app that a previous version of Aruba is busy throwing out error messages:

Apr 18 13:59:24 BCS-MBP-2 com.apple.xpc.launchd[1] (com.arubanetworks.vpnservice[1428]): Service could not initialize: Unable to set current working directory. error = 2: No such file or directory, path = /Applications/Virtual Intranet Access.app/Contents/MacOS: 17G5019: xpcproxy + 10940 [1405][1FC7BF6A-6296-382C-913A-4FF8915953DC]: 0x2
Apr 18 13:59:24 BCS-MBP-2 com.apple.xpc.launchd[1] (com.arubanetworks.vpnservice): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.

This may be a previous version of Aruba VIA that I did not completely remove from my Mac. I had good luck leaving the current version installed and just deleting the remaining portion of the old version by running the old version’s uninstaller, saved here:

“/Users/(your username)/Library/Application\ Support/Virtual\ Intranet\ Access/Uninstaller.app”

Running this file seemed to delete files from the old version residing in Application Support and other places, but it doesn’t seem to delete anything relevant to the current (3.1.3) version of Aruba VIA installed in my Applications folder.

My Big Dummy needs a couple chains to work. I wanted to flip the drivetrain tonight and had a couple partial KMC chains laying around, a CN-HG53 and a CN-HG73. For anyone else trying this, I was able to join them together and they seem to work. I plan on rolling with these the rest of the winter and putting something more uniform back in play this spring. I can’t wait!

For over four years, I used Moves.app on my iPhone and loved how the data was freely exportable, easy to view, backed up, and best of all automatically collected without having to start and stop an app like Strava – I’m a Mac user, devices should work for us, not the other way around. Frustrated and disappointed, I wasn’t completely surprised when FaceBook shut down Moves on July 31, 2018. I was hoping Moves.app would continue to allow me to view previously recorded data after Moves’ servers were shut down, but sadly I was wrong, the app stopped working.

I had backed up Moves data through July 18, 2018, but my export and download on July 30 from Moves’ servers failed without me noticing until it was too late – darn it!

Looking ahead, I wanted a replacement for Moves.app for the above reasons. Happy to say I found a new developing app called “Move X“, which reproduces several of Moves’ features including the gorgeous user interface. I’ve been reporting bugs and feature requests to the Move X developers, who readily correspond via email. I don’t have a FaceBook account, but if you do, log in to it with Move X and the developers will be able to more closely work with you on identifying bugs with Move X.

For those who backed up and downloaded their Moves.app data, Move X directly imports your old data. Just move the .zip file containing your old Moves.app data to your iCloud Drive space and Move X should be able to find it.

The tracking algorithm Move X uses has a ways to go. It seems your movement data is uploaded to their server where it is crunched. I bike a lot and unfortunately, Move X always seems to think I’m driving a car as “Transport”. While Moves.app had a way to change the category for data incorrectly categorized, Move X does not – I hope they fix this soon or else figure out a better algorithm, because nearly all of my bike rides are being categorized generically as “Transport”.

Otherwise, I’m excited to be back up and running so soon. While Move X doesn’t have near the movement-type accuracy that Moves.app had, the developers seem eager to improve on it and for now, Move X accurately tracks where I was and when I was there, which is the other half of what I really wanted. Yes, Google Timeline does this too, but I find I much prefer the Moves.app/Move X interface for quick views of my data from a mobile device.

This has come up for me a couple times and I can never seem to find a good source on the web.

For my Big Dummy, the cable run from the Rohloff grip shifters, mounted on Surly’s Open Bar, to the Speedhub is 87 inches. This is for the largest Dummy frame from 2008, 22 inches.

To order cables and housing long enough, Yokozuna filled a special order for shift cables that included the following:

2  pcs       2500mm x 4mm SIS black housing

2  pcs      SIS 1.2mm x 2500mm Shift wire

6  pcs       4mm plastic housing end caps

2  pcs       Aluminum cable tips

Will report back on the brake cable length, next.

My son hopes we can host a Minecraft Server with lots of mods, but he wants our server based on the 1.8.x codebase, because of how it works with combat. I was concerned about security exploits on an older version of the software, but it seems that there aren’t too many well-published exploits in the wild. The current codebase for the server and client are up to 1.12 with 1.13 on the horizon, so our old server will need to allow folks with 1.9-1.12+ clients. Our server will also need to allow teleporting to other worlds, which we will accomplish with BungeeCord acting as a proxy and the Multiverse-Core plugin. We are opting to locally host the Minecraft Server from our Mac mini running High Sierra and macOS Server, so we also want Mac-specific startup scripts to automatically reboot the Minecraft Server suite any time after a reboot.

We considered running GlowStone, but for now, we decided  to use Spigot for the server software and BungeeCord as the proxy for multiple worlds. To get these software packages and Mac-specific startup scripts configured and installed, we followed Kyler Holland’s video:

We deviated from Kyler instructions with Spigot – we downloaded the latest 1.8.x version of Spigot (seemed to be 1.8.8), which we grabbed here:

https://getbukkit.org/download/spigot

And we also decided to run build 1303 of BungeeCord, which we nabbed here:

https://ci.md-5.net/job/BungeeCord/

We also modified the startup command for Spigot to give it 2 GB of memory using the following code:

#!/bin/bash

java -Xmx2G -XX:MaxPermSize=128m -jar spigot-1.8.8-R0.1-SNAPSHOT-latest.jar

To allow 1.9 and newer Minecraft clients to join our 1.8 server, we loaded the ViaVersion-1.3.0 plugin available here:

https://www.spigotmc.org/resources/viaversion.19254/

We also bumped the RAM requirements to 2.5GB, And everything seems to be running fine.

Since the original install, we’ve added plugins, including EssentialsX-2.0.1, Factions, Multiverse-Core-2.6.0, PermissionsEx-1.23.4, worldedit-bukkit-6.1.7.3, and worldguard-6.2.1. There are a few more that he wants, so I hope they don’t compromise stability.

Should you need to remove DRM from a rented library book for a bit past your due date, the following should help.

1. Download the current version of DeDRM from Alf (6.5.5, 6.6.1, 6.6.3 or newer).
2. Unzip the downloaded DeDRM tools file
3. Open the application at the following location DeDRM_tools_6.5.5->DeDRM_Macintosh_Application->DeDRM.
4. Click “Select Ebook…”
5. Now open a browser and rent a book from your public library.
6. When it is available, download the book – I typically go for the ePub, which is viewable in iBooks or Adobe Digital Editions 2.0 or newer on a Mac.
7. A file with a .acsm might be downloaded from the library, double-click this file to open it in Adobe Digital Editions 2.0 or newer.
8. Inside ADE, an ePub of your book will be downloaded from the library and it will expire in a set number of days. Right click the book inside ADE’s library and select “Show File in Finder”.
9. When this book is shown in the Finder, drag it to DeDRM’s file select window (Step 4) titled “Please select a DRMed ebook” and then click “Choose”.

Success. A copy of your rented book will be stripped of its DRM and saved in the same directory as Step 4.

** UPDATE #1 ** 6.5.5 and 6.6.1 are not launching on macOS 10.13.6. Will look further into this.

** UPDATE #2 ** I never looked further into the above situation, but 6.6.3 is working fine for me on macOS 10.13.6.

While attempting to configure some 1028 continuous radon monitors from Sun Nuclear, I assumed correctly the manufacturer would only offer Windows software. They said it ran on XP/2000 and pretty much everything before that, so I figure it would be a good candidate to try with Wine and WineBottler on my Mac.

Use WineBottler 1.8.3 and configure it with the settings shown in the screenshot below.

WineBottler 1.8.3 settings for Sun Nuclear 1028 software

The resulting application, saved to my desktop, boots up. Success! Almost.

Next we need to tell macOS sierra which USB to serial device and port to use. I started this, but didn’t quite get it to work yet. I think these links are going to be helpful when I dig into this further:

https://www.codeweavers.com/support/wiki/mac/faq/usbtoserial
http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/

http://www.ftdichip.com/Drivers/VCP.htm
http://www.ftdichip.com/Support/Documents/InstallGuides/Mac_OS_X_Installation_Guide.pdf
https://fearthecow.net/guest/wine-serial-ports/

In the mean time, I can confirm that Sun Nuclear’s software works fine with VirtualBox, Version 5.1.30 r118389 (Qt5.6.3), running Windows XP on my Mac.

Finally, here’s what I quickly tried, but it didn’t seem to work:

1. Using the codeweavers link up above, open Terminal.app and enter:

Last login: Fri Feb 16 23:17:05 on console
BCS-MBP:~ brad$ cd /dev
BCS-MBP:dev brad$ ls > ~/disconnect.txt
BCS-MBP:dev brad$ ls > ~/reconnect.txt
BCS-MBP:dev brad$ diff ~/disconnect.txt ~/reconnect.txt
269a270
> cu.usbserial-410
450a452
> tty.usbserial-410
BCS-MBP:dev brad$ ls > ~/disconnect.txt
BCS-MBP:dev brad$ ls > ~/reconnect.txt
BCS-MBP:dev brad$ diff ~/disconnect.txt ~/reconnect.txt
269a270
> cu.usbserial-410
450a452
> tty.usbserial-410
BCS-MBP:dev brad$ ls > ~/disconnect.txt
BCS-MBP:dev brad$ ls > ~/reconnect.txt
BCS-MBP:dev brad$ diff ~/disconnect.txt ~/reconnect.txt
269a270
> cu.usbserial-410
450a452
> tty.usbserial-410

2. Incorporating info in the CodeWeavers link with the app we created with WineBottler, let’s link the tty USB port with COM1 using the following command in Terminal.app:

BCS-MBP:~ brad$ cd /Users/brad/Desktop/Sun\ Nuclear.app/Contents/Resources/wineprefix/dosdevices
BCS-MBP:dosdevices brad$ ln -s /dev/tty.usbserial-410 com1

3. Opening “Sun Nuclear.app” didn’t allow me to connect to the 1028. For this to work, I think I need to load the FTP USB drivers, which is more than I want to get into at the moment.

If anyone sees where I went wrong, feel free to chime in below.

Thanks to Homebridge, I’ve forced a few non-Homekit devices in the house to play with the existing HomeKit devices in our house. Along the way, I followed nfarina’s advice to make a LaunchAgent for macOS Sierra, but I’m running macOS Sierra Server and I noticed Console.app->system.log keeps reporting the following errors

Feb 15 00:04:33 schwie com.apple.xpc.launchd[1] (com.homebridge.server): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
Feb 15 00:04:43 schwie com.apple.xpc.launchd[1] (com.homebridge.server[62564]): Service could not initialize: 17C205: xpcproxy + 11572 [1522][1729AB5E-4591-3F1B-AC72-36700ABA4F74]: 0xd

I first installed HomeBridge a couple years ago, so nfarina’s instructions may be different from what I followed. I also perused these posts and decided I could try to fix the situation:

1. Unload the existing LaunchAgent you created as described by nfarina:

launchctl unload ~/Library/LaunchAgents/com.homebridge.server.plist

2. Move the LaunchAgent .plist you created for HomeBridge from the ~/Library/LaunchAgents folder to the /Library/LaunchDaemons folder.

3. Load the LaunchDaemon for HomeBridge with the following command in Terminal:

sudo launchctl load -wF /Library/LaunchDaemons/com.homebridge.server.plist

This seems to fix the problem for me, although step #3 causes system.log to spew out this message:

Feb 15 00:12:01 schwie com.apple.xpc.launchd[1] (com.homebridge.server): This service is defined to be constantly running and is inherently inefficient.

Console.app only reports this error message once, so I think I can live with my inherently inefficient situation for a little while.