MQTT Broker gateway
-
I'm currently busy implementing an mqtt client plugin, and i'm going to use mysensors for it's first predefined implementation so i have a couple of questions
I took a look at the api page and saw this in the mqtt documentation:
[MQTT_BROKER_PREFIX]/[NodeID]/[SensorID]/V_[SensorType]Does this means as example:
MyMQTT/[0-255]/[0-255]/[STRING]/[VALUE]OR this?
MyMQTT/[0-255]/[0-255]/[0-endvarindex]/[VALUE]- Are variable types defined by their index used or by name?
- Also it states it keeps track of node id's how are these reported by the broker, should the controller still hand out free id's?
[EDIT]
I currently do not have the hardware present to at least set it up to test and look at what exactly is happening.
[/EDIT]@John MyMQTT/[0-255]/[0-255]/[STRING]/[VALUE]
MQTT.cpp :
sprintf(&buffer[buffsize],"/%i/%i/V_%s", msg.sender, msg.sensor, getType(convBuf, &vType[msg.type]));note V_%s -> MyMQTT/[0-255]/[0-255]/V_[STRING]/[VALUE]
also note there is no trailing / before payload, as http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html
http://mqtt.org/wiki/doku.php/topic_format
I choose not to have trailing slash, but if needed its easy to make it configurable.and get type translates from this list
char V_0[] PROGMEM = "TEMP"; //V_TEMP char V_1[] PROGMEM = "HUM"; //V_HUM char V_2[] PROGMEM = "LIGHT"; //V_LIGHT char V_3[] PROGMEM = "DIMMER"; //V_DIMMER char V_4[] PROGMEM = "PRESSURE"; //V_PRESSURE char V_5[] PROGMEM = "FORECAST"; //V_FORECAST char V_6[] PROGMEM = "RAIN"; //V_RAIN char V_7[] PROGMEM = "RAINRATE"; //V_RAINRATE char V_8[] PROGMEM = "WIND"; //V_WIND char V_9[] PROGMEM = "GUST"; //V_GUST char V_10[] PROGMEM = "DIRECTON"; //V_DIRECTON char V_11[] PROGMEM = "UV"; //V_UV char V_12[] PROGMEM = "WEIGHT"; //V_WEIGHT char V_13[] PROGMEM = "DISTANCE"; //V_DISTANCE char V_14[] PROGMEM = "IMPEDANCE"; //V_IMPEDANCE char V_15[] PROGMEM = "ARMED"; //V_ARMED char V_16[] PROGMEM = "TRIPPED"; //V_TRIPPED char V_17[] PROGMEM = "WATT"; //V_WATT char V_18[] PROGMEM = "KWH"; //V_KWH char V_19[] PROGMEM = "SCENE_ON"; //V_SCENE_ON char V_20[] PROGMEM = "SCENE_OFF"; //V_SCENE_OFF char V_21[] PROGMEM = "HEATER"; //V_HEATER char V_22[] PROGMEM = "HEATER_SW"; //V_HEATER_SW char V_23[] PROGMEM = "LIGHT_LEVEL"; //V_LIGHT_LEVEL char V_24[] PROGMEM = "VAR1"; //V_VAR1 char V_25[] PROGMEM = "VAR2"; //V_VAR2 char V_26[] PROGMEM = "VAR3"; //V_VAR3 char V_27[] PROGMEM = "VAR4"; //V_VAR4 char V_28[] PROGMEM = "VAR5"; //V_VAR5 char V_29[] PROGMEM = "UP"; //V_UP char V_30[] PROGMEM = "DOWN"; //V_DOWN char V_31[] PROGMEM = "STOP"; //V_STOP char V_32[] PROGMEM = "IR_SEND"; //V_IR_SEND char V_33[] PROGMEM = "IR_RECEIVE"; //V_IR_RECEIVE char V_34[] PROGMEM = "FLOW"; //V_FLOW char V_35[] PROGMEM = "VOLUME"; //V_VOLUME char V_36[] PROGMEM = "LOCK_STATUS"; //V_LOCK_STATUS char V_37[] PROGMEM = "DUST_LEVEL"; //V_DUST_LEVEL char V_38[] PROGMEM = "VOLTAGE"; //V_VOLTAGE char V_39[] PROGMEM = "CURRENT"; //V_CURRENT char V_40[] PROGMEM = ""; // char V_41[] PROGMEM = ""; // char V_42[] PROGMEM = ""; // char V_43[] PROGMEM = ""; // char V_44[] PROGMEM = ""; // char V_45[] PROGMEM = ""; // char V_46[] PROGMEM = ""; // char V_47[] PROGMEM = ""; // char V_48[] PROGMEM = ""; // char V_49[] PROGMEM = ""; // char V_50[] PROGMEM = ""; // char V_51[] PROGMEM = ""; // char V_52[] PROGMEM = ""; // char V_53[] PROGMEM = ""; // char V_54[] PROGMEM = ""; // char V_55[] PROGMEM = ""; // char V_56[] PROGMEM = ""; // char V_57[] PROGMEM = ""; // char V_58[] PROGMEM = ""; // char V_59[] PROGMEM = ""; // char V_60[] PROGMEM = "Started!\n"; //Custom for MQTTGateway char V_61[] PROGMEM = "SKETCH_NAME"; //Custom for MQTTGateway char V_62[] PROGMEM = "SKETCH_VERSION"; //Custom for MQTTGateway char V_63[] PROGMEM = "UNKNOWN"; //Custom for MQTTGateway char V_64[] PROGMEM = "FW_CREQ"; //Custom for MQTTGateway char V_65[] PROGMEM = "FW_CRES"; //Custom for MQTTGateway char V_66[] PROGMEM = "FW_REQ"; //Custom for MQTTGateway char V_67[] PROGMEM = "FW_RES"; //Custom for MQTTGatewayThe MQTTgateway hands out ID's; configured in MQTT.h:
#define MQTT_FIRST_SENSORID 20 // If you want manually configured nodes below this value. 255 = Disable #define MQTT_LAST_SENSORID 254 // 254 is max! 255 reserved. #define MQTT_BROKER_PREFIX "MyMQTT" // First prefix in MQTT tree, keep short! #define MQTT_SEND_SUBSCRIPTION 1 // Send empty payload (request) to node upon MQTT client subscribe request. // NOTE above : Beware to check if there is any length on payload in your incommingMessage code: // Example: if (msg.type==V_LIGHT && strlen(msg.getString())>0) otherwise the code might do strange things. -
@Damme
Clear!And how about the internal messages? Are these somewhat compatible with the Serial API? Like this one now has a "I_GATEWAY_READY" internal var, this one complies then with the "Started!\n" message?
Also about the presentation (if the node does it), are these also passed through?
I know it's a bit question banging... But i just want to do it right.
My Domotica project: http://www.pidome.org
-
@Damme
Clear!And how about the internal messages? Are these somewhat compatible with the Serial API? Like this one now has a "I_GATEWAY_READY" internal var, this one complies then with the "Started!\n" message?
Also about the presentation (if the node does it), are these also passed through?
I know it's a bit question banging... But i just want to do it right.
@John No worries! :)
Presentation is On Todo.. Or Rather To think About list is presentation . I dont do anything with that as it is (Just ignores it). I havn't had any good idea for that yet.Internal is nothing more or less, it connects and set a variable that it is connected. :) But sure, there could be transport for internal messages also.
I do have an experimental version there I can send internal messages to reboot node, reboot gateway and set clear read eeprom values. (over mqtt-protocol) but this s not finnished yet.. Ideas are welcome! -
@John No worries! :)
Presentation is On Todo.. Or Rather To think About list is presentation . I dont do anything with that as it is (Just ignores it). I havn't had any good idea for that yet.Internal is nothing more or less, it connects and set a variable that it is connected. :) But sure, there could be transport for internal messages also.
I do have an experimental version there I can send internal messages to reboot node, reboot gateway and set clear read eeprom values. (over mqtt-protocol) but this s not finnished yet.. Ideas are welcome!@John About Presentation ; My idea was that next version of the variable system I will either store some bytes in the MQTT gateway about what S_types to V_types, or hopefully the next protocol contains both those so the GW doesnt have to remember. And then add an extra directory to the MQTT path ( MyMQTT/[0-255]/[0-255]/S_[STRING]/V_[STRING]/[VALUE]
-
I think maybe it depends on the next protocol implementation. Personally i wouldn't mind if the full path mapping was /[0-255]/[0-255]/etc.. to keep (prog)mem print smaller (use the V_ and S_ array index values). It could leave space for more specific things or some extra gateway specific functions.
it would be nice if the mqtt gateway output was "cloned" to the serial output. Controllers should/could be able to map the S_ and V_ types internally. I'm not aware of the openhab config if that would allow this, or that such a setup would require a lot of coding at openhab side.
[EDIT]
It would be more difficult to read though if a path would only exist of numbers. But could also introduce easier maintainability in your library because you wouldn't have to keep track on type namings.
[/EDIT].My Domotica project: http://www.pidome.org
-
I think maybe it depends on the next protocol implementation. Personally i wouldn't mind if the full path mapping was /[0-255]/[0-255]/etc.. to keep (prog)mem print smaller (use the V_ and S_ array index values). It could leave space for more specific things or some extra gateway specific functions.
it would be nice if the mqtt gateway output was "cloned" to the serial output. Controllers should/could be able to map the S_ and V_ types internally. I'm not aware of the openhab config if that would allow this, or that such a setup would require a lot of coding at openhab side.
[EDIT]
It would be more difficult to read though if a path would only exist of numbers. But could also introduce easier maintainability in your library because you wouldn't have to keep track on type namings.
[/EDIT].@John That was my first aproach, and I might set a define configuration to choose if the MQTT gateway should translate or not. As you say, the footprint would be much smaller.
Might be next version of the MQTT, slectable address layout :) -
@Damme
That would be really cool :)It would be nice though if there was a way to identify node id's with AUTO turned on. Maybe i'm missing something or do you have to know up front with auto enabled which node id is going to be assigned?
I'm just asking this because of identifying new/existing nodes in the network. Is it the V_SKETCH_NAME i can refer to?
And i hope some last questions protocol specific:
- Version compatibility is 3.1?
- All session are clean by default?
My Domotica project: http://www.pidome.org
-
@Damme
That would be really cool :)It would be nice though if there was a way to identify node id's with AUTO turned on. Maybe i'm missing something or do you have to know up front with auto enabled which node id is going to be assigned?
I'm just asking this because of identifying new/existing nodes in the network. Is it the V_SKETCH_NAME i can refer to?
And i hope some last questions protocol specific:
- Version compatibility is 3.1?
- All session are clean by default?
@John upon node startup it translates gw.sendSketchInfo("Battery Meter", "1.0"); into MyMQTT/20/255/V_SKETCH_NAME and version
so you could have a list as in my first post and it would get filled up with all your sketch names
@John ; Yes and I hope so :) (I might have missed some stuff, I do not take regard of QOS etc)
if its not working,, I'll try to fix it :) -
I can confirm it's working with UIPEthernet.h and the ENC28J60 module as well. You need to turn off debugging in MyConfig.h to make the code fit.
-
As I understand it:
The packet on the left would be from the node, the packet on the right would be to the node. Besides swapping sender and destination, the difference is that in 1.4 the gateway does not have the information to binary encode the value, so it sends the value as a string (payload type 0).
EDIT: added alternate MQTT respresentation of V_code as numeric -
As I understand it:
The packet on the left would be from the node, the packet on the right would be to the node. Besides swapping sender and destination, the difference is that in 1.4 the gateway does not have the information to binary encode the value, so it sends the value as a string (payload type 0).
EDIT: added alternate MQTT respresentation of V_code as numeric -
At first, I thought MQTT would be a great extension to the functionality, in particular because it might systematize the idea of routing messages to more than one destination - eg: to both a HA controller and to a cloud storage service.
So I saw these possible advantages of MQTT:
- Route to multiple destinations, dynamically updated
- Subscription wildcards to filter for desired subsets
- Possibly easier to build plug-ins for some HA controllers
As I look deeper into it, I'm coming to wonder about that.
- There are lighter weight ways to send to more than one destination
- Does subscription wildcarding meet the filtering needs well (below)?
- Is it easier or not?
I'm wondering what subscription wildcards really get used - how valuable is the type of filtering functionality offered by MQTT for our purposes? The meaingful patterns I would imagine are:
- everything
- everything from one node
- everything from one child of one node
- everything of type V_RAIN from one child of one node (ie: one variable)
- everything of type V_RAIN from anywhere
Are any of these (or other options) in use except "everything"? Do you anticipate that they will be?
Just as "route to multiple destinations" could be lighter, filtering could be done differently as well. For example, suppose you wanted to receive all report of inside temperature (7 sensors in your network) or humidity (5 sensors), but not outside temp or humidity and not other v codes. That might take 12 subscriptions - and they would have to be manually set up, or make use of manually entered metadata tables in the controller plug-in (eg: the plug-in might be configured to know which nodes had temp and/or humidity, and which ones were considered "inside", if it was written to handled that).
I could imagine that even if the subscription filtering wasn't highly useful, MQTT might make it easier to create plug-ins for some HA controllers, than using semicolon separated values (serial text format). Is that the case?
I'm very open to hearing other advantages of MQTT, I'm not against it, just trying to understand the benefits vs cost aspect better.
-
The other extension that occurs to me, in the gateway-as-transparent-switch model, is that if we ever wanted to encode binary values OTA from the gateway to the node, the plug-in would have to tell the gateway which payload_type to use. In the Semicolon Separted Values format, that could be another parameter, eg:
<node id>;<child id>;<command>;<ack>;<v_code>;<payload_type>;<value>Or it could be added to one of the other fields with a comma sub-delimiter, etc.
How would a controller plug in tell the MQTT gateway to use payload type P_UNIT16 to send to node 7?
I'm thinking that it would be done in the value string, rather than encoded into the topic. So maybe the value string goes from "321" to "4,321" or something like that.
-
@ToSa I'll update mqtt later with option to not translate V_TYPE into name string but to keep it as a byte, that would save a lot of memory and might solve problem you have. I'll keep you posted
@Damme said:
@ToSa I'll update mqtt later with option to not translate V_TYPE into name string but to keep it as a byte, that would save a lot of memory and might solve problem you have. I'll keep you posted
I could not follow the discussions the last few days - will definitely have a look over the weekend and let you know if that worked. Thanks!
-
@Damme
When the MQTT gateway prints information about itself like "started", is this done with node id 0 or 255?@John 'started' is only a internal log message, I've changed how that part works.
I've also fixed a couple of bugs and will test the changes tomorrow before I publish them.
New functionallity there user can choose of MQTT should translate ID to V_TYPE or not too. -
@Damme
Ok, my plugin will then just try to reconnect.Ok, i will check that then probably the day after tomorrow, i will make my code take no translation as first and if not found try the naming (internally), because the server takes over the semantics anyway because it also is going to include a MQTT broker service.
Currently the MQTT implementation is being tested with an end user. Maybe he will help test the new possibility without V_TYPE translation when your changes are implemented.
-
@Damme
When does exactly the messages like "MyMQTT/[NODEID]/255/V_SKETCH_NAME" and/or "MyMQTT/[NODEID]/255/V_SKETCH_VERSION" appear? is this only when an address is assigned or always when a node is started?My Domotica project: http://www.pidome.org
