What is Pebble talking about?

The Pebble smartwatch is one of the most popular smartwatches. Sofar 1 million smartwatches  have been sold, which made the Pebble the second best selling smartwatch of 2014 according to the Smartwatch Group. Probably due to the relative low price point of the Pebble, and their tech oriented user/developer community,  the company seems to stay a bit under the rader in terms of market share. At this moment Pebble has started a new chapter in their story with a new kickstarter campaign for the Pebble Time, a smartwatch with a color display. With their second Kickstarter campaign they recaptured the position as most funded project with more than $18 million dollars in pledges.

Due to the availability of SDK’s, a large developer community, onlin development environments, lots of samples, the Pebble smartwatch is a very developer friendly smartwatch. But it’s always interesting to explore the possibilities and inner workings of the Pebble even further.  For example, the wireless communication between Pebble and your telephone. How does it work?

When a Pebble is coupled to a smartphone, they communicate via an emulated serial port (RFCOMM) where both the watch and phone exchange binary encoded messages with each other. The innner workings of this protocol was disclosed by Hexxeh (Liam McLoughlin) with his release of the LibPebble library, a Pebble communication library written in Python. While most of the data communication between Pebble and Smartphone is known, the communication pattern i.e. ‘when to say what’ is not completely clear.

Messages sent from phone or Pebble have a variable length and make use of the same encoding. All messages start with a four byte header that specify length and endpoint. The first two bytes contain the length (unsigned integer) of the encapsulated message. The total message length is thus, this length specified in the header plus, the four bytes of the header itself. The last two bytes of the header contain the endpoint (unsigned int) of the communication, and specify the communication type of the encapsulated message. Examples of endpoints are: application messages, logs, and time. And each endpoint makes use of its own message structure.


Pebble message structure
Pebble message structure


While LibPebble is great, it seems that it does not implement the complete Pebble bluetooth protocol. For instance DATA_LOG type messages (endpoint 6778) are not described. And that is where Android developer mode, and Wireshark come to the rescue. With an android phone, all bluetooth traffic can be captured in a logfile. This logfile can be loaded by the Wireshark network sniffer and protocol analyser. And on top of that we can add a custom dissector for the Pebble protocol so that we can closely follow what the Pebble is talking about!

In order to get it all working, you need to have an Android smartphone with developer mode enabled. If you don’t know how to do that, It is probably better to stop reading this post, and find your luck elsewhere.  The Developer options contain an option to enable logging of all bluetooth traffic. When this option is checked, a file (located at: /sdcard/btsnoop_hci.log) is created that traces all bluetooth traffic.

enabling bluetooth logging on Android

When you think you have traced enough, transfer the btsnoop_hci.log file to your PC and open the file in Wireshark.

The only thing we need to do is create a dissector for Pebblish, the protocol spoken by the Pebble, and make this dissector available for Wireshark. For this purpose I wrote a minimalistic dissector in Lua that extracts the length, endpoint of each message, and the start of application messages.  The code for this dissector is available on Github

I’m not going to explain how to add the dissector to Wireshark. There are more than enough good tutorials available on the web that explain how to do this (for example here).

When the  dissector is enabled and the btsnoop_hci.log is loaded in Wireshark, use ‘pebble’ (without quotes) as the filter expression to show only the messages sent/received by the Pebble smartwatch. The result is shown below in the screenshot that displays the conversation between Pebble and smartphone.

Wireshark showing a Pebble conversation

Although the dissector is far from complete, it already gives a lot of insight in the conversation between the Pebble and Smartphone.

OBS de Molshoop

Het ziet er nu echt naar uit dat OBS de Molshoop, de openbare school in Noordhorn, gaat verdwijnen. Woensdag 28 mei hebben de schoolbesturen van Pentaprimair en Westerwijs het besluit voorgenomen om de twee scholen in Noordhorn (het Kompas en de Molshoop) te laten samengaan in een nieuwe samenwerkingsschool. Als alles gaat zoals het is geplanned, begint de nieuwe samenwerkingschool met ingang van het volgende schooljaar.

Tot zover het zakelijke gedeelte, nu word het tijd voor afscheid nemen van een lange periode openbare school in Noordhorn. Een van de dingen waar ik met veel plezier aan terugdenk zijn de ‘molletjesranden’. Dit zijn tekeningen van een klein molletje voor bovenaan de pagina van de schoolkrant. Deze zijn ooit gemaakt door een artistieke ouder. Het molletje is steeds iets anders aan het doen, meestal passend bij het onderwerp van de betreffende pagina van de schoolkrant.

mollenkop lees L

Mijn relatie met het molletje was best intensief, al is het alweer even geleden. Bij het layout-en van schoolkrant, en lustrumboek heb ik ook heel wat tijd besteed aan het precies plaatsen van deze molletjes.

Maar nu komt ook de tijd om ook van het molletje afscheid te nemen, en dat doe ik op mijn eigen, gepaste wijze, in de vorm van een app voor de Pebble smartwatch. Het is een klokje geworden waarin de resterende tijd tot de laatste schooldag wordt teruggeteld, waarbij steeds een ander molletje is te bewonderen. Dan ziet het er als volgt uit:


pebble-screenshot_2014-06-01_21-01-49 pebble-screenshot_2014-06-01_21-06-41



  • De broncode voor de watchapp staat op mijn github account (link)
  • De watchface zelf staat in de Pebble appstore, en wel (link)
  • Directe installatie link voor de Pebble (moet je wel een Pebble hebben, uiteraard)  (link)



Home Automation Spaghetti

Lightweight message brokers like mosquitto, that makes use of the MQTT are of great use in the world of home automation and the Internet-of-Things. With MQTT, functionality like interfacing with specific hardware, interfacing with webservices, reading/writing databases can be dived into separate programs/scripts instead of putting everything together in a complex monolithic application. This provides flexibility, and a means to extend existing functionality by listening in on existing MQTT topics, that already being published.

What I like about a lightweight message bus is illustrated by the following example which I’m actually using at the moment. One program (a perl script) is connected to the OVMS webservice, where it listens to updates on the status of my electric vehicle, a Twizy, and publishes this data   (location, state of charge, speed, …) in the form of a JSON encoded object via MQTT. Another program, which is driving a LED matrix display (located in the kitchen), is subscribed to these MQTT messages, and uses them to display the actual charging state on the display.


UntitledWith this in place, It is possible to add a third program that writes all data to file, a fourth program that switches a wall outlet when the state-of-charge has reached 100%, a fifth program that plays an audible message when the Twizy is arriving home, a sixth .. etc. etc. While this setup is great, and is very, very flexible, the relation and dependencies between publishers and subscribers if written in program code, and therefore difficult to understand.

And that’s where Node-RED come into the picture. Node-RED is visual tool that displays the process flow between (the spaghetti) between a number of building blocks. With Node-RED it is possible to visually design a flow that, in the context of the previous example, trigger on messages from the Twizy, transform these in to readable text, and publish them to a LED matrix output. It is still spaghetti, but now it’s visible. A sample flow that I built recently is that where updates from the Twizy (received through MQTT, which is the block on the left), are routed based on changes in distance or charging state (blocks DISTANCE and STATE), transformed into a set of different messages, and then publised to a Text-to-speed engine (SONOS), or mobile phone (with Notify My Android).


















Update: A beta version of Pebble My Tracks for the Pebble smartwatch with SDK 2 is available in the google play store here

Earlier this year, I released an android application to connect the Pebble smartwatch to google MyTracks. Most important feature from my perspective is that a whole session can be controlled from the Pebble watch so that the phone can be packaged in a safe (watertight) bag.

In the last months I tried to get the application stable enough to release it in the google play store. Sofar I did not reach that goal. i repeatedly run into problems with the bridge connection between MyTracks and my app. This is one of the reasons for making the source code of PebbleMyTracks available for everyone.

The source is available on github: https://github.com/pieterjm/PebbleMyTracks

Please send me your comments and improvements.



MyTracks on the Pebble

I consider myself as a heavy user of the MyTracks app (android) for sports tracking. My primary goal for the Pebble smartwatch was to connect it to MyTracks. For example that track recording/pausing/viewing could be done with the watch only, and the smartphone could be left inside a (waterresistant) pocket.

The great thing is that MyTracks has a sharing feature, which makes integration with third party apps possible. This MyTracksAPI is briefly documented, and includes a working example.  With the availabillity of two-way Pebble communication time has come to connect MyTracks to the Pebble.

I made a few modifications to the MyTracks watchapp, described in this post, and modified the MyTracksAPI example into a BroadcastReceiver and Service running in the background. The BroadcastReceiver receives button presses from the Pebble and forwards these to the service. The Service is connected to MyTracks and does all the work like getting current speed, starting/stopping (with the select button), pausing/resuming (with the down button) tracks. And everything works without touching my smartphone. The MyTracks watchapp is started from the Pebble menu.

Disclaimer time! While everything seems to work ok, it is not my intention to create a full fledged WatchApp with rock solid integration with MyTracks.The communication with the Pebble is an undocumented feature, and maybe changing in an upcoming SDK update. Although my code works (at least on my pebble, and my smartphone), it is just a prototype to see if it works.

CloudPebble project export of my MyTracks watchapp: MyTracksWatchApp.zip

Java sources of the BroadcastReceiver and Service: PebbleMyTracks.zip







Pebble communication

While still waiting for the official release of the Pebble SDK that supports two communication I stumbled upon this website that claimed that two way communication is working. I made a small pebble watch app based on the button app with CloudPebble. And much to my surprise It just seems to work! Pushing data from the phone to the watch and sending data from the watch back to my android smartphone.

Video: https://www.youtube.com/watch?v=76xif5k7DPQ

Source code: test_two_way_pebble.zip



Connecting the Twizy

A post on the twizyowners forum about timed charging the Twizy triggered me to document me recent progress in Twizy and home automation hacking and write this post. In this post i’m trying to explain how I connected the Twizy to my home automation system, and controlled charging of the Twizy. Until recently we just plugged in the AC cable of the Twizy when arriving at home (in fact we still do). But what annoyed me was that a ventilator kept on running for hours and hours while Twizy charging was completed. What I wanted to do was disconnect the plug from the socket when charging was finished to avoid (from my perspective) unneeded energy consumption. The most simple and robust method for achieving this is walk to the garage and unplug the Twizy. I decided to do it automagically via home automation. A complete schematic of the whole setup is depicted below.

Connecting the Twizy to a home automation system can be approached from two perspectives: 1) receiving status updates from the Twizy and 2) controlling the Twizy

Receiving status updates from the Twizy

Our Twizy is extended with a so called OVMS Module. The OVMS module is a small device (with GPS and GPRS) that talks to the CAN-bus of the Twizy. OVMS stands for the openvehicle open source hardware/software project. Details on this project and how to get the OVMS module are available on the open vehicles website (http://www.openvehicles.com).

By default the OVMS module is configured to log status updates (GPS location, State of charge, Temperature, Speed, Odometer, and much more) over the Internet to a central server hosted by the open vehicles project. When communicating with the Twizy, you connect to the OVMS server instead of the car. A sample client application in Perl is provided on the github site of the project (client_app.pl). In order to get this client running you probably need a Linux compatible system, install the required perl modules, and create a small configuration file (ovms_client.conf) where you must enter the location of the OVMS server and your OVMS module credentials. The client_app program does not really ‘do’ something. When started, it connects to the OVMS server, decodes and prints out status update messages from the Twizy.

In order to connect the Twizy to my home automation system I modified the client_app.pl script so that the content of messages is decoded into understandable data (GPS location, charge status, speed, odometer, etc) and the the Twizy status is made available to other applications via an MQTT message broker (mosquitto). My modifications to the script can be downloaded here (client_app_mqtt.zip).

Control the Twizy

For now the only Twizy control I need is switching the AC socket for charging. For this purpose I make use of a Conrad/ELV FS20 wireless switching socket (link). This switch is triggered by an 868Mhz OOK encoded protocol. Luckily, the JeeLink is capable of transmitting this protocol.

The OVMS client application contains a rule that when the state of charge (SOC) reaches 100%, an MQTT message with the topic ‘FS20’ is being sent. The contents of the message is a JSON encoded structure with the details of the FS20 message (address of the socket and command 0 for off and 17 for on)

if ( $status->{soc} == 100 ) {
} else {

The JeeLink – MQTT bridge script (see this post)  subscribes to the ‘FS20’ MQTT messages and forwards them to the JeeLink. A modified version of the JeeLink-MQTT bridge which encodes FS20 messages is available here. The JeeLink then transmits a FS20 protocol message and the socket is switched.

A perl JeeNode MQTT bridge

This is a perl implementation of a bridge between the MQTT pub/sub message bus and the JeeNode wireless network. This MQTT bridge makes it a lot easier for me to implement home automation logic. Where device specific features (heating system, radiator valves,. washing machine, energy metering, electric vehicle, status display) are implemented most with JeeNodes, the logic that binds everything together (and makes home automation working) can be done in a higher level scripting or programming language.

An example of this logic i’m using is to switch off an AC wall outlet at the moment our electric vehicle reports that it is fully charged: Our EV is monitored through a client script watching the OVMS server (see my previous post). MQTT messages containing the battery status, car location, current speed, odometer are sent at regular intervals. At the moment the battery capacity reaches 100%, an MQTT message is sent which triggers the car charger AC outlet to be switched off.

The bridge implementation can be used to forward packets in both directions: MQTT messages of specific topics are forwarded as packets in the wireless JeeNode network. Packets received from other JeeNodes are forwarded as MQTT messages.

The MQTT bridge implementation is written in perl and should run on at least any Linux like server. makes use of two seperate threads, one for communicating with a JeeLink attached to a USB port. The JeeLink runs the standard RF12demo sketch. The second thread waits for subscribed MQTT messages sent by a MQTT server (in my case mosquitto) and forwards these via a queue to the first thread.

The perl script depends on several perl modules, most important are WebSphere::MQTT::Client, and Device::SerialPort. Both can be installed through the commands.

perl -MCPAN -e "install Device::SerialPort"
perl -MCPAN -e "install WebSphere::MQTT::Client"

The perl script can be downloaded here








Cosm Popularity

How popular is Cosm? I consider myself as a heavy user of the free Cosm webservice for storing all sorts of sensor data (home, energy, washing machine, sports). Not that I am a huge fan of the service for this moment its ok for me. Features like triggers, debugging and privacy groups are really helpful.

But somehow I always get the feeling that Cosm is not really taking of, and that the number of  subscribers (usually very important for a free service) is not enough to create a profitable business.

To get insight in the growth of Cosm, I used the feedid, identifier of a stream of sensor data and the fact that most feeds are public.  This feedid is a positive integer, newly created feeds always have a greater value of the feedid than older feeds. To me, the feedid looks like a simple counter, possible proportional to the number of feeds.

What I did was the following: I loaded ‘http://www.cosm.com/feeds/<feedid>’  in my webbrowser, and wrote down the creation date of the particular feed.  Then I requested the same url, but now for another feedid. So I queried Cosm from 0 to 85000 in steps of 5000. What I got was the following chart.

In contrast to what I thought, the number of feeds (and probably users) is still increasing. Also the amount of increase (now approx. 160 feeds per day) is growing.

Coming back to the initial question about the popularity of Cosm. The trend for Cosm seems to be ok, but will it be enough for them?


Wachten op de Pebble

In mei 2012 heb ik meegedaan met de crowdfunding van de Pebble. De Pebble is een slim horloge dat in verbinding staat met je mobiele telefoon. Met de Pebble kan je door middel van apps berichten lezen, gemiste gesprekken zien, de muziek bedienen of als sportcomputer gebruiken. Die apps kunnen naar wens worden geinstalleerd of zelf worden gemaakt met de Pebble SDK.

Zelf ben ik van plan de Pebble te gebruiken tijdens het fietsen, skeeleren en schaatsen. Kan je zonder je telefoon uit je broek/jas/achterzak te halen zien hoe hard je gaat, of hoeveel kilometer je hebt gedaan. Dan is zo’n horloge een stuk makkelijker. Op dit moment gebruik ik daar nog de LiveView (van SonyEricsson) voor. Met de Pebble moet dat als het goed is een enorm stuk verbeteren. Met name het display van de LiveView is met een beetje zonlicht niet meer te zien. Het e-paper display van de Pebble is juist bedoel om buiten met direct zonlicht goed te kunnen aflezen. Ik ben benieuwd.

De crowdfunding van de Pebble was (in ieder geval voor de makers van Pebble) een magesucces. In totaal is meer dan 10 miljoen dollar opgehaald! De makers zijn aan de slag gegaan, en via updates om de drie weken worden de ‘backers’ (iemand die geld heeft gestoken in de Pebble) op de hoogte gebracht van de voortgang van het project. Er wordt nog geen definitieve opleverdatum gegeven vanuit de gedachte dat het missen van een deadline erg nagatief is. Door de inhoud van de updates krijg je goed inzicht in de voortgang, en kan je zelf zien hoe het staat met de Pebble: De eerste pre-production van de Pebble is gedaan. Nu volgen een aantal cycli van testen en produceren alvorens de uiteindelijke massaproductie wordt gestart.

Inmiddels is het Oktober 2012, en is de Pebble nog niet af. Tijdens de initiele crowdfunding is een geschatte oplever datum van september afgegeven. In het forum en ook op Twitter is goed te merken dat er Backers zijn die het wachten zat zijn, of moeilijk kunnen omgaan met de onbekende opleverdatum. Ik ben benieuwd hoe dit uitpakt voor Pebble. Volgens Pebble wordt de frequentie van de updates opgevoerd naar om de twee weken.