To integrate new building automation protocols (eg: zwave, zigbee, ...) you can create a dedicated plugin.
This plugin acts as a “translator” from Freedomotic generic commands to protocol specific commands and viceversa.
Your plugin will read data from the protocol and translate them into Freedomotic events to be notified to the framework. The event you want to notify usually is a ProtocolRead event; take a look at how to listen and notify events tutorial.
To bind an event to a change of the status of a specific object on the Freedomotic environment map you have two ALTERNATIVE choices:
High level communication protocols usually know if the readed value is a temperature, a binary state (true/false) or another kind of value.
In this case you can specify the object state directly in the notified event as following:
//protocol name= zwave, address=3 ProtocolRead event = new ProtocolRead(this, "zwave", "3"); //set the object state to powered=true event.getPayload().addStatement("behavior.name", "powered"); event.getPayload.addStatement("behaviorValue", "true"); // (OPTIONAL) specify a Freedomotic object class and name for the autodiscovery feature event.getPayload.addStatement("object.class", "Light"); event.getPayload.addStatement("object.name", "A Light"); //send the event to Freedomotic notifyEvent(event);
The drawback is that you plugin is now bound to this specific object implementation, so it will work only with objects that have a behavior called “powered” which accepts true/false values (BooleanBehavior).
To avoid bounding your plugin to a specific object implementation you can just notify the raw read hardware value and convert it into a valid behavior value using a hardware trigger (data source).
You’d choose this option if your communication protocol doesn’t know the object type. For example a relay board just knows if a relay is on or off but not if the wired object is a lamp or a coffee machine. It simply notifies an hardware read value.
The interpretation of the raw read value is done at configuration time,
because only the configurator knows what is really connected to the relay
board. This simply means to bound an object state (eg:
to a specific trigger that you (as developer) have to provide along
with your plugin.
For example if you are developing an Arduino based plugin you can define
a data source trigger called
Arduino Relay Board: readed value 1 in
first relay line. The mapping between the object state and your plugin
trigger, will make the object to become “powered” when the first relay
of the Arduino board is on.
As a note the object settings can be changed from jfrontend with a right click on an object on the map (Data source tab), like in the image below:
Freedomotic can request something like this to your plugin
relay 1 on board at 192.168.1.100.
Assuming the board communication protocol is HTTP based, the plugin should translate this into a proper HTTP request to the IP the hardware board is listening.
Your plugin will receive this generic command in the
method of your plugin and here you’d parse the command parameters with
and create the corresponding protocol specific request.
To know which variables are available to you plugin to perform its tasks take a look at the section Properties received by a driver plugin