Upgrade to Mac OS 10.8.4 Breaks WeatherSnoop

Shortly after updating my Mini to 10.8.4 I noticed a connection error to my WeatherLink USB Data Logger. It seems to be related to the USB Driver from Silicon Labs. The discussion link can be located at: http://www.tee-boy.com/forums/viewtopic.php?f=3&t=468&p=1903#p1903 for those effected.

When/if an update is provided to the driver I will post back.

[jay (support)]

To clarify SILabs position, they provide a serial to USB chipset and driver to other hardware vendors, in this case Davis, and then the hardware vendor includes that chipset in their product. So they are saying that they will only directly support their customer - Davis.

This could be a problem for us as well though since the Z-Stick also uses the SILabs chipset. I haven't upgraded my 10.8 Mac to 10.8.4 yet - has anyone else that uses the Z-Stick?

Thanks for clarifying that relationship as I was not sure how that works. I also have the z-stick and have not noticed anything out of the ordinary since updating to 10.8.4. The one thing that has always bothered me with my z-wave is that when my power is interrupted I have to reconfigure z-wave by selecting the appropriate Serial Port: SLAB_USBtoUART. Screen shot provided below. If I select the ...UART# z-wave will not load.

Other than Davis Weather station I am also running RFXCOM. I wonder if the WeatherSnoop Weather Agent is by default choosing the other USBtoUART6 (I believe the number changes with restarts)? I don't see where w/in the agent I can choose otherwise. Can I manually go in to the system and remove USBtoUART6?

[jay (support)]

You've hit the nail on the head, so to speak. The SILabs drivers (or, possibly, Davis and Aeotec's implementation of the SILabs hardware) sucks - they don't have the unique serial number implemented (that all the FTDI devices we've ever seen use), so the VCP driver can't distinguish between them. Bottom line: I believe anyone who has multiple SILabs-based devices are always going to struggle with them because it appears to be random which device the driver names "SLAB_USBtoUART" and which one gets some (random?) number appended to it.

This, I believe, is a valid complaint to both the hardware vendors (Davis and Aeotec) and to SILabs - particularly the latter because if it's a driver issue it means that hardware vendors may switch to a competitor (FTDI) that does the right thing with their drivers (append the device serial number to the end of the VCP port name - meaning it will always represent the correct device). Again, I don't know if it's SILab's issue or whether Davis and Aeotec aren't implementing something correctly. But it reflects badly on all parties IMO.

I think perhaps WeatherSnoop is also having difficulty with this port naming thing (which is not it's fault). Have you tried reselecting the right port (the one that's NOT selected for the Z-Stick) to see if that fixes it?

The two usbserial-# ports are your PowerLinc and the RFXCOM. Notice how they uniquely identify themselves such that you can have as many FTDI devices connected to your Mac as you like and they never get confused?

[jay (support)]

Oh, and I just did a quick test with 10.8.4 and the Z-Stick and it appears to be fine. So I think you're just stuck with the multiple SILabs-based device conflict issue.

I think perhaps WeatherSnoop is also having difficulty with this port naming thing (which is not it's fault). Have you tried reselecting the right port (the one that's NOT selected for the Z-Stick) to see if that fixes it?

In that case if would be the one with the numbered ending of 6. Within the WeatherSnoop weather agent I don't see a choice for selecting ports just selecting the type of connect (USB Data Logger) and the ability to test it, which fails in my case. Image below of Weather Agent screen. I will point out this discussion to Boisy of WeatherSnoop.

Just to see what would happen, I removed my z-stick and rebooted my Mac. Following restart I tried running the WeatherSnoop agent and still an error. When I went into configuring Z-wave in Indigo I noticed that the numbered USB driver was not an option. Upon plugging my z-wave stick back in the trailing number had changed to 5. I selected 5 in configuring and z-wave works but WeatherSnoop still shows errors.

In WeatherSnoop I have no options when my WeatherLInk USB Data Logger is selected but do when Weatherlink Serial Data Logger is selected with options for usbserial-03VGC637 and usbserial-A501LCSZ but neither works as suspected. If I had the WeatherLInk IP: http://www.davisnet.com/weather/products/weather_product.asp?pnum=06555would my problems go away? I looks like WeatherSnoop supports this as well.

[jay (support)]

BTW, there was a discussion about this a couple of months ago - the problem is with Davis and Aeotec. Of course getting those guys to "do the right thing" is problematic at best. I think we asked Aeotec about it but never heard back. We'll try again though I don't expect much.

Hi everyone,

I've been looking at this issue since AlaskaDave pointed it out to me. I was preparing a fix when I went back and read this thread, and realized that the device name could change if unplugged and replugged as noted.

This would cause particular grief to WeatherSnoop users who happen to be using more than one Silicon Labs based device. What will the user think if they, for example, select SLAB_USBtoUART6 and then upon restart, it's now SLAB_USBtoUART5? WeatherSnoop saves off the selected device's name and thus has an expectation that it will be there when it restarts.

I can certainly modify WeatherSnoop to look for more than one SLAB_USBtoUART device and if so, allow the user to select, but since it's not guaranteed to be named the same thing on a restart, it's really not an ideal fix.

Hello guys,

I have an update on this issue.

Today I received a WeatherLink USB data logger and have been able to test this on a Mac that is also connected to a Kenwood TS-590S HF Radio with USB port. So now I have two CP210X USB devices attached to this Mac.

Going to terminal and typing: ls /dev/cu.* shows the following:

/dev/cu.Bluetooth-Incoming-Port /dev/cu.PL2303-001042FA /dev/cu.SLAB_USBtoUART7 /dev/cu.usbserial
/dev/cu.Bluetooth-Modem /dev/cu.SLAB_USBtoUART /dev/cu.usbmodem1 /dev/cu.usbserial-A1003T6g

Note there are two devices with SLAB_USBtoUART... one contains a 7 (it was 25 before I rebooted).

Now, the IOKit code I'm using in WeatherSnoop to iterate over the serial devices is example code from Apple. It has worked for years and always returns multiple serial devices using the same driver (for example, FTDI USB-to-serial adapters). However in the case of the SLAB_USBtoUART device, the iterator code only returns ONE device even though there are two above.

From what I am seeing, this points to an issue with Silicon Labs' driver. Somehow, they are not currently able to give OS X more than one device during iteration.

I'm going to contact Silicon Labs about this.

After posting this, I looked back at the previous posts on this thread and see a screen shot with Indigo clearly showing two SLAB_USBtoUART devices in a pop-up button.

Now I'm wondering if I'm somehow missing something here.

Well, I'll be...

It turns out that the code I've been using for years may be at fault, or perhaps partially.

The code that I'm using iterates through the IO registry and gets two names: the service name and the BSD path name. Here's a dump of the serial devices on the Mac with the two SLAB_USBtoUART devices:

[names setValue:/dev/cu.PL2303-001042FA forKey:PL2303-]
[names setValue:/dev/cu.usbserial forKey:usbserial]
[names setValue:/dev/cu.usbserial-A1003T6g forKey:usbserial-A1003T6g]
[names setValue:/dev/cu.usbmodem1 forKey:usbmodem]
[names setValue:/dev/cu.Bluetooth-Incoming-Port forKey:Bluetooth-Incoming-Port]
[names setValue:/dev/cu.SLAB_USBtoUART forKey:SLAB_USBtoUART]
[names setValue:/dev/cu.SLAB_USBtoUART7 forKey:SLAB_USBtoUART]

In the lines above, names is an NSMutableDictionary, using the service name as the key and the BSD path as the value. I then use the service name as the display name in the pop-up button.

Clearly you can see both SLAB_USBtoUART and SLAB_USBtoUART7, but the service names are the same... and that's why only one SLAB_USBtoUART device shows up in the pop-up button... because an NSDictionary's keys are unique. Inserting the second SLAB_USBtoUART device in the dictionary overwrites the first one.

What it looks like I need to do is have the key be the device name (which appears to be unique) and have the value be the service name. Of course, now I'll have to display the BSD path in the pop-up (minus the /dev/cu.).

So this explains why my changes weren't working. I'll work on a fix.