Interesting problem with DHT22 Sensor

Total the power requirements of the DH22, Edimax and RPi. Compare with stated output of the PSU. If close to, or exceeding the PSU capability, get a bigger PSU.

Remember that an RPI can need 2100mA while booting though typically will only uses 500mA while running. This was correct for the RPi B+ - the Pi 2 and 3 may/probably will have higher power requirements.

Find out whether the other devices have similar spikes and size the PSU accordingly.

Note that the flat, square, black two-outlet USB PSUs sold by Maplins had a TOTAL capacity of 1000mA: I'm certain that other PSUs have a similar limitation.

Get the current requirement of each device by reading the spec or, preferably, using a multimeter on each device. Yes, you may need to make up one or more leads that you can connect the multimeter to. Make you use the maximum current drain for each device and assume that they can all happen at the same time.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

In message , Martin Gregorie writes

Thanks, the old power supply is marked as 2000mA, so I'd be looking for one at least that size as a replacement.

Adrian

--
To Reply : 
replace "bulleid" with "adrian" - all mail to bulleid is rejected 
Sorry for the rigmarole, If I want spam, I'll go to the shops 
Every time someone says "I don't believe in trolls", another one dies.

Get a proper Raspberry Pi PSU. 2500mA:

Or similar, no recommendation/not tried it/3000mA:

--

Chris Elvidge, England

It is possible that the SD card was corrupted as the power supply died. You might try reloading raspian (and, of course, you can always back up the current card on a full sized computer).

In message , ray carter writes

That thought had also crossed my mind, although there isn't any obvious sign that corruption has occurred.

Adrian

--
To Reply : 
replace "bulleid" with "adrian" - all mail to bulleid is rejected 
Sorry for the rigmarole, If I want spam, I'll go to the shops 
Every time someone says "I don't believe in trolls", another one dies.

In message , Chris Elvidge writes

Thanks, that saved me looking it up.

Adrian

--
To Reply : 
replace "bulleid" with "adrian" - all mail to bulleid is rejected 
Sorry for the rigmarole, If I want spam, I'll go to the shops 
Every time someone says "I don't believe in trolls", another one dies.

There usually isn't.

The problem is that all Linuxes use unoccupied RAM as disk cache space. Start a console and run "top" to see (a) whats running and (b) the way RAM is being used (thats on the last header line. When a file is closed, all buffered blocks are flushed to disk but its unclear, to me at least, just how often sectors are flushed when a bigger file is being written. The result of a power failure can be incomplete files due to cached but unwritten blocks. This may also mean that the inode(s) for that file are left pointing at the wrong sectors if an existing file is being overwritten.

The other problem with all forms of SSD storage is due to 'wear levelling'. Since every storage cell has a limited number of writes before it fails, all SSD storage periodically remaps its blocks so that the few heavily modified ones (directories, inodes, etc) get exchanged with less heavily used blocks. This doesn't happen often, but its not instantaneous and, if there's a power failure during it, the SSD storage is quite likely to be unreadable. Don't forget that the remapping code is in the SSD and won't understand anything about the filing system on the disk: all it knows is how many times each block has been written to and its only aim is to remap blocks to equalise the number of writes to each block. On top of this, SD cards are the smallest and cheapest SSD devices and, as such, have the least resilience to power failures.

There's not much you can do about this except to make a point of NEVER switching an RPi off without stopping the OS first, so it can flush all cached blocks and close down tidily.

There are small, inexpensive switch units you can buy that will power the RPi off after Raspbian has stopped.

For the properly paranoid, there are also UPS addons for the RPi, but they aren't particularly cheap by the time you've bought the UPS board and added reasonable sized batteries to it. That said, if you have Linux running on a desktop or laptop, put the RPi disk in an SD reader attached to it, but DON'T mount it. Now and run fsck against the SD card to see if its corrupted. Don'y know which drive its on? Run "df -h" before and after sticking the SD card in the slot. The item that appears (called something like /dev/sdc) is the SD card.

Don't have Linux on a desktop or laptop? Download, a 'Live DVD' ISO file, burn it to a DVD and boot your computer from it. This won't damage your existing OS, but will let you run fsck against the SD card. Or, if your PC will boot from a memory stick and you had a 2GB stick, put it there rather than on a DVD.

I suggest getting the Fedora XFCE live disk spin, because XFCE looks and acts fairly similarly to Windows, or you could try a Mint ISO that has the Cinnamon desktop. There are lots of others, but these happen to be the pair I know. I've installed and briefly used Mint+Cinnamon and Fedora_XFCE is my everyday system.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

I didn't think pis used SSDS. I thought they were plain SD cards

wear levelling varies enormously between brands

and may take place on card long after data is flushed

--
To ban Christmas, simply give turkeys the vote.

All flash memory is an SSD of some sort and SD cards are one of them, along with memory sticks, SATA-connected solid state disks, NVME (solid state storage plugged into the PCI bus), etc, ...

Indeed, and the levelling algorithms vary in how susceptible they are to leaving a damaged SSD. Power failure while an SD card is doing wear levelling is more likely than not to leave a damaged or trashed card than not. OTOH, if it happens to an enterprise-grade SATA SSD you're more likely to get away with only minor damage, that fsck may be able to repair if its formatted as one of the Linux journalling filing systems.

Of course, this doesn't excuse you from regularly making backups and storing them offline [1]. At least two backup generations on separate storage devices is a sensible minimum. If you don't do that and the online storage takes a serious hit, then just suck it up: any data loss is your fault for not having a recent backup.

[1] Of course using one of the version control packages (cvs, git, svn,...) is a fast and easy alternative backup for files you consider valuable - provided that the central repository is regularly backed up and offline copies are kept.

I like version control: couple of days ago I made a mistake doing a set of edits to a 1300 line C source file. The result compiled OK but crashed on a regression test. Recovery was simple and fast: delete the edited source, run "cvs update" to retrieve the most recent version out of the cvs repository and redo the edits more carefully, recompiling and rerunning regression tests after each group of edits. Result: success.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

Easier just to plug everything into a "USB Doctor" to check voltage stability.

In message , Adrian writes

Problem now resolved.

The new power supply was plugged in, but that in itself didn't fix the problem. A new SD card was plugged in (the old one was showing various errors which fsck didn't fix), and that has got me back up and running again.

Adrian

--
To Reply : 
replace "bulleid" with "adrian" - all mail to bulleid is rejected 
Sorry for the rigmarole, If I want spam, I'll go to the shops 
Every time someone says "I don't believe in trolls", another one dies.