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
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.
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.
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.
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.
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.
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
Regards
Jean
[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.
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.
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.
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.
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
@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.
hola buenas tardes yo he comprado un temperhun en aliexpres pero no me funciona en sgp
me podrias decir como o has instalado ?
usas windwos ? cual ?
le has instalado un dirver exterior para poder usarlo ?
que driver has seleccionado en sgp para que lo reconozca ?
Javier - I would love to think that Temperhum is great. They are very inexpensive and I had three. They all are supposed to be the same but they work entirely differently. It is a game of Russian Roulette to find one that works. Ken and Jared gave up with them as it was impossible to provide working drivers when they had frequent undocumented changes in the device.
I threw mine away and bought a BlueAstro Weatherstick. Since Per’s passing, I think they are hard to find. There are alternatives - it is easy to do with just an Arduino and a Bosch sensor (I just made one in an afternoon with a Nano and free software). I think MBOX provide an commercial alternative.
