Winter is coming, and the Northeastern United States where I live can get cold! And the houses are often old and drafty. So I built a wireless sensor system tied to a Nest thermostat to keep me cozy, wherever I am in the house, instead of keeping my thermostat cozy, bolted to its wall.
Yeah, they call it Bluetooth Smart now, but I don’t like that name! LE for me. 😉
DeviceHive managed the device registration for Sensortags, to make it easy to add new tags and wrangle them, and the wot.io data service exchange piped the messaging to scriptr for some transform logic in a convenient cloud service. bip.io did visualization and Nest control, and Circonus handled data logging and analytics.
Update: I have a forthcoming three-part series of articles on Texas Instruments’ e2e blog that dives into some of the hardware engineering behind this, too. I’ll link them here when it’s finally published!
I’m a coffee snob. I admit it. I’m proud of it. Although, upon reflection I really think it boils down to appreciating deliciousness. And who wouldn’t?
I discovered my drip coffee maker sucks at temperature regulation, and my pourover and French press technique has improved quite a bit. So has the coffee!
OTR is a good protocol for encrypted chat. I use it often, but have always wondered how to transfer my OTR private keys between computers and devices. Up until now, every machine would have a separately-generated key, and I’d have to re-verify keys with my friends before chatting. Always verify your keys! Today I finally looked around for where the keys are stored, on a Mac using Adium, and on a Debian Linux box using Pidgin.
The Pidgin OTR keys were easy to find. Pidgin is run under the hood by libpurple, and there was simply a .purple directory in my home dir. In here we find the OTR files:
The bit inside of the private-key section is the bit you want to transfer.
On the Mac, using Adium, you can find your OTR key files in the directory ~/Users/username/Library/Application Support/Adium 2.0/Users/Default but the contents are slightly different. Adium names the protocls differently. This is why it’s best to transfer the private-key section of the file only, and make sure you copy from and to the intended protocols.
You can also see the otr.fingerprints file, which has the list of verified (or simply seen) fingerprints for your friends. Copy that around also, and you won’t have to re-verify keys! You could also do this on your mobile devices in theory, but that’s going to vary widely, so good luck and have fun!
Make sure you don’t mess up the file access permissions during this process – you wouldn’t want someone to steal your keys! chmod 600 is probably what you want, but security is complex, so don’t take my word for your setup.
The Novena laptop’s Linux build doesn’t support the Samsung 840 EVO hard drive that it ships with. While this isn’t a problem specific to the Novena by any means, it will affect the users. It’s a simple fix, just edit the hddtemp.db file and add the proper ID string and temp code to it. You can just echo-append it, or if you are fussy open it in an editor and put it neatly in the Samsung section!
echo '"Samsung SSD 840 EVO 250G B" 190 C "Samsung SSD 840 EVO 250GB"' >> /etc/hddtemp.db
^---that space needs to be there; see below
If you want to find how to add this to hddtemp.db yourself, or on a different model drive that’s not in the db file, use smartctl and hddtemp --debug. The -A flag on smartctl lists the drive’s attributes. Look for the ID# for the temperature sensor. It also may indicate Celsius or Fahrenheit, but more likely it will be Celcius. Here we can see it’s attribute number 190, and based on the name, it’s in Celsius.
You can get the drive’s name with hddtemp --debug and also make an educated guess as to the sensor ID#. Notice the space in “250G B” below – you’ll want to use this exact model string in the db file. Not sure precisely why that space should be there, but from the hddtemp source it seems that’s how the drive identifies itself via SATA command. Perhaps other utils like smartctl get the name in other ways, or fix it up. I don’t have time to dig further on that…
[email protected]:~# hddtemp --debug /dev/sda
================= hddtemp 0.3-beta15 ==================
Model: Samsung SSD 840 EVO 250G B ï¿½@
field(5) = 0
field(9) = 170
field(12) = 12
field(177) = 0
field(179) = 0
field(181) = 0
field(182) = 0
field(183) = 0
field(187) = 0
field(190) = 34
field(195) = 0
field(199) = 0
field(235) = 8
field(241) = 50
If one of the field value seems to match the temperature, be sure to read
the hddtemp man page before sending a report (section REPORT). Thanks.
I was inspired in a fit of sleep deprivation, and took a crack at creating a logo for the Shellshock Bash vulnerability. If you like it, have fun with it. Released under the Creative Commons Attribution 4.0 International license (CC BY 4.0). Download Adobe Illustrator, EPS, SVG, and JPEG file archive here: Shellshock-Logo-1.0
Shellshock Logo JPEG
Shellshock Logo No Text JPEG
See? It’s like an old bomb! Made out of code stuff! That explodes all over your computer! 🙂
A friend was trying to import about 300K rows that were dumped with pg_dump. Trouble was, it would barf saying “Invalid Command \N” and never work. The attempted work-around involved telling pg_dump to use discrete INSERT statements per row, but this made it so slow it would have taken nearly 3 days, we guessed.
The actual error was above the Invalid Command messages, but scrolled away. Was able to see it like this:
Not sure if I needed the STDERR redirect there, but it seemed sensible and worked so I didn’t investigate further!
We ended up fixing the actual problem causing the Invalid Command messages, which involved pre-creating various bits of schema, relations, roles, etc., and using a data-only dump during The Big Import. The error was kicking the COPY FROM STDIN command to malfunction, and it tried to interpret the rows as SQL statements, which they are not.
Moral of the story, use COPY FROM and not INSERTs. There are plenty of other optimizations, turn off indexes and add them back at the end, and make sure your pg tuning is in order.