Why TemperHum


#1

Hi,

I am new to this forum and as I am discovering the Sequence Generator software I stumbled over one SGP feature called TemperHum. As last year I bought such a device, but was never able to put it at work, I hoped that it would work with SGP… in vain. The feature tells me that the device is connected but there are no graphs or readings showing up. I used the device in Backyard Eos and had some readings there but witch had no sense at all. I searched for appropriate drivers, even through the website of PC_Sensor, and despite the good will of O’Telescope (the builder of BYE) the problem was never solved. So my question is: why does a quality software as SGP includes features for hardware that is not even close to be reliable? It is an all-known fact that the TemperHum devices don’t work and if it wasn’t that these are produced in China and are distributed by the eBay channel (difficult to track down), I would have longtime pressed charges against the producer of this crap.
Main Sequence Software should consider removing the ThemperHum feature from the SGP or replacing it with hardware suggestions that do work correctly. The presence of TemperHum degrades the otherwise well thought and fine working piece of software.
Best regards
Jean


#2

I believe it’s pretty much unsupported at this time.


#3

Indeed. This has been discussed a bit on other threads and I think at this time it is just a legacy item. I would agree that the Temperhum hardware is basically crap.


#4

Whew - was almost going to buy one of these recently. Glad I didn’t now.
Figured could probably just as easy extrapolate my focusing in between scheduled auto-focus if looking to get clever.


#5

Hate to be contrary here, but within the past 2 months I have purchased 3 of these devices. They work perfectly for me as standalone devices, ie. not being referenced by SGP. I have been running them using the included software. They record temp, humidity, and dewpoint on any frequencey down to once per second, the data being written to a text file, and nice graphs plotting the data. My 3 are by default closely calibrated and seem quite accurate, and the software allows for you own calibration of the temp offset. I had hoped to run all three simultaneously on the same pc, but the software only allows one at a time. I may install a virtual machine to run a second. I will be using it to keep track of the temp/humidity in my observatory.


#6

Suffice to say that everyone’s experience is different and has changed over time, which is not particularly clever!
When Main Sequence wrote it into SGP, it seemed to be very good. Since then it appears that PCSensor has brought out different models but under the same product name and whose calibration is different. I had two physically identical ones, which gave very different and plain wrong results. I threw my first one away in disgust and just sacrificed the second one to the cloud god.

I just bought the new BlueAstro USB Weatherstick. This is the same size as a TemperHum and has temperature, dew point, humidity and Barometric pressure. It is a serial device and has an internal FTDI serial to USB convertor. It is currently sitting in a USB3 hub on my NUC and reporting out in very high resolution. Its Windows application allows calibration of temp, humidity and pressure.

It is being targeted at intelligent tracking mounts. Currently it integrates with the 10Micron mount driver and can update its refraction model in real time. The website suggests future collaboration with others. The software currently writes the data into a DB3 file (SQLite) and a Boltwood compatible text file. I can see it also being used to indicate temperature for focusing and the source of information for adaptive dew control or as a mist predictor.

My Davis weather station seems redundant now too.


#7

There are multiple TemperHum models and they’re all poorly (not) documented from a development perspective. We reverse engineered one but the effort to do so on other models just isn’t worthwhile, especially since we have no clue how many are out there.

Obviously they work with the software that they come with as they have complete control over their driver and implementation…unfortunately we do not.

I would love to completely remove support for TemperHum devices but don’t want to harm those that have them working (even though that may only be a few folks)

I’d be happy to look at the BlueAstro solution to see if it’s better.

Thanks,
Jared


#8

Maybe it would be a good idea to have a choice in the SGP between TemperHum and BlueAstro. The last one works nicely and precisely and is a Swedish product.
In that way, folks who would have a working model of TemperHum wouldn’t suffer the loss of a feature that works for them, but as Jared said, with TemperHum changing all the time, what is the benefice of implementing it when you know beforehand that it would not work…
Hope to see a solution :sunny:
Regards
Jean


#9

[quote=“Jared, post:7, topic:1869”]
I’d be happy to look at the BlueAstro solution to see if it’s better.
[/quote]Jared - the documentation is shown here for the Blue Astro stick. It would interesting to have your view on the developer-friendliness of it.

http://download.blueastro.se/Stickstation_manual_0.88.pdf

I have tried mine on two machines and randomly inserted / pulled it without any detrimental effect. It just continues when it detects the device in the COM port once more. That includes USB3 and 2 ports, for good measure.

I’m hoping that SB pick up on it and use it to update their ProTrack model. Even though PHD2 is good, having the base mount tracking really accurately helps things out when it guiding is disabled or inhibited during focusing.


#10

Looks very easy to integrate with on a quick visual pass of those docs. I’ll pick one up and do some playing.

Jared


#11

Looks interesting. Thanks for the update/information…


#12

@Jared
@Chris

Thanks Jared. I’m sure it is straightforward to read temperature and use it in SGP.

I’m not an ASCOM guru but looking forward, I know that we have a separate interface for safety devices (for instance the ASCOM safety monitor) for AAG cloudwatcher wind speed and cloud cover. For the future, would there a benefit for a unified approach that has hardware devices writing into a single (DB3?) file and then the applications picking out what info they require through an ASCOM interface? Would that be a way to crack the weather nut? The ‘standards’ discussion would then revolve around defining the superset of weather parameters in the DB3 file.


#13

I would use the ASCOM switch interface for these weather related things.

A driver could, for instance, implement properties called Temperature, Humidity, DewPoint, Cloud, Rain, Wind and so on. All would be read only (that’s allowed in the switch interface).

The ones that are implemented by a particular driver would depend on what’s available.

A safety monitor driver could connect to this (possibly several switch interfaces) and apply logic to decide if it’s safe or not.

We discussed implementing a weather interface ASCOM interface but it got nowhere because there was no agreement on what the interface required - what properties were essential and which optional. In the end all that could be agreed on was that what the application needed was to know if an operation was safe to do and so we had the Safety Interface.


#14

Hello Jared,
I just saw that the latest reply on this topic is now 225 days old. I am planning on buying the BlueAstro stick weather station. It is distributed by Baader now. Wonder if it integrates already with SGP? Was there some testing done? What were the results?
Kind regards
Jean


#15

@Jean I’ll just drop a note here: I use the BlueAstro - no problems now whatsoever. Info displayed in its own docking module and my RoboFocus uses this temp sensor also - as I have it set to do.


#16

Hello Kinch,
Thank you for the information. I will use it in the same way!
Best regards
Jean


www.mainsequencesoftware.com