UPDATE: A few hours after posting this I got an email from the CTO of Withings.  He checked out the debug logs, and determined that the batteries that shipped with the scale were defective (voltage logs at the bottom).  According to Withings, the batteries should last 6 months on a good set of alkaline batteries.

The prompt and thorough follow-up by the CTO just shows how well they’ve thought out this product.  I don’t want this to be a full review, just a quick hack post, but I have to say the product is exceptional.  All the setup and out-of-box stuff was fantastic.  The Withings scale is a great product.

Nonetheless, I am sticking with AC power.

First thing you need is a power adapter or wall wart.  You’ll need something that outputs roughly 6 volts, and I’m just guessing on current requirements but 500mA should be more than enough.  I happened to have a Nokia phone charger laying around that was rated at 5.7V and 800mA.  Perfect.  If you don’t have things like that laying around, make a trip to Radio Shack and buy a 6V wall wart.

Next step was to determine the polarity and which of the battery contacts mattered.  The way these things work is that the metal tabs are just connect different ends of the batteries to each other in series.  So only 2 matter, the negative and the positive connected to the device.  They’re marked on this image:

Next up you’re going to strip the wires and determine the polarity of the wall wart.  I can’t think of any way to explain how to do this without using a voltmeter or at worst an LED.  Then again, if you don’t have a voltmeter around the house you probably aren’t trying to hack your Wifi scale to add a power adapter.

I could have made this next part a lot more complicated, but I am a fan of getting things done, not coming up with impressive complex solutions.   All I did was strip the wires, insert them behind the batter tabs, and pop the batteries in.  This pushed the wires against the case so hard, that there is no way they are going anywhere.

Since the batteries are there for no purpose but to hold the wires, and you’re leaving the middle 2 batteries out, they aren’t even part of the circuit.  I added a couple pieces of tape to keep everything in place, but they are very very snug anyway.

Magic:

I would really hope that the rev 2 of this scale would have a jack for a power adapter.  Using batteries for something like this is inexcusable.

[DBLIB] DBLIB_IE_PWR_DEBUG            : “6.49V (6.15V, 2.77Ohm)  97%”

4 days after you packed out the scale

[DBLIB] DBLIB_IE_PWR_DEBUG            : “6.23V (5.78V, 3.89Ohm)  77%”

1. Use a shared NAS or SAN drive and set all of the paths to the exact same path.  This would work well I think if you had extremely fast network attached storage.
2. Set them like I have, and make sure that all the nodes are running under the same username and the machines can access each other.  I don’t specifically know that this is how it works, but I’m pretty sure it is.

Here are the settings:

On your main cluster controller machine:

Advanced tab:

Setup tab for worker node:

Advanced tab for worker nodes:

Also, set this in Compressor->Preferences:

Download plugin.

First thing you need to do is create 2 theme folders.

theme1 is your original theme

theme2 contains the same theme, but with the changes you want to test

Set up 2 Google Analytics accounts.  This seems easiest to do with 2 different email addresses, and 2 browsers so that you can load both at the same time, and it doesn’t complain about the URL being the same.

1. Open theme1/footer.php and insert the GA code from one account into the footer before the </body> tag.
2. Open theme2/footer.php and insert the GA code from one account into the footer before the </body> tag.

That’s about it.  The plugin will drop a cookie on the user telling them which theme file to load.  If you want to completely change the themes, you can edit the plugin and change the cookie name to something new.  The cookie lasts for 30 days by default.

PS. I’m gonna admit right now that I almost always make mistakes the first time around.  If this doesn’t work for you – let me know.  If this doesn’t work for you and you figure out why – PLEASE hit me up and let me know so I can update this post.

P.P.S This could be pretty easily made so much better, easier to install, easier to use, and more flexible.  We’ll see if the demand warrants it.

Once I figured out the problem it was easy to fix. Even more convenient, I found this modified version of the pngfix that solved the onload hanging problem.

h8 IE.

Here’s a few thoughts:

I like Perl a lot for scraping, but PHP works too. Since scraping is kind of a rapid-prototype situation you should just use the tool you’re most comfortable with. The nice part about Perl for scraping is all the available modules to do various data mangling, and the ability to multi-thread it. I rarely write a scraper in PHP, but if you’re more comfortable with PHP by all means USE IT.

Scrape ALL THE DATA YOU CAN. You might think you only want one little bit of data from a site. Take everything you can and dump it into a database. Look, you’re pulling the page anyway, you might as well save everything in case you need it later. Dump everything into a database, and then pull out what you want from there into whatever you’re using it for. You’ll never regret having the full dump, but you will regret not grabbing everything when you need another bit of data and you didn’t scrape it.

Be smart about re-indexing it. Say you scrape somesite.com/id=123. Don’t put it into your database with id=123. Some day the site owner you ripped is going to notice all the IDs are the same and could use that against you. Re-index it. Going back to my previous point, keep THEIR ids in a database in case you need to rip some more data, you have their keys intact.

A lot of people worry about rotating or proxying IPs when they’re scraping. Don’t waste your time. I’ve yet to find a site (other than Google) that will actually be aware enough to block you for scraping. In the same vein, don’t piss-pound someone’s server when you’re scraping them. Put a sleep(1) in for christs sake.

Distributing your scraper? That might make sense if you’re planning on spidering or scraping a lot of sites. Use a common database and make sure your scrapers never cross paths. Its a waste of your resources as well as the site you’re pillaging.

Don’t overthink or overcode it. This is like anything else. I’ve literally seen people spend a week writing a scraper with a million bells and whistles. Just make it WORK and run it.

Be aware of cookies. Sometimes you’ll want your scraper to happily accept cookies, other times you want to make sure it ignores them. Depends on the site you’re scraping. Be aware that some sites will have interstitials or other things that will mess with your scrape. Cookies may or may not be away around those ads. Regardless, be aware of them and code accordingly.

Use Live HTTP Headers in Firefox if you’re struggling with understanding why you can access a site in a browser but your Perl script doesn’t get the same responses.

Don’t forget APIs. Sometimes you don’t even need to scrape, you can pull the data with an API. One time I wanted a database of like every CD ever made. Amazon API for the win.

Finally, remember, if a browser can access it, you can scrape it. If you can’t figure it out, you’re not trying hard enough.

Anyway I ended up choosing XSilva Lightspeed. For the most part we are very happy with it so far. The only thing I don’t like is that it doesn’t have a way to automatically email out reports. I’d like to see what kind of sales the store is doing on a daily basis. Since the whole thing is based on OpenBase/SQL, I figured it would be trivial to write some tools to generate and email my own reports. I did a quick search, and came to find out that XSilva keeps the database password a secret. Lame. Granted, I didn’t try to call their tech support and insist that I wanted it but it seems like from responses on their forum that they won’t give it up.

So here’s how to hack it:

On the machine that has Lightspeed and the server, fire up Lightspeed but don’t login. Open up a terminal, and I’m assuming you already have tcpdump installed.

/usr/sbin/tcpdump -i lo0 -s0 -c 1000 -x -w dump

Run that tcpdump, and then login to lightspeed. Once LS has logged in, you can Ctl-C the tcpdump.

Now use ngrep to pull out the login information from the dump file:

ngrep -wi "dbpassword" -I dump


The output of this looks like:

input: dump
match: ((^dbpassword\W)|(\Wdbpassword$)|(\Wdbpassword\W))
##################################
######################
#########################
T 127.0.0.1:56526 -> 127.0.0.1:20223 [AP]
....|dict|....action....call_register....usersAllowed....1000
....dblogin....lightspeed....dbpassword....adminXXXXX....userlogin....light
speed....hostName....192.168.3.180....databaseName.
...xsilva_db_217demo....softwareId....Lig
htSpeed:REALbasicCM....processId....0016CB08
4925_21777781....
########################


See the adminXXXXX? That’s the db admin password. I redacted the actual string. I’m HOPING that they actually use a random string for every LS install. I didn’t verify on another install that its different. If not, I don’t really want to publish the password for every LS SQL database. However, they are retards if they don’t use a random secret.

Now you can go nuts on the database.

Update: I’ve verified on 2 installs that the admin password for the SQL is the same. Lesson here: firewall off your POS or anyone can modify your store database.