# USB Temperature gadget driver >> ugold



## Phishfry (Oct 25, 2018)

Recently I stumbled onto a driver in source for the TEMPer brand of USB Temperature Sensors.
/usr/srs/sys/dev/usb/misc/ugold.c
"Driver for Microdia's HID based TEMPer Temperature sensor"

These are really common and cheap on ebay. I have four inbound tomorrow for testing along with 4 USB bases for remote use.
Anybody try these?
https://www.ebay.com/itm/263025822995


----------



## aragats (Oct 26, 2018)

Did you get and tested yours?


----------



## Phishfry (Oct 27, 2018)

I seem to have TEMPer V3.1 and the VID and PID are not present in usbdevs. I am working on it this weekend.
There seems to be several varieties and troubles on Linux too.
https://github.com/edorfaus/TEMPered/issues/51


----------



## Phishfry (Oct 27, 2018)

So upon further review the FreeBSD code is written for version 1F of the TEMPer
https://www.ebay.com/itm/302722798857

I am going to order one to check it out. I was wondering what the 'outer' field was in the code.
This unit has an external temperature probe for a secondary reading named 'outer'.

I added entries to usbdevs and ugold.c but my device is too different.

```
sysctl dev.ugold
dev.ugold.0.sensors.outer_valid: 0
dev.ugold.0.sensors.outer_calib: 0
dev.ugold.0.sensors.outer: 0
dev.ugold.0.sensors.inner_calib: 0
dev.ugold.0.sensors.inner_valid: 0
dev.ugold.0.sensors.inner: 0
dev.ugold.0.%parent: uhub3
dev.ugold.0.%pnpinfo: vendor=0x413d product=0x2107 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0000 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01
dev.ugold.0.%location: bus=1 hubaddr=2 port=2 devaddr=5 interface=0 ugen=ugen1.5
dev.ugold.0.%driver: ugold
dev.ugold.0.%desc: vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 5
dev.ugold.%parent:
```
The device:

```
Oct 27 00:56:05 E6420 kernel: ugen1.5: <vendor 0x413d product 0x2107> at usbus1
Oct 27 00:56:05 E6420 kernel: ugold0 on uhub3
Oct 27 00:56:05 E6420 kernel: ugold0: <vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 5> on usbus1
```


----------



## none (Apr 5, 2019)

Hi,

I have one of those but my system loads the ums driver instead:


```
ukbd0 on uhub0
ukbd0: <vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 2> on usbus0
kbd1 at ukbd0
ums0 on uhub0
ums0: <vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 2> on usbus0
```

Does yours work?


----------



## Phishfry (Apr 5, 2019)

Nope. I got the TEMPer1F setting right here.
Yet to try.


----------



## Phishfry (Apr 5, 2019)

Maybe that's the problem. ugold is interfering.

```
sysctl -a | grep ugold
dev.ugold.0.sensors.outer_valid: 0
dev.ugold.0.sensors.outer_calib: 0
dev.ugold.0.sensors.outer: 0
dev.ugold.0.sensors.inner_calib: 0
dev.ugold.0.sensors.inner_valid: 0
dev.ugold.0.sensors.inner: 0
dev.ugold.0.%parent: uhub3
dev.ugold.0.%pnpinfo: vendor=0x413d product=0x2107 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0000 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01
dev.ugold.0.%location: bus=1 hubaddr=2 port=1 devaddr=3 interface=0 ugen=ugen1.3
dev.ugold.0.%driver: ugold
dev.ugold.0.%desc: vendor 0x413d product 0x2107, class 0/0, rev 1.10/0.00, addr 3
dev.ugold.%parent:
```
I will try without the driver. Do you have any sysctl's?


----------



## leebrown66 (Apr 7, 2019)

Phishfry said:


> "Driver for Microdia's HID based TEMPer Temperature sensor"
> 
> Anybody try these?
> https://www.ebay.com/itm/263025822995


I don't suppose you know offhand if the TEMPer HUM (ebay) (humidity + temperature) is compatible?  It's only $20 so I'll probably just end up getting one to try anyhow.

Thanks -- lee


----------



## Phishfry (Apr 7, 2019)

No I don't know. I have found the source of my problem. The PID or Product ID is already assigned to another device in usbdevs.
So I need to try editing that again and removing the duplicate entry.
The ums driver does indeed pick up this device but that is useless for temperatures.
That ums driver is picking this up might be an artifact of the other device PID.


----------



## unitrunker (Apr 7, 2019)

I'd rather see a userland lib to talk to the device and let the OS speak generic USB (eg. libusb20). There's no need for this in the kernel. USB is the modern equivalent of an RS232 / RS485 port - with equal complexity - meaning it isn't hard.


----------



## Phishfry (Apr 7, 2019)

That's all fine and dandy but having a sysctl to scrape with syctlbyname is enough for me.


----------



## none (Apr 8, 2019)

Phishfry said:


> Maybe that's the problem. ugold is interfering.
> 
> ```
> sysctl -a | grep ugold
> ...



I do, but from ums driver. Nothing useful here 



leebrown66 said:


> I don't suppose you know offhand if the TEMPer HUM (ebay) (humidity + temperature) is compatible?  It's only $20 so I'll probably just end up getting one to try anyhow.
> 
> Thanks -- lee



That's exactly mine. I hope there is hope 



Phishfry said:


> No I don't know. I have found the source of my problem. The PID or Product ID is already assigned to another device in usbdevs.
> So I need to try editing that again and removing the duplicate entry.
> The ums driver does indeed pick up this device but that is useless for temperatures.
> That ums driver is picking this up might be an artifact of the other device PID.



So I need to take that PID from UMS driver and recompile it? As this is a server, and the kernel is modular, if I remove ums.ko from /boot/kernel will it crash the box, or just ugold will take over as desired?

thanks.

none


----------



## Phishfry (Apr 8, 2019)

No `kldload ugold` will load the module. The rest is "yet to be determined". Maybe devd.conf will be nicer.
I think a bug report is in order to get the VID/PID into FreeBSD.

I had to let this go.
Like I mentioned above in the "FreeBSD list of USB device ID's" usbdev has a PID entry already for my device.
There can not be a duplicate. It fails to compile.
So as a hack I changed the PID for the outdated hardware that I was battling(0x2107 changed to 0x2106).
That left the quirk issue out. but that don't really seem to be working right either. The sysctl is not showing any temps.

My next tact is going straight to devd and spoofing the supported PID/VID.
I got to admit it has been harder than I imagined.
There is no company named "TEMPer" and they latch onto CHICONY2 in the driver if you look at the code.
No luck.
I fooled around with the button on the device as I noticed it spews data to the terminal when you hit the button.
This only seemed to work in Xterm. A normal console I see no messages when pressing the button.
The LED is Red and I am not sure if that is right.
My device has a second external temperature probe using a mini-phono jack. I have read that it uses a onewire sensor.


----------



## none (Apr 23, 2019)

Hi again.

All my research leads me to a bad usb device ID by the device. I tried now on Linux, using tools well tested and got nothing.

As my device won't report as temperature device even on Windows, I guess that's it. I have to buy another


----------



## Phishfry (Apr 23, 2019)

Yes that does seem to be the problem. 
The ProductID or PID that is assigned to most of these TEMPer's belongs to another device.
That is why Linux barfs too. Bad PID. There is a github for them to make it work.


----------



## none (Apr 30, 2019)

Phishfry said:


> Yes that does seem to be the problem.
> The ProductID or PID that is assigned to most of these TEMPer's belongs to another device.
> That is why Linux barfs too. Bad PID. There is a github for them to make it work.



where is this github url?

All I found got me nowhere. Both FreeBSD and Linux.


----------



## Phishfry (Apr 30, 2019)

A hack to support TEMPer2 / TEMPerX_V3.2 / 413d:2107 · Issue #51 · edorfaus/TEMPered
					

I purchased this USB stick with an external sensor, and did not have any luck finding Linux drivers. After a few hours I managed to hack a way to read the temperatures.. it's ugly, but it works...




					github.com


----------



## none (May 2, 2019)

Well, I got mine working on linux using those hints in that link above. If that was feasible on Linux, do you think it can also be on FreeBSD?


----------



## Phishfry (May 2, 2019)

Yes maybe not by me but if Warner(driver author) had one he could have it going in 5 min.
I think a custom devd.conf script would do it.
This area is not my specialty.


----------



## none (Sep 20, 2019)

Phishfry said:


> So upon further review the FreeBSD code is written for version 1F of the TEMPer
> https://www.ebay.com/itm/302722798857
> 
> I am going to order one to check it out. I was wondering what the 'outer' field was in the code.
> ...



Hi, as a small reply to this, I got this 1F version of the sensor via Amazon.de and just to know it is listed in dmesg as same vendor and product numbers 

The same ums got loaded. No temperature numbers so far 

Can I force ugold to load?

none


----------



## none (Sep 22, 2019)

Phishfry said:


> So upon further review the FreeBSD code is written for version 1F of the TEMPer
> https://www.ebay.com/itm/302722798857
> 
> I am going to order one to check it out. I was wondering what the 'outer' field was in the code.
> ...



Hi,

could you share the code you wrote so it could be claimed by ugold not ums?

I tried here, no lucky. My driver coding skills are superficial.

thanks,

none


----------



## Phishfry (Sep 22, 2019)

Long story shortened- I am not a coder either. This might best be addressed by making a Problem Report at bugzilla.
Warner Losh is a very talented programmer and is very accessible and answers emails promptly.

When I mess with the /src tree I make a separate copy so as to not contaminate my source tree.
I deleted my custom source tree after failing here.

Here is why I chose not to continue working on this.
FreeBSD uses standard 'PCI Working Group' list of VendorID and ProductID 's.
The people who make these Temper devices are using a fake ID.
This problem cascades even further in that the fake ID actually belongs to another device.
So I work with NIST calibrated standards for ensuring my manufactured parts are usable by people in Germany or Timbucktoo.
It is called standardization. The computer industry would not exist in its current form if not for standards groups.

The people making Temper are using a fake ID.
I can't help that and it causes many problems that are above my paygrade.

No offense to you I just felt I need to make myself clear. I was not ignoring you but cannot help any.

Edit: The official name is "Peripheral Component Interconnect Special Interest Group"


			https://pcisig.com/membership
		

Membership is $4,000 a year and I feel this manufacturer probably don't want to pay their dues.
If Windows required a proper PCI-ID I bet they would pay up.


----------



## Phishfry (Sep 22, 2019)

Back to the technical side of this.
What I did is remove the usbdevs entry for the 'other device' that TEMPer spoofs.
Then recompiled.
That errored out because the removed device entry also had hooks in another file.
So I removed references in that file as well (can't remember the name).
Then it would compile cleanly. I then added back the TEMPer device and compiled again.
Still didn't help.


----------

