 |
||||||||||||||
|
|
|
||||||||||||
stewlg's ContentThere have been 6 items by stewlg (Search limited from 29-April 23) #58663 DHT11/22 sensor managed driver
I am not going to be trying his code any time soon; my relevant Netduino project is installed and functioning adequately, and I'm not inclined to take it apart right now:
http://www.skyscratc...r-for-netduino/
To answer your question, after startup, I read from the sensor about once every 1-2 minutes. #57248 Netduino NRPE monitor
#57247 How hard can I expect to lean on network activity for Netduino Plus 2? (Sampl...
#56803 How hard can I expect to lean on network activity for Netduino Plus 2? (Sampl...
I totally agree. You need to have something of a Nagios-centric perspective already to embrace it, but I am hoping others will find it useful too. I just couldn't bear to pay hundreds of pounds/dollars for a flood monitor for Nagios:
http://www.sensormet...nd_flooding_s_6
Also, your wiring image has the wrong devices on the end of each set of wires, it's the DHT22 that needs multiple pins, not the water contact
Crumbs. I did that late at night. I will revise before "final" publication, and this time I'll use different colors for the wires.
In the meantime, I'm seeing several others suggesting that the Netduino network stack is inherently somewhat unreliable:
http://forums.netdui...uino#entry49132 #56795 How hard can I expect to lean on network activity for Netduino Plus 2? (Sampl...
I've been working on an implementation of NRPE for Netduino Plus 2.
NRPE is a protocol spoken by Nagios for system monitoring. So far I've hooked up a flood sensor (the reason I started the project) and a temperature/humidity sensor (so I could get the mechanics of multiple checks figured out early, and allow for easier expansion).
I feel like I'm near the end of the project, but during development I've had some threading/resource type crashes so I've made an effort to test the code under circumstances that go way beyond what will happen during deployment. I do NOT want to be going down to my basement every few weeks or days to manually reboot the device if it hangs. I am OK with it getting into a bad state briefly, SO LONG as it can recover in a few minutes by itself and keep going.
I've been testing under three scenarios.
Normal Usage: In deployment, the device will be polled every 1-5 minutes per service. This is very light duty and it is certainly possible that the code I have may already sustain this load indefinitely without crashing.
In my testing though I have stepped up the load two more levels more to try to find any lurking networking/threading/resource bugs:
Stiff Breeze: One copy of this shell script running against the device. You will need check_nrpe available to you to make this work, which is part of NRPE.:
#!/bin/bash
[ Yes I'm not incrementing the counter, and this runs forever, deliberately. ]
Gale: Multiple copies of the above shell script running in parallel against the device.
Under Stiff Breeze, I can consistently get the device to crash in 2-4 hours. When it crashes, I get a network 10054 error, probably when some incoming connection that the Netduino is trying to respond to times out. Then I get some 10048 errors on the aborted stream. And finally I bounce back to the main loop, but evidently the network stack is dead by then, as the Netduino is no longer responsive to ping. The Netduino must be power cycled/rebooted to become responsive to ping.
Under Gale, I can get the same thing to happen in a matter of minutes.
(I haven't done long-term Normal Usage testing, as it seems likely that it will take days for an error to occur, if it is going to occur at all.)
Am I being unrealistic about what the device can do? Or is there a coding error here I can correct?
You do not need my sensor setup to simulate the crash (although I've included a Fritzing screenshot in the zip for the interested). All you need is the ability to run check_nrpe in a loop as shown above.
Thanks very much!
Attached Files
#56717 DHT11/22 sensor managed driver
I was getting the
public bool Read()
{
if (disposed)
{
throw new ObjectDisposedException();
}
// The 'bitMask' also serves as edge counter: data bit edges plus
// extra ones at the beginning of the communication (presence pulse).
bitMask = 1L << 41;
data = 0;
// lastTicks = 0; // This is not really needed, we measure duration
// between edges and the first three values are ignored anyway.
// Initiate communication
portOut.Active = true;
portOut.Write(false); // Pull bus low
Thread.Sleep(StartDelay);
portIn.EnableInterrupt(); // Turn on the receiver
portOut.Active = false; // Release bus
bool dataValid = false;
// Now the interrupt handler is getting called on each falling edge.
// The communication takes up to 5 ms, but the interrupt handler managed
// code takes longer to execute than is the duration of sensor pulse
// (interrupts are queued), so we must wait for the last one to finish
// and signal completion. 20 ms should be enough, 50 ms is safe.
if (dataReceived.WaitOne(50, false))
{
// TODO: Use two short-s ?
bytes[0] = (byte)((data >> 32) & 0xFF);
bytes[1] = (byte)((data >> 24) & 0xFF);
bytes[2] = (byte)((data >> 16) & 0xFF);
bytes[3] = (byte)((data >> 8) & 0xFF);
byte checksum = (byte)(bytes[0] + bytes[1] + bytes[2] + bytes[3]);
if (checksum == (byte)(data & 0xFF))
{
dataValid = true;
if (bytes[0] == 0)
{
portIn.DisableInterrupt();
}
else
{
Convert(bytes);
}
}
else
{
Debug.Print("DHT sensor data has invalid checksum.");
}
}
else
{
portIn.DisableInterrupt(); // Stop receiver
Debug.Print("DHT sensor data timeout."); // TODO: TimeoutException?
}
return dataValid;
}
Now I get this when the demo app starts up:
DHT sensor data timeout.
A timeout, one bad read, and then good ones from that point forward. I'm sure with a bit of work we could eliminate that first bad read as well, I haven't tried yet.
To save someone else time, I'm attaching my working project. I'm targeting the 4.3 framework successfully in it. Attached Files
| ||||||||||||||
|
||||||||||||||
|
|
|
||||||||||||
|
This webpage is licensed under a Creative Commons Attribution-ShareAlike License. | |
||||||||||||
|
||||||||||||||
Posted by
