Thursday, October 17, 2013
Just had to post this one, after a narrow escape:
LESSON: ALWAYS BACK UP YOUR DATA BEFORE UPDATING BIOS FIRMWARE!
While diagnosing some sleep/wake issues on an ASUS P8H77-I motherboard, I was forced to update the BIOS. While this is pretty easy on the Asus boards, Be aware that sometimes a BIOS update can wipe the Intel RAID controller configuration!
Looking at the RAID management screen in the BIOS it was obvious that two of the 4 RAID-5 disks had somehow been marked as 'non-RAID' and therefore were not members of the set anymore.
All may not be lost however, if you encounter this, and you know your RAID disks are good - in other words they were ok before the update, then you could try this:
- Boot into the RAID config (CTRL-I on my board)
- DELETE the RAID configuration [just wipes the RAID sig on the disks]
- CREATE a NEW RAID configuration of EXACTLY THE SAME SETTINGS as before
Windows will still not recognise the partition I discovered but you can recover this using TESTDISK:
- Download TestDisk
- Start it up, and let it scan for partitions
- you should see your missing volume within seconds.
- Stop the scan (unless you have more AWOL volumes)
- Write the partition signature
- Reboot again.
Data was restored 8-)
More details here:
ALWAYS BACK UP YOUR DATA BEFORE UPDATING BIOS FIRMWARE!
[Your experience may vary from the above, but I felt it was worth posting that this worked flawlessly for me]
Tuesday, January 01, 2013
Here's a quick hack I use to control Crashplan on my Windows Home Server. If you've not tried Crashplan, you're missing out - It's a cloud based and peer-to-peer backup solution that 'just works', complete with the ability to avoid that huge initial backup to your friend's PC by taking the 'seed' backup to them on a USB drive, then sync the changes over the net. There even a smartphone app to get your files on the go.
You can configure it to backup 'all the time', and you can also configure it to run between certain times of day. This was great until I calculated that it would take 4 months to pump my backup up to the Crashplan Cloud running 11pm-8am using all my upstream bandwidth !!
One of the problems of a DSL internet connection is that authough you might have a tasty 20mbit connection for downloads, you only get a 1mbit connection for uploads (or backups) - this is fine until you try to use that connection while the backup is running, things are extremely slow as a result of all the data you're sending 'up' your DSL connection.
Cue a nasty hack to help us out a bit! - this simple script adds a little intelligence to when the backup actually runs. I should point out that Crashplan is configurable in terms of the bandwidth it uses when you're at your PC, or away from it - though with a headless Windows Home Server, I'm always away, so have less control of this, coupled with more than one PC in the house, this is a little limited , but if you have just one PC or laptop it will work fine for you.
I use this simple script to do the following:
- Run the backup at night time (22:00-08:00) - no-one is using the net at that time 8-)
- During the day run the backup, unless one of our PC's is being used, in which case stop it.
Hopefully I wont have to wait 4 months now!
Friday, November 30, 2012
I have however updated all your links so that any uploads that are assoicated with posts mostly work, if I have missed one, please let me know.
More coming - I promise...
How about ... FPV Camera setup for a Blade MCP Helicopter? - coming soon.
Thursday, June 03, 2010
My home lab is a good example - My laptop is on my employer's domain where other people in other countries are the administrators, and my virtual machines are on another where I am the evil overlord.
While it would be cool to link them all together, it's far too complicated and frankly I dont want my employer's IT department tinkering with my lab machines, and they wont be setting up any employer-employee domain trusts anytime soon.
I wanted to manage my virtual machines from my laptop, without changing it from the configuration I had, here's how I managed to get it working for System Center Virtual Machine Manager, and Hyper-V Administation tools:
My lab looks like this:
SCVMM R2 on a Hyper-V VM Win2k8 box, in it's own domain (its a DC actually as well, but that doesnt matter), and a Laptop client running Win7 x64 in a different domain (no relationship between them)
•Login to client PC as your normal domain user account
•Install SCVMM console from media as usual.
•create an account on the SCVMM servers' domain with the same username and password as your client, make yourself a domain admin for good measure (you may not need this step, but all home labs need lots of domain admins!)
•Make SCVMMDomain\youraccount a SCVMM admin in the SCVMM console on the server.
•Get hold of John Howard's HVRemote script and run on both client and server to enable anonymous dcom (cscript hvremote.wsf /AnonDCOM:grant ) _ WARNING: You are opening up your DCOM security here, be aware of this and read-up if you are concerned.
•Each time, just before you launch the console on the client Establish a secure connection from client to server: (non admin command prompt on client) :
net use \\scvmmserver\ipc$ /user:scvmmdomain
(note that if you've setup correctly you shouldnt be asked for a pw)
Now launch SCVMM console, and connect to server
(worked for me, your mileage may vary, if you cannot get this to work, follow John's blog details for remote Hyper-V admin console access from your client to the server - I had this working first, then added SCVMM console afterwards) I seem to get remote consoles and everything to my VM's as well, with the occasional disconnect - but hey.
BTW, unless an app is coded specifically to close all sessions and re-authenticate against the server or to 'get' the domain it's connecting to from the client (e.g ad domain tools) this trick should work for most apps like this that 'assume' (quite rightly) that everything is on the same AD domain, or a trusted domain.
Wednesday, June 02, 2010
Monday, March 22, 2010
Friday, January 15, 2010
stty -F /dev/ttyUSB0 speed 57600 raw cs8
stty < /dev/ttyUSB0
speed 57600 baud; line = 0; min = 1; time = 0; -brkint -icrnl -imaxbel -opost -isig -icanon
Friday, December 04, 2009
There's been quite a bit of activity over on the HomeEasy pages on Arduino.cc, and several people have mailed me to say that they have made progress with various HomeEasy related Arduino Projects.
Hi to David Edmunson, for posting his latest project for an alarm clock, (above) - nicely done - like the interface, clearly, unlike me - you can code in CSS (!) .
What am I up to?, and why have I been neglecting my blog?
Well, the day job is getting in the way again, but I do have *three* projects on the go that I will post updates for shortly - here's where I'm at:
BBSB RF Only Repeater
This is a really easy to build Arduino + TX + RX circuit that just does a dumb repeater job within our house - this is great as it now means that our BBSB messages get repeated all over the house and none of our devices miss a beat (mostly) - I will probably also extend this to repeat HomeEasy messages as well, as we now have a mixture of devices.
This is all built, and working just fine - I discovered that a couple of 15cm lengths of wire make far better antennas then expensive 433mhz stubby antennas purchased because they looked cool.
PIC Based BBSB 'Water Detector'
A couple of years ago, I came in from work one afternoon, only to find it was 'Raining' in our downstairs loo! - Our shower pump in the bathroom above had sprung a minor leak, and flooded the upstairs bathroom. Ever since then we've had a nifty little Velleman 'Water Alarm' wired up to a sensor under the bath where all the plumbing bits are. This works great, and makes a rude noise if the area under there gets wet.
(blurrycam pic , sorry)
This isnt very 2009 though, so it was high time it was empowered a bit. - a peeping alarm in an empty house is no use to anyone!
This little project is based around the PIC 12F675 microcontroller - which is less than £2 at Maplins, I ported the BBSB transmit code that works on the Arduino into the little PIC, resulting in a little 'module' or 'bug' that can send a BBSB ON or OFF code when an input changes status (high-low, low-high etc). I also built a little battery monitor into it so that it sends a signal every few days just to say 'Hi' to the house and confirm its still working! - I managed after a bit of fiddling to build this up with NO PCB, as the 8 pin chip makes a reasonable cowboy construction bed to solder the other components to ...yee-ha.
I dont have the PDF write up for this one done yet, but will post it with code etc as soon as I get around to it. - we also have a small battery drain problem currently Houston - or it has crashed, because it stopped calling in about a week after being installed. ahem! - so perhaps not quite ready for the primetime!
Yale Alarm Integration
This is more a not-even-half-baked-idea but appears to be a go-er.
We've had a Wireless Alarm for some time in our house, which works really well - I do however miss two things - 1) being able to arm/disarm it via the internet, and 2) being able to catch events from all the system's detectors around our house too and act on them.
Internet Alarm Arm/Disarm
The Yale protocol is not published anywhere, and so far my attempts to reverse engineer it have failed I'm assuming it's a code-rolling type system (like a car key fob, so unlikely to be easy to decode) - (I think Yale would also be happy about this too), but what is possible is to interface to the Alarm system via two of it's most commonly available components - a) the Keyfob Remote, and b) the Bell-box - both of which can be learned into the alarm system (even a 2nd bell-box) - The Bell Box itself can actually function as a stand-alone alarm controller on the cheaper Yale system , so in itself it's packed with circuitry and certainly knows if the alarm is ON or OFF.
I bought an extra bell-box from Ebay and learned it to our system, I binned the housing we can re-house it in a smaller box with the 'duino later), amputated the deafening siren (not needed!) and shorted the tamper switch closed (no thanks) - I was left with a little board that I could connect to the Arduino.
My prototype Arduino project monitors the status of the Alarm currently - this is possible because the 3 LED's on the Yale Alarm box have a 'flash' sequence that is different for arming, and dis-arming - by responding to these two different combinations of events, you can tell if the alarm was just armed, or disarmed - I will probably just send a HE or BBSB message via the Arduino when this happens, which will allow the rest of the house to respond to Arm/Disarm events - primarily enabling security schedules , and, more importantly, turning down the heating! -- This isnt really all that smart, as clearly if the Arduino powers-up it wont know whether it's On, or Off - some more probing around the circuit board for the bell-box unit may reveal more. There is definatley a pin somewhere for 'Siren going off' as well, so this should be not too hard to track down either.
As you might have worked out by now, the easy way to arm/disarm the Alarm using the Arduino interface is to connect some output pins from the trusty 'duino across the keyfob buttons for arm/disarm - again very nasty - but also very secure - provided you shut the remote in a box somewhere the entire unit can remain wireless with the Arduino onboard also - especially if you are using 433mhz messages to HomeEasy/BBSB when events occur. - I wouldnt recommend allowing the insecure protocols like this to actually 'do' stuff like disarm the alarm however, for obvious reasons - I will probably do this 'some other way' using cabling inside the house.
So - unfinished masterpiece currently, but perhaps more progress over Xmas on that one - if you have any ideas on this one, or circuit diagrams(!!!!) let me know - of if you just want to hack-along on this project, I'll set up a wiki or something.
Thats it for now.
Sunday, October 04, 2009
Saturday, September 26, 2009
Monday, September 21, 2009
Quite a few folks are activley monitoring using this hardware solution, but I think this solution gets the 'quick and dirty' award, as very little else is needed, the data is collected and posted using a little shell script, with no need for perl, ruby or other such stuff.
- We got the older CurrentCost Classic as the serial data comes out a little slower (9600baud) than the newer, shiny CC128 model, which suited hooking it up to stuff that cant swallow the data rate of the newer model.
- Get the CurrentCost USB cable as well, it has a USB/Serial converter built in , which you'll need unless you already have a separate one (CurrentCost serial port is 5v RS232, so hooking it up to a serial port directly will get you nothing or magic smoke 8-( )
- Unsling your NSLU2 so you can telnet/SSH into it and run stuff. (see links above)
- Hook your CurrentCost to the spare USB port on the NSLU2 (it should also work on a hub btw, but the device below may be different to mine.)
- run dmesg and look for the device ID of the serial port that is detected - ours was /dev/ttyUSB0
- Try this filthy script out - you'll need to edit it, to replace: YOUR_PACHUBE_API_KEY with your actual Key from your pachube account, and also your YOUR_FEED_ID in this file to get it to work. - I just have two integer values, one for watts, one for temp on this feed.
- Two little scripts are provided get-watts , and get-temp which should just echo the data from the CurrentCost to the console, as well as update-pachube which does the biz to the pachube service.
Footnotes: You may need to do some ipkg install magic on the NSLU2, you need grep, sed, cut and curl I forget which ones are in the slugos already.
The NSLU2 is a great platform for this type of stuff, the power consumption is less than 3w according to our killawatt, with processing power to spare, for ..... more stuff in the near future 8-)
UPDATE: An abusive co-worker who is attempting to follow my vague and inaccurate posting has reminded me that there are two missing steps in this post:
- You need to install some extra packages on your slug, I *think* these are:
- picocom - 1.4-1 - A minimal dumb-terminal emulation program. (you will want this to see what is happening on the com port from the current cost)
- libcurl - 7.19.5-1 (you need curl for the pachube posting)
- coreutils - 7.4-1 -(I think coreuils has cut in it, among other utilities)
(e.g # ipkg install picocom; ipkg install libcurl; ipkg install coreutils)
- You need to install the PL2303 kernel module so the USB-To-Serial cable is recognised. (following http://www.nslu2-linux.org/wiki/Peripherals/USB2Serial worked for my official currentcost cable) - after doing this check with dmesg for the name of the serial port to point to for your data.
Further abusive comments welcome from anyone, if this is still not correct 8-/ - my apologies.
Friday, September 11, 2009
I spent hours searching for a solution on the net, fiddling with Netsh, MTU sizes, switches and NIC drivers, until I spotted this blog entry. Turn off the Large Send Offload setting on the NIC. POW Fixed. Thanks to Daniel Petri. No reboot required.