Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Bresser/Explore Scientific ST1005H #3092

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

DonKult
Copy link

@DonKult DonKult commented Nov 14, 2024

I am very new to this and my SDR hardware is old DVB-T equipment (RTL2832U+FC0012+20cm rod antenna), so probably not quality cu8 files (they are at least rather large for something so trivial)… attaching one anyhow as it shows that what is send by this variant of the Bresser Thermo-/Hygro-Sensor 3CH is misdetected by the "Oregon Scientific SL109H Remote Thermal Hygro Sensor" decoder if the bits align. I am happy to collect some for the test repository though if that helps and they turn out good enough for you. bresser-misdetect-as-oregon_433.92M_250k.cu8.gz

The timings were thankfully provided by -A and the protocol is so simple that I think I managed to figure the meanings of the individual bits out except for the last 6bits that are probably a checksum, but I lack the experience to make a proper guess as to what type I am afraid.

As such, this remains a draft for the time being. Also as I don't know much about the sensor… I got two in a sale a while ago for far cheaper than the current asking price (from a vendor who sells them for even more than Bresser now?!) under the impression/hope that this might be the ones already supported by rtl_433… they have the same name and feature set after all. Of course, they were not. Could hence be an outdated model mainly sold as (pricey) replacements (covering up the "EXPLORE SCIENTIFIC" branding that seems to be used on other Bresser sensors, too) and so maybe not the most pressing/useful to support.

@zuckschwerdt
Copy link
Collaborator

It seems like the first "bit" of the 38 needs to be ignored (have you ever seen the first bit set?), then the fields mostly align to bytes and checksum is field-wide addition, e.g. something like 1x ID:8h FLAGS:4h TEMP:12h HUM:7d CHK:6h in BitBench, with checksum maybe ID+FLAGS+TEMP+HUM? But maybe HUM counts 2x, i.e. padded to 8-bit value, not sure.

I think the bresser shouldn't be changed, this looks like a very different protocol. Not sure if ST1005H is the original name then?

@DonKult
Copy link
Author

DonKult commented Nov 22, 2024

Thanks for the quick and spot-on hints! The first bit is indeed always 0 & humidity is doubled in the checksum. All that was left was figuring out that the individual nibbles of the values are added together to form the checksum.

I moved the implementation to a new bresser_st1005h as it indeed shares nothing but the generic name with bresser_3ch. I did keep bresser in the name through instead of explore_scientific as the later does not seem to sell them anymore nor have they any info on their website about it. Also, bresser_6in1 is the only other sensor making a mention of that brand name with bresser prefixed so as long name I picked Bresser Thermo-/Hygro-Sensor Explore Scientific ST1005H. I think that would have given me a reasonable chance to find it.
As usual, naming things is hard… so more than happy to change that further.

@DonKult DonKult marked this pull request as ready for review November 22, 2024 22:09
@DonKult DonKult changed the title Add support for a second variant of Bresser Thermo-/Hygro-Sensor 3CH Add support for Bresser/Explore Scientific ST1005H Nov 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants