As mentioned previously, the kit I bought has 2 sockets. But knowing that the remote can control 4 (it has a total of 8 buttons), it would be good to be able to use the remaining unused buttons. And why not, since the state of the socket can't be retrieved, to intercept and store the current state.
Maybe there is a way to squeeze yet another protocol?
It turned out that it was quite easy to do without much interference to the existing two decoding pipelines!
Meet the 433Mhz receiver
Basically, the signal from the remote will appear as a series of High pulses which are shorter (~ 320µS & ~ 960µS) compared to the one from the sensors (~ 500µS/1300µS and 1900µS/3800µS). If a string of these specific pulses is detected, then we switch to the remote decoder.
The signal being sent at least 3 times from the remote, this mean that we can intercept the second or the third transmission. The transmission itself starts with a "very long" pulse (31 times the base pulse). The encoding is based on a tri-state system which basically means, since we can ignore the floating state, that every other bit must always be a 1. The data consists in the address part, the button part and the state (ON/OFF) repeated but inversed.
For example:
101011101011101010101110
can be decoded in (checking then removing all the odd bits):
001001000010
and interpreted as:
address (DIP switches): off-off-on-off-off
button: A
Action: On
Code
Since there is now a little bit more than Lacrosse sensor decoding, I renamed the project on GitHub to 433Mhz receiver...
Since I embraced the MQTT protocol, I added the conversion and now any touch on the remote control is translated into something like (to carry on with the example above):
Topic: cm/remote-00100/action/a
Payload: {"ts": 1451215192, "value": "on"}
The first part is complete. Hooking up a 433 Mhz emitter (remember this?) on the Raspberry Pi is easy but for both technical and whimsical reasons, I have something else in mind...
A few days ago, as I was in a nearby DIY store (looking for something I didn't find in the end), I came by the Electricity aisle and noticed cheap remote sockets. These are a not new thing, I owned some more than 25 years ago — so unstable there were switching on and off randomly — and in France at least, the Belgian company Chacon made a successful product (DI.O) with this kind if items.
One of the major issue with them is that they are without any feedback of the status like you could have on a modern "smart plug". Yet, where a Z-wave socket alone is at least 40€, here a pack of 2 sockets was less than 15€ including the remote and its battery. The "manual" includes a EC Declation of Confirmity so I assume there are safe to use. The power is limited to 1000W but for Christmas lights, this is not an issue!
Obviously, the idea was also the do the reverse engineering on the protocol and if possible try to emulate the remote itself like I did several times in the past. Turns out that this very model of remote is used in dozens of packs and the circuit inside is well known and even officially documented!
Protocol and Home Automation
A quick search show pages and pages on the subject. These one are now called "Smart Home" but were previously sold under the Phenix brand by IDK. Protocol seems virtually identical to the Elro Home Easy plugs.
The next question was: What is the best to integrate these elements in the existing installation? There are two main parts for this: controlling the sockets but also making the most of the remote (especially the two unused ON/OFF buttons).
MQTT used to be the acronym of MQ Telemetry Transport but is now just MQTT is now a OASIS standard for Machine2Machine data sharing. This protocol was invented by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now Cirrus Link) in 1999 and was designed for connections with remote locations where a small code footprint is required or the network bandwidth is limited.
Tutorials
The best explanations I found on the subject come from a series of blog posts by HiveMQ (even if I don't use their product):
There are other posts about security and clients but I think that the ten ones referenced above are a very good introduction.
Basic concepts of MQTT
There is also a IBM redbook called Building Smarter Planet Solutions with MQTT... which is a little bit old and geared towards IBM Websphere MQ product but still interesting and another good presentation of this protocol. Moreover it is free and available in numerous formats.
Extract from the book (chapter 1.2.3):
The MQTT protocol is built upon several basic concepts, all aimed at assuring message delivery while keeping the messages themselves as lightweight as possible.
Publish/subscribe
The MQTT protocol is based on the principle of publishing messages and subscribing to topics, which is typically referred to as a publish/subscribe model. Clients can subscribe to topics that pertain to them and thereby receive whatever messages are published to those topics. Alternatively, clients can publish messages to topics, thus making them available to all subscribers to those topics.
Topics and subscriptions
Messages in MQTT are published to topics, which can be thought of as subject areas. Clients, in turn, sign up to receive particular messages by subscribing to a topic. Subscriptions can be explicit, which limits the messages that are received to the specific topic at hand or can use wildcard designators, such as a number sign (#) to receive messages for a variety of related topics.
Quality of service levels
MQTT defines three quality of service (QoS) levels for message delivery, with each level designating a higher level of effort by the server to ensure that the message gets delivered. Higher QoS levels ensure more reliable message delivery but might consume more network bandwidth or subject the message to delays due to issues such as latency.
Retained messages
With MQTT, the server keeps the message even after sending it to all current subscribers. If a new subscription is submitted for the same topic, any retained messages are then sent to the new subscribing client.
Clean sessions and durable connections
When an MQTT client connects to the server, it sets the clean session flag. If the flag is set to true, all of the client's subscriptions are removed when it disconnects from the server. If the flag is set to false, the connection is treated as durable, and the client's subscriptions remain in effect after any disconnection. In this event, subsequent messages that arrive carrying a high QoS designation are stored for delivery after the connection is reestablished. Using the clean session flag is optional.
Wills
When a client connects to a server, it can inform the server that it has a will, or a message, that should be published to a specific topic or topics in the event of an unexpected disconnection. A will is particularly useful in alarm or security settings where system managers must know immediately when a remote sensor has lost contact with the network.
Naming of Topics
If the best practices are rather well defined and mainly:
Through trial and error, I finally settled for the following formats:
group_id/sensor_id/action/action
group_id/sensor_id/data/measurement
group_id/sensor_id/status/heartbeat
For example:
cm/alecto1/data/temperature
cm/alecto1/data/humidity
cm/doorlock/data/status
cm/lcd/status/heartbeat
z-wave/fgk101-1/data/status
z-wave/fgwpe101-1/action/set
Payload
Another problem comes with the payload format. Sometimes the format is part (usually a postfix) of the topic (it is the case with IBM or Xively). It might make sense when the source of data is diverse and unknown but I really don't like it, specially for something all integrated.
At first, I tried to prefix all payloads with a indication of the format. But the result was really different from all the examples and productions I could see around.
Thinking about it, I needed only 2 main "forms" of data:
single value
dictionnary type data: key1="value1" key2="value2" ...
JSON is able to deal with the former case by default. For the single value, it can handle all integer and float values directly. For strings, it is a bit more complicated as string should be between quotes. So the idea now is simply:
First try JSON decoding
If there is an exception, fall back to the raw value
Brokers
There are quite a few brokers around (see here or here) but so far Mosquitto has been perfect on the Raspberry Pi: easy to install, fast and irreproachably stable.
Even the bridge mode between two remote locations worked perfectly the first time.
Just last week, I was mentioning the existence of Minibian which is basically a Raspbian Jessie but with a minimum set of pre-installed packages.
Raspbian Jessie... Light
And a couple of days ago, the "Raspbian Jessie Light" was anounced! (I don't know if it is linked to the Raspberry Pi Zero release, but one can say that they were focused on reducing things this week!)
I haven't tried this new distribution yet but it can be downloaded on the official download page and more info about it is available on the forum.
