For testing purposes a gateway has been made public. Please use http://dcgw.enocean-gateway.eu in the host field in case you want to check out EnOcean API's behaviour. You will peek events from Stuttgart, Germany and be able to send actions as well. You need to provide default credentials:
login: user pw: user ##### Use sample flow A sample flow is provided that includes a couple of predefined requests for enocean out and reveal its equivalent REST calls. - Open [flows/sampleFlow.json](flows/sampleFlow.json) in any editor and copy its content while using the import function in Node-RED menu bar in the upper right corner. - simply start Node-RED with `node-red sampleFlow.json` ### Quickstart Once your set up is done, you need to provide API-Origin by specifying host, port and credentials. This information will be held in a configuration node and is available to other enocean nodes as well. But your credentials are saved securely and won't be part of any exports. In case you've activated JSON encryption please prepend host field byhttps protocol instead of http protocol.
#### node - enocean out
This node facilitates flows in sending json objects to EnOcean API more easier than using HTTP modules.
enocean out is preferably used when a state change on a device needs to be applied, even though information can be retrieved too (e.g. requesting device states). A state can be requested on both, bidirectional and unidirectional enocean devices. Whereas only bidirectional EnOcean devices will accept changes to their state.
enocean out composes http requests and responds accordingly, when JSON messages are injected adequately. A json object is expected to contain a payload property that will address one resource out of state(s), device(s), profile(s) or API info. { payload: ... }
{"resource" : "states"}{"resource" : "devices"}{"resource" : "profiles"}Requests can be targeted, that will include more information for each resource. Specifically setting items array will result in a single respond for any item given. Valid items are provided with deviceId, friendlyId or any profileId.
Sample requests:
{"resource" : "states", "items" : ["FFDDBBCC", "kitchenThermostat"]}{"resource" : "devices", "items" : ["kitchenThermostat"]}{"resource" : "profiles", "items" : ["FFDDBBCC", "F6-02-01"]}The schema looks pretty much the same as requesting a state, except that you need to give a new state. A property identically named takes care of it.
{ "resource" : "states", "items" : ["kitchenLight"], "state": { "functions" : [{"key": "dimValue", "value" : "70"}] }}
Request a device profile gives indication on which information (key-value pairs) is needed. Pick one functionGroup (a set of key-value pairs) containing a direction to and provide at least any key-value pair that is not stated with a defaultValue. A key-value will be set with its defaultValue automatically whenever not given.
Feel free to use native REST interface by means of http nodes instead. More documentation is available here.
###### State and FunctionGroups Astate is represented by a set of key-value pairs and is encapsulated in a functionGroup. Each functionGroup specify the communication direction (to/from) in addition. FunctionGroups therefore represent information that can be held or had been hold by enocean telegrams. However, enocean profiles - widely used to organize EnOcean communication- sometimes specify more than one telegram or functionGroup per profile. Each device communicates by using at least one EnOcean equipment profile (EEP).
The function names with their interface specification can be retrieved anytime through HTTP requests in a syntax:Enocean device updates are being received in realtime and injected into the flow. A HTTP streaming connection will be established as soon as a flow is deployed and a valid configuration has been given.
Rather streaming than polling
enocean in node works independant and active in comparison to polling where it is required to request regurarly. Enocean api counterpart pushes events to enocean in actively.
Message objects will be passed and always define a msg.payload object in typical node-red manner. Expect any payload object to contain a header property that indicates what type of information does follow up.
states - last known device states, if one is availabletelegram - one device state eventExample message object (including a telegram):
{ "payload": { "header": { "content": "telegram", "timestamp": "2016-03-07T08:37:13.578+0100" }, "telegram": { "deviceId": "FEFEA199", "friendlyId": "4Button", "timestamp": "2016-03-07T08:37:13.578+0100", "direction": "from", "functions": [ { "key": "buttonAI", "value": "0", "valueKey": "released", "meaning": "Button released" } ], "telegramInfo": { "data": "00", "status": "20", "dbm": -88, "rorg": "F6" } } }, "_msgid": "f3ab21cd.0c54e" }
Assuming you want to limit events that happening, you may have a look to available filter options. Information type states can be omitted at all, although telegram events can be reduced to specific devices only. Furthermore a filter to direction can be set that will influence the output if the information has been received or sent by the API. That means requested device state changes are also events with direction to. Be aware that these messages have only been sent by the API not yet acknowledged by the actuator. In most of the cases you can ignore these messages and wait until a feedback (event) with direction from arrives.
More information on Enocean api you can find here.
### Author / Copyright (c) 2017 Digital Concepts | Dominic Böhler | @boehlefeld --- _Source: https://npm.io/package/node-red-contrib-enoceanip · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._