In SGP 2.4 beta the TEMPerHUM device is connected but not reading:
sg_logfile_20141229152237.txt (19.6 KB)
Which device is this? Was it working in 2.3? Did you enable the option to look for TemperHum devices in the SGP Options?
Thanks,
Jared
Don’t know, bought this device (TEMPerHumM12V1.2) after start using 2.4.
Give it a try on 2.3 and let you know.
Nope…it’s not working in 2.3 either…
Not surprising, unfortunately. Do you happen to have a link to the device you purchased?
TemperHum devices are super annoying to support. Little versioning and support from the MFG end. Plus they seem to reuse the same packaging/casing/model numbers but not the same implementation. We’ve talked about pulling support for them multiple times. Unfortunately I can’t even tell you one that will work because of the reasons above!
Thanks,
Jared
Here’s the link: http://www.ebay.com/itm/360874230481?_trksid=p2060778.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT#
Yup…looks EXACTLY like one of ours that works fine. I’ll see what we can do. No promises here though.
Thanks,
Jared
Okay…thanks.
Jared - I feel that you are battling a lost cause with this device. We cannot expect you to keep trying to second guess what the manufacturer does.
Is there an alternative temperature device that is more robust? I wondering about Phidgets, some of which are USB thermometers. I found a bunch of other USB thermometers but think that they are probably re-packaged PCSensor devices.
I know this is an old post, but just as point of interest, were you ever able to get it to work?
I just bought a TEMPerHUM sensor and have a similar issue. From the replies I understand the difficulties, but sadly I only discovered this issue after buying my TEMPerHUM.
Regards
Martin
Martin,
Some TemperHUM devices work and some do not. It is very hard for us to tell which ones do and which ones don’t (meaning we can’t even direct users to a vendor that sells known working devices (with SGPro). They are terrible devices and we have made the decision, that while we will not remove existing support, we will no longer make any effort to support them. We are exploring alternate options.
Hi Ken,
I’m not sure if I am underestimating the problem, but is it really necessary for SGP to detect the TEMPerHUM device to access the required data?
Even though the devices differ substantially, they all come with a basic data logger that outputs a simple text or csv file with the date and time, temperature, humidity and dew point.
To avoid dealing with the lack of standards in the TEMPerHUM devices, can’t SGP simply read the text logs that the TEMPerHUM device’s data logger generates? If need be the frequency of the readings, and temperature units of the log files can be dictated by SGP.
Typical TEMPerHUM Log:
1 , 29.87 , 26.19,8.41 , 02/10/2015 21:00:10
2 , 29.69 , 26.23,8.28 , 02/10/2015 21:00:15
Surely that will work, and avoid having to support the devices themselves.
Regards
Martin
Martin - possibly - but both of my TEMPerHums’ were TEMPerMental and did not always even get recognized by the PC.
I threw mine away and bought a USB weather stick from BlueAstro. I cannot integrate it into SGP for focusing, but it provides accurate temp, pressure and humidity for my mount tracking. It has been very reliable so far and more accurate than my Davis weather station. Ken was looking at this device too as it appeared to update a simple boltwood and DB3 file for easy reference.
I got my TEMPerHUM to work and log data fine, which is why I thought it was worth investigating.
Thank you for the info, I will take a look.
Martin
I was going through cleaning out the cupboards and found a TemperHUM stick from a few years ago. I recall at the time that I could not get it working.
Just plugged it in on my current machine, no drivers or anything manually installed, and Windows automatically loaded all the drivers itself. SGP doesn’t appear to be detecting it, but Astro Photography Tool APT - Astro Photography Tool does automatically, as does the third party software ThermoHID http://www.thermohid.co.uk/
Perhaps getting in touch with them for drivers/ideas? There may not be much support from the manufacturer, but it can be done. They are cheap, and therefore attractive for SGP users to incorporate into their arsenal and make SGP even more powerful 
Had a quick look at the BlueAstro ones mentioned above - may be nice, but expensive!
Thx for the input. Right now we are just not that interested in supporting these devices. They are poorly made, poorly supported and not all that accurate (our first 2 that we ordered were just plain DOA). The $20 price tag may seem attractive to users, but to us, this “small feature” will likely cost us a great deal in terms of support and tweaking and versioning, etc… In the end it is a disservice to most of our user base (who really have no interest in these devices), that we spend time here when we could be spending it on what we feel are more useful services to a much wider audience.
That said… we have been wrong before and will be again. If I have totally missed the mark on the need to fully support TEMPer and TEMPerHUM devices we can reconsider.
Does your forum software allow for having polls? 
A better way forward would be for Ken and Jared to use the new ASCOM ObservingConditions interface that we are planning for the 6.2 ASCOM platform.
It provides this sort of environmental data. The task of hooking up multitudes of different flavours of TemperHum devices (or anything else) can then be done independently. Ken and Jared do one implementation and then get on with more useful things.
Chris
As you know we are big fans of the “Dependency Inversion Principle” (and as a result of this, ASCOM as a platform). We very much like the idea of this. It will allow folks that like TEMPer stuff to write their own ASCOM driver for them and we will not need to devote large amounts of time to support.
Don’t you mean dependency aversion principle? 