Three Lights in Three D Place!

I added two more rules. The first rule is in a light Thing/object to notify to its place that it's there. The link to the place is hard-coded for now until we get mutual discovery. The second rule is in the place and rather simplistically just adds any notified object at a fairly random location.

Here's what the Android app can then see, after starting up the place, then starting up the Pies - the three lights from yesterday, all automatically notified to, and located in the place object:

As you can see, I've touched them to set their colours. The actual LED behind one of them also changes, of course.

Next job is to advertise this place object instead of the third light, on my laptop. I've currently set a hard-coded URL and UID in the server and the Android app, but it should be auto-generated, like the light UIDs. Then I can get the lights to place themselves there - if they can somehow be coded to see BLE adverts like the Android app can.

Oh - that mysterious dark object in the background is a pretend light level sensor. When you set its light level below 100, all the lights come on white. This is the rule, which I discussed before. Eventually I hope to wire this into a Pi camera, which should be able to detect light levels, colour temperature and motion in a room.

Three Lights!

Well, progress is slow but steady. Now that I've identified each light Thing separately and am broadcasting unique URLs from my Java code, I've updated the Android app to list them all, unlike before when I just had one.

I gave them all the same name - "Light" - so this screen shot is kinda boring, but you get the idea:

This is picking up three BLE beacon broadcast URLs from two Pies and from my laptop. Jumping the link shows a different light running on that respective host. One of them actually changes the LED colour.

Next job is to put them all in a "place" object so I can "walk around" virtually in 3D and set their light colours. I'll get the laptop to broadcast a place object instead of a light, and have the Pies be two lights in that place.

Each has a signal strength, so once that's done, I'll be onto the AR algorithms for location and orientation, so that I can really walk around to get to them.

Nexus 4 conflict between WiFi and Bluetooth

I mentioned the other day how my Nexus 4 wouldn't allow me to use both Bluetooth and WiFi at the same time.

Well I did a little research, and found this issue describing the  problem.

Solutions may be: to use a different WiFi channel setting, or to switch to 5GHz. I'm using 11g currently, but I'll try 11n. Which I should be doing anyway, I guess.

I'll try these out and report back..

Update: I've no idea if it's using 5GHz or how to find out, but using 11n does seem to be working...

Java BLE broadcast

Finally got some Java code into NetMash to drive the BLE URL broadcasting today, instead of manually typing it into the command line.

Here it is, in case you're interested:

    void startBroadcasting(){
        byte[] ipbytes=UID.IP().getAddress();
        int port=Kernel.config.intPathN("network:port");
        String re="uid-([0-9a-f][0-9a-f])([0-9a-f][0-9a-f])-([0-9a-f][0-9a-f])([0-9a-f][0-9a-f])-([0-9a-f][0-9a-f])([0-9a-f][0-9a-f])-([0-9a-f][0-9a-f])([0-9a-f][0-9a-f])";
        Matcher m = Pattern.compile(re).matcher(uid);
        if(!m.matches()) return;
        String advert="hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 ";
        advert=advert+String.format("%02x %02x %02x %02x %02x %02x %s %s %s %s %s %s %s %s ",
                 ipbytes[0], ipbytes[1], ipbytes[2], ipbytes[3],
                 port/256, port-((port/256)*256),
                 m.group(1), m.group(2),m.group(3), m.group(4), m.group(5),  m.group(6), m.group(7), m.group(8));
        advert=advert+"00 00 00 00 00 00 00 00";
        exec("hciconfig hci0 up");
        exec(advert);
        exec("hciconfig hci0 leadv 3");
        exec(advert); // possible bug workaround
    }

    void exec(String command){ try{
        Process p=Runtime.getRuntime().exec(command);
        BufferedInputStream bis = new BufferedInputStream(p.getInputStream());
        int read;
        do{ read = bis.read(); }while(read != -1);
    }catch(Throwable t){ t.printStackTrace(); }}

Not pretty, but seems to work - there's a strange bug I haven't tracked down the cause of, which seems to be fixed by setting the advert data twice as you can see above.

This works on both my Pies, but the Android code is still too dumb to show them both. So that's my next task, plus showing the approximate distance between the phone and the Pies.

Alternative Approaches to the Object Network IoT

I recently mentioned a number of initiatives playing in the same space as my Object Network approach to unifying and animating the Internet of Things.

I've been reading up a bit on The Thing System, and have formed some early thoughts about the commonalities and differences between their approach and my own.

My general goals and philosophy are pretty much aligned with theirs. Adapting to many different Thing technologies, absolute minimum of configuration, open data and protocols, preferring automation over remote control, allowing people to write simple rules, etc.

The main difference is that my approach uses REST, with URLs to the state of Things, encoded in stable formats, and links between them, plus a programming model (and programming language) based on observation of linked state and state transition based on those observations.

These elements of the Object Net give a simplicity and mashability that the more imperative event- and agent-driven approaches lack. The documentation of the Thing System does reveal its complexity pretty quickly.

Looking around, here is another good list of IoT projects like the one I linked to before. Neither mentions the OpenHAB project, which seems at least as active as the Thing System. It is, however, based on an Event Bus and OSGi, both of which weigh against its chances of success in the real world. Maybe it'll attract Enterprise support, though.

In summary, I've yet to see another approach like the Object Network to unifying the IoT that is based on the original Web - with links between state. Most (all?) other approaches seem to be event-based.

Collecting the bits of the beacon URL: getting the host's IP number, etc.

In order to broadcast the URL of the Thing object, NetMash needs to discover the IP of the Pi host to put into the URL.

My Raspberry Pi has only one network interface with only one IPv4 IP address. In general, those 'one's aren't true. So in Java you have run a nested enumeration to find out the IP. Here's the algorithm I settled on today after some traditional stack overflow research:

    static public String findTheMainIP4AddressOfThisHost(){ try{
        Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
        while(interfaces.hasMoreElements()){
            NetworkInterface ni=interfaces.nextElement();
            if(!ni.isUp() || ni.isLoopback() || ni.isVirtual()) continue;
            Enumeration<InetAddress> addresses=ni.getInetAddresses();
            while(addresses.hasMoreElements()){
                InetAddress ad=addresses.nextElement();
                if(ad.isLoopbackAddress() || !(ad instanceof Inet4Address)) continue;
                return ad.getHostAddress();
            }
        }
        } catch(Throwable t){ t.printStackTrace(); }
        return "127.0.0.1";
    }
       

I'll actually need to return the InetAddress itself, for when I break it down into bytes to broadcast.

Also today, I put the light rules up on netmash.net, as Cyrus resources: here, here and here. Saves creating new objects locally for every light.

I also moved the light object itself out of a text database file and into the Java code, so that each light is generated afresh with a new UID, which it didn't do before. This means I really do depend on that broadcast URL now, or I'll never be able to find my light object!

All this is heading towards the Java NetMash code itself setting up the BLE beacon. I need to battle with the input and output streams of Runtime.getRuntime().exec() or use java.lang.ProcessBuilder to do that, because I don't think there's a Java API to the BLE stuff, so I'll have to call out to hciconfig and hcitool.

Finally, I found this RGB LED globe bulb again today, after I lost it:

All the circuitry is on the top, there, even if covered in white paint. I can hack into the RGB LEDs with a PCB cutter tool I have, and some gentle soldering. Three quid from Maplin.

Cheap Remote Controlled Consumer Products for Hacking

As the picture below shows, I just bought an AuraGlow RGB LED bulb (left in the picture) and a set of remote-controlled power socket switches (right). Obviously, as you can see, I've started thinking about how to hack the controllers..

They're pretty cheap: the bulb was £20 from Maplin, but there's a cheaper GU10 one for £15; the power switches were three for a tenner from Clas Ohlson. So this makes them appealing for the home hacker.

The bulb is driven by an IR signal, the switches by radio. I'm thinking I can just short the controller button pads with transistors driven by GPIO pins. Or if I can capture the bulb's IR protocol, it may be possible to send that directly. Hopefully there'll be separate R, G and B values sent, not just the preset colours on the controller.

Both controllers are powered by a 3V battery, which makes it possible to power them from the Pi.

I'll let you know of any developments..

Meanwhile, here's what my Christmas Pi looks like now it's been assembled with the slot cut in the top: