I recently added an initial support of the Somfy RTS protocol in Flock. Thanks to the rfxcom RFXtrx433e device, this was quite easy. For now only pairing a device and open/close commands are supported. This means that you can now control your blinds or gates with flock. Implementing this protocol required fundamental changes to the original design of Flock.
The main reason why changes were needed is the fact that a pairing action must be done before one can use an RTS device. This is obviously not specific to RTS and all reasonably secured protocols require pairing devices before they can communicate. However until now this was supported neither by Flock or Mastiff. As a reminder, here are the current components running on the concentrator:
Until now Flock did not save any information on the known devices. This was not really needed since the supported protocols packets were sniffed by the controllers (enocean and rfxcom). Flock just forwarded all devices events to mastiff and received actions from it. Initially I though that all the pairing stuff would be handled in mastiff. However after some deeper look at this part, it proved to be more complex than initially expected and made it difficult to abstract all the possible protocols and devices in flock. Now all discovered and paired devices are known by flock via a list of devices (the roster) that is persistent. Since Flock now knows all devices that are present, it also assigns to each of them a unique identifier which simplifies the communication with mastiff and other components : A device is now identified by its unique identifier and has some capabilities (such as temperature or power switch). This allows a real abstraction and mastiff does not need any knowledge on the protocol used.
At the same time I cleaned up the Message class that was supposed to be the message abstraction for all possible protocols. This was not the case until now since it contained some code specific to some protocols. Now it really defines an generic message type that can be used to set a value, retrieve a value, or pair a device. More actions can be added if needed. Such messages are translated to device packets via dedicated translators that are implemented in some message handlers.
The message router evolved since several message handlers can now exist for the same controller. Since the messages do not contain the protocol anymore, the router cannot route the message based on the controller. So it now forwards the messages to all handlers until one is handling it.
Another big change that was started is changing the frontend protocol from AMP to a derivative of msgpack-rpc. The twisted implementation is much easier to use than AMP, and I added publish subscribe to it. Moreover I think that it will be easier to use with another language.
Finally a flockctl executable is now available to control flock from the command line. This is useful for debugging purpose, or to test things that are not available from the mobile application… such as pairing a device!
Next steps
Some rework will probably be done on the handlers part: It would be better to remove inheritance between the handlers and the associated controller and use aggregation instead. I also expect mastiff to just disappear : When the xmpp client will be removed from it, it will only contain the status of each devices and I do not see any reason to add other features in mastiff. So I will probably rename it since its role will be different that what I initially expected.
All these evolutions are already available on github.