Trouble with DHT-22

I had to reinstall everything on my RPI B+ I installed Raspian Stretch and this in one problem I’m having.

I’m getting this error message:
“Specified argument was out of the range of valid values. Parameter name: processor”

Any ideas?

Hi Claton,

I am having a similar problem with my DHT11. What I digged up so far is:

  • The Kernel Change from 4.8 onwards changed the way the chipset is being reported
  • home genie makes use of the raspberry-sharp-IO library to control GPIO
  • the current version doesn’t expect the new chipset naming of kernel >4.8
  • changes need to go in to raspberry.system and GpioConnectionDriver.cs


But I got stuck there in how to compile the two, maybe you have a clue?

Best regards

Hi Jens,

I suspected something like this. The solution is to go back to Jesse, that worked and that’s what I will try next. I’ll let you know how it goes.


Didn’t work going back to Jesse. The reason is Jessie now contains kernel 4.9 too.

I downgraded to kernel 4.4.50 and things seem to be working.

I found the instructions for doing this here:

Doing a kernel downgrade is unfortunate no option for me. I had regular reboots of homegenie because of USB kernel issues. They were not linked to homegenie as such, more a basic OS problem. Since I upgraded the kernel they seem to be gone (this is what I found as comments in various forums, too) until now.

I found two forks


Raspberry.System contains the Info for the 2835, but in uppercase BCM2835.
Raspberry.IO.GeneralPurpose expects them to be as Bcm2835. I tried to fix that in the code with XAMARIN, but Raspberry.System is linked as package via nuget.

Would be really helpful if somebody would know how to go beyond that point.

Many thanks
Best regards

I just experienced the USB problem. I didn’t have the problem before. So I restored from the recycle bin the version of Raspbian I had great success with from 2016. I intend to go back to that version. So wish I had remembered to shut the pi down before I pulled the power! I’ll report back in a week or so on my results.

Update Jan. 15th: Haven’t had the USB lock again so haven’t gone back to older Jessie. Still using kernel 4.4.50.


I’m having the same problem. Thanks for help!



I was able to compile now by changing all relevant entries to

case Processor.BCM2835:
return Interop.BCM2835_GPIO_BASE;

I haven’t exchanged all DLLs on the Pi yet, as I wanted to do a backup first.

Will try in a couple of days


1 Like

Goodmorning everyone!
… Please, has anyone managed to solve the DHT-22 problem with Raspberry P3 and Raspbian Stretch installed?

Old thread, but wondering if anyone compiled this and confirmed it fixed the DHT-22 on the RPi3? This may be related to GPIO not functioning on the RPi3 as well.

No need to answer. I figured out the issue with RPi GPIO not working. See my post from yesterday to see that unrelated solution and download the updated library.

As I reported in RPi GPIO update for HG - General - HomeGenie Club
The fix for GPIO program not working doesn’t fix the DHT-22 issue however it does help a bit (at least with a ZeroW running Buster).
I’m getting different error messages then reported in the OP:

[Line 28, Column 50](javascript:HG.WebApp.ProgramEdit.JumpToLine(‘CR’, { line: 27, ch: 49 })) (Code):
The type UnitsNet.Ratio' is defined in an assembly that is not referenced. Consider adding a reference to assembly UnitsNet, Version=, Culture=neutral, PublicKeyToken=null’

[Line 28, Column 67](javascript:HG.WebApp.ProgramEdit.JumpToLine(‘CR’, { line: 27, ch: 66 })) (Code):
The .' operator cannot be applied to operand of type UnitsNet.Ratio’

[Line 29, Column 53](javascript:HG.WebApp.ProgramEdit.JumpToLine(‘CR’, { line: 28, ch: 52 })) (Code):
The type UnitsNet.Temperature' is defined in an assembly that is not referenced. Consider adding a reference to assembly UnitsNet, Version=, Culture=neutral, PublicKeyToken=null’

[Line 29, Column 65](javascript:HG.WebApp.ProgramEdit.JumpToLine(‘CR’, { line: 28, ch: 64 })) (Code):
The .' operator cannot be applied to operand of type UnitsNet.Temperatur

I tested RPi 1B, 1B+, 2B, 3B, 4B, and ZW. In the models I had borrowed, all tested correctly. There are other HW revisions that I did not have nor test. I found f this morning that there were a few that were not in my update. If you grab the git repository and compile the Test.Board program on your RPi, you can confirm that the new updates committed today fix things. I have no way to test so I’ll just leave it as is in what should be a working state. If gene gets back to it, he can incorporate the update and the main HG package should work. It could be included in the BE too, but this project appears mostly focused on Windows environment.

For those that have a DHT212, DHT11 or AM2302 and wish the info these produce in HG.
I created a HG program that will pull the info into HG from an external Python 3 call using the Ada_Fruit_DHT library. It still uses the HG sensor widget so it is possible to get these back working with HG until Gene updates the drivers these sensors use.
There is a newer library then the Ada_Fruit one that supplies a bit more info however the HG sensor widget unlikely will work correctly with the info it spits out.

The error with DHT is related to the libraries. The error message is suggesting that there is a problem with using the “UnitsNet.Ratio” and “UnitsNet.Temperature” properties. There are 2 locations in the Raspberry.IO.Components code that reference these.

The UnitsNet library is referenced here:

I suspect a small update to one or more of these locations would get you working with HG and DHT natively. This is a small change that’s fairly straight forward. I’d recommend giving this a go rather than cobbling things together outside of native solutions.

In fact, there is actually a test program that Gene provided that would make the tweaks easy to diagnose. I’d recommend anyone interested in getting DHT modules working on the HG/RPi setup check out this little tool and fix the lines I pointed out as necessary.

Good luck!

You’ve done more for HG in two months than Gene has done in two years. Not being the type to quit you proved once again that these problems can be resolved internally with the correct expertise. Once again, well done :+1:

In case you get a working update to the HG code, please update the issue so that Gene can include the fix in his next release.