Sunday, October 07, 2012

Door Chime Repair 101

Following on my theme of repair, rather than throw away and replace ... my attention turned to my door chime - which had not been working properly for a while.

It's a simple model - an Arlec DC371 - $35 retail. After changing batteries in the receiver and transmitter, it was still not cooperating. But, in looking around inside the transmitter, I inadvertently pushed the button to select the tunes - and it sprang in to life.

So, I knew we had some basic functionality. I returned to the circuit board, and inspected the main micro-switch for the pushbutton. It had two leads protruding from the other side of the circuit board - so I shorted the switch output with a screw driver, and hey presto - it worked.

The cuplrit was the micro-switch. And they don't call them micro for nothing.



It looked a little daunting. The top plastic retainer was fixed by 4 little plastic lugs. I sliced those off, and underneath was a small plastic button, sitting on top of a flexible metal disc - which was slightly convex, so that it clicked when depressed.

Under the disc were 3 contacts - two at the sides, and one in the middle. When the disc was pressed, it closed the circuit between these contacts. I removed the disc, and tried shorting the contacts with a screw driver but this didn't seem to work.

I gave the contacts and the disc a good scrape with a sharp knife, and a clean with some vinegar. And this seemed to be enough to allow the contacts to work. Result.

The tricky part was re-assembling the switch, since I'd cut off the tops of the lugs. I turned to my trusty super glue - but the first attempt failed - since it seemed to find it's way in to the mechanism.

I broke it down again, cleaned the parts, and tried again. This time was successful.

So, it's now back in operation. No more complaints from family and friends that the door bell isn't working.

I know I could have bought a new one ... but it's the principle, right?

Thursday, June 28, 2012

Helvetica and Italics - at Central Station

Ok, so I've been meaning to put this up for a while. As a follow on from this post: commuting-with-helvetica ... I've realized that the station I'm at every day - Central - is a prime culprit of the Helvetica / Italics phenomenon.


I would love to know why:

  • people do this
  • how Queensland Rail can roll out a rebranding exercise, and not have consistent signage.
To recap - here's the original picture from Graceville station:




Monday, June 04, 2012

Toaster Repair 101

Dualit Combi
This is the story of one of my favorite kitchen appliances ... my Dualit toaster.

It's a Combi 2+1 model, and has given almost 20 years of faithful service - until the other day when the centre element shorted and died. Needless to say, it caused a bit of a calamity in our household. I've had it since the early nineties, when it was received as a gift from a wonderful friend in London.

Fortunately, I’ve long known that the simplicity of it’s design is one of it’s virtues. No electronic circuits. No fancy lights or displays. Just a simple mechanical timer. And most importantly, nearly all of the internal parts are user serviceable. I turned to Google in the first instance but was surprised to find no local distributor of parts in Australia.

But I did find what seemed to be a fairly reputable distributor with quite a shop front on EBay in the United Kingdom. I downloaded the instruction manual as a PDF document - which illustrated how to access the slots which hold the toaster elements. And how to replace the elements as well. This also showed the simple coding scheme which allowed me to match up my broken part with the appropriate replacement. I placed the order (which was around 20 dollars) and received it about 7 days later.

Inside - showing slots

I needed to wait until the weekend to find the time to devote to the replacement process - which is ok, since that’s when our major toasting happens.

I'm pleased to say that the operation went without a hitch.  The only issue is that the centre element is more efficient than the sides, leading to a slightly less even toasting result - perhaps I should have ordered replacements for all of the elements at the same time.

But, it does make you think. The fact that this and many other parts could be replaced didn’t happen by accident - it was designed in.

It also reminds me of an article in the New York times I’ve read recently, which highlighted a concept of ”Repair Cafes” in Amsterdam. The article is here: http://www.nytimes.com/...

These are places where members of the public can bring broken appliances and a team of volunteers attempt to fix them. What a great idea.

Imagine what could happen if we had products which are designed to be repaired - and communities to help support them.

Monday, February 20, 2012

Exporting Graphs from neo4j

I've recently had a brief introduction to the Neo4j database - by way of the YOW 2011 conference in Brisbane.

It looks really interesting - so I set about performing a few experiments. One of which is taking a graph and exporting it for use via other tools.

For example, here's a really simple graph - shown via neoclipse:
Sample Graph
And the code to produce it is like this:

Node nodeA = graphDb.createNode();
Node nodeB = graphDb.createNode();
Node nodeC = graphDb.createNode();
Node nodeD = graphDb.createNode();
Node nodeE = graphDb.createNode();


nodeA.setProperty("name", "A");
nodeB.setProperty("name", "B");
nodeC.setProperty("name", "C");
nodeD.setProperty("name", "D");
nodeE.setProperty("name", "E");


Relationship rel = null;
rel = nodeB.createRelationshipTo(nodeA, RelationshipTypes.DEPENDS);
rel = nodeC.createRelationshipTo(nodeA, RelationshipTypes.DEPENDS);
rel = nodeD.createRelationshipTo(nodeC, RelationshipTypes.DEPENDS);
rel = nodeE.createRelationshipTo(nodeC, RelationshipTypes.DEPENDS);

Nothing exciting to see there.

So, using the Cypher language for querying, I thought I'd investigate how to dump the graph structure so I could export it.

Assuming that A is the starting point of our Graph - just getting the nodes which are related to A can be found via this query:

start n=node:concepts(name="A") 
match (n)<-[r]-(x) return x.name, r

Results are:
+-------------------------+
| x.name | r              |
+-------------------------+
| "C"    | :DEPENDS[1] {} |
| "B"    | :DEPENDS[0] {} |
+-------------------------+
2 rows, 978 ms

But, to retrieve the whole graph, I require all nodes which have a relationship with A. So another attempt is this - allowing for multiple depth relationships:

start n=node:concepts(name="A") 
match (n)<-[r:DEPENDS*1..3]-(x) return x.name, r

Results are:
+-------------------------------------------------+
| x.name | r                                      |
+-------------------------------------------------+
| "C"    | List(Relationship[1])                  |
| "E"    | List(Relationship[1], Relationship[3]) |
| "D"    | List(Relationship[1], Relationship[2]) |
| "B"    | List(Relationship[0])                  |
+-------------------------------------------------+
4 rows, 100 ms

However, this doesn't help to recreate the graph. To do this, I need each source and destination node - and the relationship. The next attempt makes use of the fact that you can specify a minimum cardinality of zero of the relationship predicate - which allows you to include the start node as well. Using this allows us to construct a query like this:

start n=node:concepts(name="A") 
match p1=(n)<-[rel:DEPENDS*0..2]-(x)<-[r:DEPENDS]-(y) 
return n, x, r, y 

Which returns results like this:
+-------------------------------------------------------------------------------+
| n                  | x                  | r              | y                  |
+-------------------------------------------------------------------------------+
| Node[1]{name->"A"} | Node[1]{name->"A"} | :DEPENDS[1] {} | Node[3]{name->"C"} |
| Node[1]{name->"A"} | Node[1]{name->"A"} | :DEPENDS[0] {} | Node[2]{name->"B"} |
| Node[1]{name->"A"} | Node[3]{name->"C"} | :DEPENDS[3] {} | Node[5]{name->"E"} |
| Node[1]{name->"A"} | Node[3]{name->"C"} | :DEPENDS[2] {} | Node[4]{name->"D"} |
+-------------------------------------------------------------------------------+
4 rows, 31 ms

From here, it's a small matter of programming to iterate through these results, and generate an XML representation (for example, GraphML style) - like this:


<graph start="1">
  <node id="1">
    <data key="d0">A</data>
  </node>
  <node id="3">
    <data key="d0">C</data>
  </node>
  <edge id="e1" source="3" target="1">
    <data key="d1">DEPENDS</data>
  </edge>
  <node id="2">
    <data key="d0">B</data>
  </node>
  <edge id="e0" source="2" target="1">
    <data key="d1">DEPENDS</data>
  </edge>
  <node id="5">
    <data key="d0">E</data>
  </node>
  <edge id="e3" source="5" target="3">
    <data key="d1">DEPENDS</data>
  </edge>
  <node id="4">
    <data key="d0">D</data>
  </node>
  <edge id="e2" source="4" target="3">
    <data key="d1">DEPENDS</data>
  </edge>
</graph>


The first column of the result - N - is simple used to infer the start node. In this case, it's "A" - as specified by the query.