Channel for every Xbee and Pin

Hi, I have made a small change in the script that generates the mosquitto message. I have added the remote64 address to topic and the pin values for every pin in digitalSamples and analogSamples.

`function publishXBeeFrame(frame) { if (!isConnected()) throw new ReferenceError("MQTT not conencted."); if (!frame) return; / don't publish empty frames / var topic = rootTopic + '/response';
var message = JSON.stringify(frame); /////Addes var response = JSON.parse (message); topic += '/' + response.remote64; var digital = response.digitalSamples; var t = 0; for (var i in digital){ topic += "/" + Object.keys(digital)[t]; message = digital[i]; log('debug', 'Sending: ' + topic + ': ' + message); mqtt.publish(topic, message); t++; }

var analog = response.analogSamples;
t = 0;
for (var i in analog){
  topic += "/" + Object.keys(analog)[t];
    message = analog[i];
    log('debug', 'Sending: ' + topic + ': ' + message);
  mqtt.publish(topic, message);
    t++;
}

So in my environment (openHAB2) is easy to access to very pin value.

I've been thinking about this quite a bit and it comes down to this: Should IO sample frames be parsed and published by the XBee gateway (ie. xbmq), by the subscribed mqtt client application, or somewhere in between? Given that the goal of xbmq is to "do as little processing as possible", I'm not sure the gateway is the place for this.

Parsing IO Samples and publishing to multiple topics seems like a trivial addition, but it gets more involved trying to ensure two-way communication. For example, in order to drive XBee OUTPUT pins via mqtt, the gateway would need to subscribe to additional IO topics, parse incoming messages, build XBee frames, and transmit them to the XBee network.

Likewise, a client application could be a simple or low-power device that also wants to do as little processing as possible, and it's certainly simpler to create a client application that can respond to events on a single mqtt topic without any parsing or filtering of XBee frames. I'm not an openHAB user but perhaps it (or similar applications) doesn't even provide a mechanism to parse or filter frames!

The solution is to keep both sides simple: Have the gateway only publish complete frames, and use a server in between the gateway and the client if extra filtering or parsing is required. An mqtt broker is required anyway, so why not use node-red, or some other app to filter, parse, format, transform or even re-publish messages to application-specific topics, or anything else?

angryelectron / xbmq-js

Channel for every Xbee and Pin #12